İlya Kosmodemyanskinin 2015-ci il hesabatının transkripsiyası "PostgreSQL performansını yaxşılaşdırmaq üçün Linux tənzimləməsi"
İmtina: Qeyd edirəm ki, bu hesabat 2015-ci ilin noyabrına aiddir - 4 ildən çox vaxt keçib və çox vaxt keçib. Hesabatda müzakirə olunan 9.4 versiyası artıq dəstəklənmir. Son 4 il ərzində PostgreSQL-in 5 yeni buraxılışı və Linux nüvəsinin 15 versiyası var. Bu yerləri yenidən yazsanız, başqa hesabatla nəticələnəcəksiniz. Ancaq bu gün də aktual olan PostgreSQL üçün əsas Linux tənzimləməsidir.
Mənim adım İlya Kosmodemyanskidir. Mən PostgreSQL-Consulting şirkətində işləyirəm. İndi isə ümumiyyətlə verilənlər bazası və xüsusən PostgreSQL ilə bağlı Linux ilə nə edəcəyim barədə bir az danışacağam, çünki prinsiplər olduqca oxşardır.
Nə müzakirə olunacaq? Əgər siz PostgreSQL ilə məşğul olursunuzsa, o zaman müəyyən dərəcədə UNIX admini olmalısınız. Bunun mənası nədi? Oracle və PostgreSQL-i müqayisə etsək, Oracle-da siz 80% DBA verilənlər bazası admini və 20% Linux admini olmalısınız.
PostgreSQL bir az daha çətindir. PostgreSQL ilə Linux-un necə işlədiyi barədə daha yaxşı təsəvvürə malik olmalısınız. Və eyni zamanda, lokomotivdən bir az sonra qaçın, çünki son vaxtlar hər şey olduqca sərin şəkildə yeniləndi. Və yeni nüvələr çıxır və yeni funksionallıq görünür, performans yaxşılaşır və s.
Niyə Linux haqqında danışırıq? Heç ona görə yox ki, biz Peter Linux konfransındayıq, lakin ona görə ki, müasir şəraitdə ümumiyyətlə verilənlər bazası və xüsusən PostgreSQL ilə işləmək üçün ən əsaslandırılmış əməliyyat sistemlərindən biri Linux-dur. Çünki FreeBSD, təəssüf ki, çox qəribə bir istiqamətdə inkişaf edir. Həm performansda, həm də bir çox başqa şeylərdə problemlər olacaq. Windows-da PostgreSQL-in performansı ümumiyyətlə ayrı bir sərt mövzudur, Windows-un UNIX kimi ortaq yaddaşa sahib olmamasına əsaslanır və PostgreSQL çox prosesli bir sistem olduğu üçün bu biznesə aiddir.
Solaris kimi ekzotiklər isə, məncə, hamını daha az maraqlandırır, ona görə də gedək.
Müasir Linux paylamasında nüvənin necə qurulduğundan asılı olaraq 1-dən çox syctl variantı var. Eyni zamanda, müxtəlif qoz-fındıqları nəzərdən keçirsək, onda hələ də bir şeyi tənzimləmək üçün bir çox yol ola bilər. Quraşdırmaq üçün fayl sistemi seçimləri var. Necə başlamaq barədə suallarınız varsa: BIOS-da nəyi aktivləşdirmək, aparatı necə konfiqurasiya etmək və s.
Bu, bir qısa hesabatda deyil, bir neçə gün danışıla bilən çox böyük bir həcmdir, lakin mən indi vacib şeylərə diqqət yetirəcəyəm, əgər Linux-da verilənlər bazasını yaxşı idarə etməyə imkan verməyəcək o dırmıqlardan necə qaçınmaq olar. sən onları düzəltmirsən.. Və eyni zamanda, vacib bir məqam, bir çox standart parametrlərin verilənlər bazası üçün düzgün olan parametrlərə daxil edilməməsidir. Yəni, default olaraq pis işləyəcək və ya heç işləməyəcək.
Linux-da ənənəvi tuning hədəfləri hansılardır? Düşünürəm ki, siz hamınız Linux administrasiyası ilə məşğul olduğunuz üçün hədəflərin nə olduğunu izah etməyə ehtiyac yoxdur.
Siz tənzimləyə bilərsiniz:
- CPU-lar.
- Yaddaş.
- Saxlama.
- başqa. Bu barədə sonda qəlyanaltı üçün danışacağıq. Hətta, məsələn, enerjiyə qənaət siyasəti kimi parametrlər performansa çox gözlənilməz və çox da xoş olmayan şəkildə təsir göstərə bilər.
PostgreSQL-in və ümumiyyətlə verilənlər bazasının xüsusiyyətləri hansılardır? Problem ondadır ki, siz müəyyən bir qozu düzəldə bilmirsiniz və performansımızın çox yaxşılaşdığını görə bilmirsiniz.
Bəli, belə qadjetlər var, lakin verilənlər bazası mürəkkəb bir şeydir. O, serverin malik olduğu bütün resurslarla qarşılıqlı əlaqə qurur və tam şəkildə qarşılıqlı fəaliyyətə üstünlük verir. Əgər siz Oracle-ın host ƏS-dən necə istifadə etmək barədə hazırkı təlimatlarına baxsanız, bu, monqol astronavtının zarafatına bənzəyir - iti qidalandırın və heç bir şeyə toxunmayın. Gəlin verilənlər bazasına bütün resursları verək, verilənlər bazası özü hər şeyi məhv edəcək.
Prinsipcə, müəyyən dərəcədə vəziyyət PostgreSQL ilə tamamilə eynidir. Fərq ondadır ki, baza özü üçün bütün resursları götürə bilmir, yəni Linux səviyyəsində bir yerdə hər şeyi özünüz həll etməlisiniz.
Əsas fikir tək bir hədəf seçmək və onu tənzimləməyə başlamaq deyil, məsələn, yaddaş, CPU və ya buna bənzər bir şey, ancaq iş yükünü təhlil etmək və yaxşı proqramçıların yaratdığı yükü mümkün qədər yaxşılaşdırmağa çalışmaqdır. istifadəçilərimiz də daxil olmaqla.
Bunun nə olduğunu izah etmək üçün bir şəkil var. Linux OS buferi və ortaq yaddaş var və PostgreSQL paylaşılan buferləri var. PostgreSQL, Oracle-dan fərqli olaraq, birbaşa yalnız kernel buferi vasitəsilə işləyir, yəni diskdən bir səhifənin paylaşılan yaddaşa daxil olması üçün o, nüvə buferindən keçməli və tam eyni vəziyyəti geri qaytarmalıdır.
Disklər bu sistem altında yaşayır. Mən onu disklər kimi çəkmişəm. Əslində, bir RAID nəzarətçisi ola bilər və s.
Və bu giriş-çıxış bu və ya digər şəkildə bu biznes vasitəsilə baş verir.
PostgreSQL klassik verilənlər bazasıdır. Səhifənin içərisindədir. Və bütün giriş-çıxış səhifələrin köməyi ilə baş verir. Yaddaşdakı blokları səhifələrlə qaldırırıq. Heç bir şey olmadıqda, biz onları sadəcə oxuyuruq, sonra tədricən bu keşdən, paylaşılan buferlərdən batırılır və diskə qayıdırlar.
Əgər bir yerdə nəyisə əvəz etmişiksə, bütün səhifəmiz çirkli olaraq qeyd olunur. Mən onları burada mavi rənglə qeyd etdim. Və bu o deməkdir ki, bu səhifə blok yaddaşı ilə sinxronlaşdırılmalıdır. Yəni onu çirkləndirəndə WAL-a giriş etdik. Və zamanın gözəl bir nöqtəsində, nəzarət nöqtəsi adlı bir fenomen gəldi. Və bu jurnalda onun gəldiyi barədə məlumat qeydə alınıb. Və bu o deməkdir ki, o anda bu paylaşılan buferlərdə olan bütün çirkli səhifələr fsync istifadə edərək, nüvə buferi vasitəsilə yaddaş diski ilə sinxronlaşdırılıb.
Bu nə üçündür? Gərginliyi itirmişiksə, o zaman bütün məlumatların itirildiyi vəziyyəti almadıq. Hər kəsin bizə söylədiyi davamlı yaddaş, verilənlər bazası nəzəriyyəsində indiyə qədərdir - bu, əlbəttə ki, səy göstərdiyimiz və bəyəndiyimiz parlaq bir gələcəkdir, lakin hələ də mənfi 20 il yaşayırlar. Və təbii ki, bütün bunlara nəzarət etmək lazımdır.
Və ötürmə qabiliyyətini artırmaq vəzifəsi bütün bu mərhələləri tənzimləməkdir ki, hər şey tez bir zamanda irəli və geri getsin. Paylaşılan yaddaş əsasən səhifə keşidir. PostgreSQL-də biz orada bir sorğu göndərdik, bu məlumatları diskdən aldı. Ortaq buferlərə girdilər. Müvafiq olaraq, bunun daha yaxşı işləməsi üçün çoxlu yaddaş olmalıdır.
Bütün bunların yaxşı və tez işləməsi üçün əməliyyat sistemini bütün mərhələlərdə düzgün konfiqurasiya etməlisiniz. Və balanslaşdırılmış dəmiri seçin, çünki bir yerdə balanssızlıq varsa, o zaman çox yaddaş edə bilərsiniz, lakin o, qeyri-kafi sürətlə xidmət edəcəkdir.
Gəlin bu məqamların hər birini nəzərdən keçirək.
Bu səhifələrin daha sürətli irəli-geri səyahət etməsi üçün aşağıdakılara nail olmalısınız:
- Birincisi, yaddaşla daha səmərəli işləmək lazımdır.
- İkincisi, yaddaşdan səhifələr diskə keçdikdə bu keçid daha səmərəli olmalıdır.
- Üçüncüsü, yaxşı disklər olmalıdır.
Əgər serverdə 512 GB RAM varsa və bütün bunlar heç bir önbellek olmadan SATA sabit diskində başa çatırsa, onda bütün verilənlər bazası serveri təkcə balqabaq deyil, SATA interfeysli balqabaq halına gəlir. Birbaşa onunla qarşılaşacaqsınız. Və heç bir şey sizi xilas etməyəcək.
Yaddaşla bağlı ilk məqama gəlincə, həyatı çox çətinləşdirən üç şey var.
Birincisi NUMA-dır. NUMA performansı artırmaq üçün hazırlanmış bir şeydir. İş yükündən asılı olaraq, müxtəlif şeyləri optimallaşdıra bilərsiniz. Və yeni cari formada, səhifə önbelleği paylaşılan buferlərdən intensiv istifadə edən verilənlər bazası kimi proqramlar üçün çox yaxşı deyil.
Bir sözlə. NUMA-da nəyinsə səhv olduğunu necə başa düşmək olar? Bir növ xoşagəlməz tıqqıltı var, birdən bəzi CPU həddindən artıq yüklənir. Eyni zamanda, siz PostgreSQL-də sorğuları təhlil edirsiniz və orada oxşar heç nə olmadığını görürsünüz. Bu sorğular çox CPU intensiv olmamalıdır. Onu uzun müddət tuta bilərsiniz. PostgreSQL üçün NUMA-nın necə qurulması ilə bağlı düzgün məsləhətdən istifadə etmək daha asandır.
Həqiqətən nə baş verir? NUMA qeyri-vahid yaddaş girişi deməkdir. Məsələ nədir? Sizdə CPU var, onun yanında onun yerli yaddaşı var. Və bu yaddaş konnektorları yaddaşı digər CPU-lardan çəkə bilər.
Qaçarsansa numactl --hardware, onda belə böyük vərəq alacaqsınız. Digər şeylər arasında məsafələr sahəsi olacaq. Rəqəmlər olacaq - 10-20, belə bir şey. Bu rəqəmlər bu uzaq yaddaşı götürmək və onu yerli olaraq istifadə etmək üçün hopların sayından başqa bir şey deyil. Əsasən yaxşı fikirdir. Bu, bir sıra iş yüklərində performansı yaxşılaşdırır.
İndi təsəvvür edin ki, əvvəlcə yerli yaddaşdan istifadə etməyə çalışan bir CPU-nuz var, sonra bir şey üçün interconnect vasitəsilə başqa bir yaddaşı götürməyə çalışırsınız. Və bütün PostgreSQL səhifə keşiniz bu CPU-ya daxil olur - bu qədər, orada neçə gigabayt var. Siz həmişə ən pis vəziyyətdə olursunuz, çünki CPU-da birbaşa həmin modulda adətən az yaddaş olur. Və xidmət edilən bütün yaddaş bu qarşılıqlı əlaqədən keçir. Yavaş-yavaş və kədərli şəkildə ortaya çıxır. Və bu node'a xidmət edən bir prosessorunuz var, daim yüklənir. Və bu yaddaşın giriş vaxtı pisdir, yavaşdır. Əgər bu işi verilənlər bazası üçün istifadə edirsinizsə, bu, istəmədiyiniz vəziyyətdir.
Buna görə də, verilənlər bazası üçün daha düzgün seçim, Linux əməliyyat sisteminin orada nə baş verdiyini ümumiyyətlə bilməməsidir. Belə ki, o, müraciət etdiyi kimi yaddaşa müraciət edir.
Niyə belədir? Deyəsən, bunun əksi olmalıdır. Bu, bir sadə səbəbdən baş verir ki, səhifə keşi üçün bizə çoxlu yaddaş lazımdır - onlarla, yüzlərlə gigabayt.
Bütün bunları ayırsaq və məlumatlarımızı orada saxlasaq, keşdən istifadənin qazancı belə bir hiyləgər yaddaş girişindən əldə edilən qazancdan xeyli çox olacaq. Və bu yolla NUMA-dan istifadə edərək yaddaşa daha səmərəli daxil olacağımızla müqayisədə müqayisə olunmayacaq dərəcədə qazanacağıq.
Buna görə də, hazırda iki yanaşma var, parlaq gələcək gələnə qədər və verilənlər bazası özü hansı CPU-larda işlədiyini və haradan nəyisə götürməli olduğunu anlaya bilmir.
Buna görə düzgün yanaşma NUMA-nı tamamilə söndürməkdirməsələn, yenidən başladıqda. Əksər hallarda uduşlar elə sifarişlərdə olur ki, heç bir sual yoxdur, hansı daha yaxşıdır.
Başqa variant da var. Biz ondan birincisindən daha tez-tez istifadə edirik, çünki müştəri dəstək üçün bizə gələndə onun serveri yenidən işə salması hər şeydir. Onun orada biznesi var. Və NUMA-ya görə problemlər yaşayırlar. Buna görə də, biz onu yenidən başlatmaqdan daha az invaziv üsullarla söndürməyə çalışırıq, lakin burada onun söndürüldüyünü yoxlamaq üçün diqqətli olun. Çünki təcrübənin göstərdiyi kimi, biz PostgreSQL-in ana prosesində NUMA-nı deaktiv edirik, bu yaxşıdır, lakin bunun işləməsi heç də vacib deyil. Yoxlayıb görməliyik ki, o, həqiqətən sönüb.
Robert Haasın yaxşı bir yazısı var. Bu, PostgreSQL komitentlərindən biridir. Bütün aşağı səviyyəli giblets əsas inkişaf etdiricilərindən biri. Bu yazıdakı bağlantıları izləsəniz, NUMA-nın insanların həyatını necə çətinləşdirdiyinə dair bir neçə rəngarəng hekayəni təsvir edir. Baxın, verilənlər bazamızın yaxşı işləməsi üçün serverdə konfiqurasiya edilməli olan sistem administratorunun yoxlama siyahısını öyrənin. Bu parametrləri qeyd etmək və yoxlamaq lazımdır, çünki əks halda çox yaxşı olmayacaq.
Diqqətinizi ona yönəldirəm ki, bu, danışacağım bütün parametrlərə aiddir. Lakin adətən verilənlər bazaları xətaya dözümlülük üçün master-slave rejimində yığılır. Qulada bu sazlamaları etməyi unutmayın, çünki bir gün qəzaya düşəcəksiniz və qulluğa keçəcəksiniz və o, ağa olacaq.
Fövqəladə vəziyyətdə, hər şey çox pis olduqda, telefonunuz davamlı olaraq çaldıqda və müdiriniz böyük bir çubuqla qaçırsa, yoxlamaq barədə düşünməyə vaxtınız olmayacaq. Və nəticələr çox fəlakətli ola bilər.
Növbəti an böyük səhifələrdir. Böyük səhifələri ayrıca sınamaq çətindir və bunun heç bir mənası yoxdur, baxmayaraq ki, bunu edə bilən meyarlar var. Onlar asanlıqla google-da axtarılır.
Nə mənası var? Çoxlu operativ yaddaşa malik, məsələn, 30 GB-dan çox olan çox bahalı olmayan bir serveriniz var. Böyük səhifələrdən istifadə etmirsiniz. Bu o deməkdir ki, yaddaşdan istifadə ilə bağlı mütləq yükünüz var. Və bu yük ən xoş olandan uzaqdır.
Niyə belədir? Və nə baş verir? Əməliyyat sistemi yaddaşı kiçik hissələrə ayırır. O qədər rahat, o qədər tarixi. Təfərrüatlara girsəniz, OS virtual ünvanları fiziki ünvanlara çevirməlidir. Və bu proses ən asan deyil, ona görə də ƏS bu əməliyyatın nəticəsini Translation Lookaside Buferində (TLB) yaddaşda saxlayır.
TLB bir önbellek olduğundan, bu vəziyyətdə önbelleğe xas olan bütün problemlər yaranır. Birincisi, çoxlu operativ yaddaşınız varsa və hamısı kiçik hissələrə bölünürsə, bu bufer çox böyük olur. Önbellek böyükdürsə, onu axtarmaq daha yavaşdır. Baş üstü sağlamdır və öz-özünə yer tutur, yəni səhv bir şey RAM istehlak edir. Bu vaxt.
İki - belə bir vəziyyətdə önbellek nə qədər çox böyüyərsə, önbellek qaçırma ehtimalınız bir o qədər yüksəkdir. Və ölçüsü böyüdükcə bu keşin səmərəliliyi sürətlə aşağı düşür. Beləliklə, əməliyyat sistemləri sadə bir yanaşma ilə gəldi. Linux ondan çoxdan istifadə edir. Bu yaxınlarda FreeBSD-də ortaya çıxdı. Amma biz Linux-dan danışırıq. Bunlar böyük səhifələrdir.
Və burada qeyd etmək lazımdır ki, nəhəng səhifələr ideya olaraq ilkin olaraq Oracle və IBM-in daxil olduğu icmalar tərəfindən irəli sürülürdü, yəni verilənlər bazası istehsalçıları bunun verilənlər bazaları da daxil olmaqla faydalı olacağı barədə çox düşünürdülər.
PostgreSQL ilə necə dostluq etmək olar? Birincisi, Linux nüvəsində nəhəng səhifələr aktivləşdirilməlidir.
İkincisi, onlar sysctl parametri ilə açıq şəkildə göstərilməlidir - neçə var. Buradakı nömrələr köhnə serverdəndir. Nəhəng səhifələrin oraya sığması üçün təxminən neçə paylaşılan buferinizin olduğunu hesablaya bilərsiniz.
PostgreSQL-ə həsr olunmuş bütün serveriniz varsa, yaxşı bir başlanğıc nöqtəsi paylaşılan buferlər üçün RAM-ın 25% və ya verilənlər bazanızın bu 75% -ə mütləq uyğun olacağına əminsinizsə, 75% verməkdir. Əvvəlcə başlanğıc nöqtəsi. Və nəzərə alın, əgər 256 GB RAM varsa, deməli, 64 GB sherd buferiniz olacaq. Bəzi marja ilə hesablayın - bu rəqəmi nəyə qoymalısınız.
9.2 versiyasından əvvəl (səhv etmirəmsə, 8.2 versiyasından) üçüncü tərəf kitabxanasından istifadə edərək nəhəng PostgreSQL səhifələri ilə dostluq etmək mümkün idi. Və bu həmişə edilməlidir. Birincisi, nəhəng səhifələri düzgün ayıra bilmək üçün nüvəyə ehtiyacınız var. İkincisi, onlarla işləyən proqram onlardan istifadə edə bilsin. Sadəcə bu şəkildə istifadə olunmayacaq. PostgreSQL yaddaşı sistem 5 üslubunda ayırdığı üçün bunu libhugetlbfs istifadə etməklə etmək olar - bu kitabxananın tam adıdır.
9.3 PostgreSQL yaddaş performansını yaxşılaşdırdı və sistem 5 yaddaş ayırma metodunu sildi. Hər kəs çox xoşbəxt idi, çünki əks halda siz eyni maşında iki PostgreSQL nümunəsini işlətməyə çalışırsınız və o deyir ki, mənim kifayət qədər ortaq yaddaşım yoxdur. Və deyir ki, sysctl-i düzəltməlisən. Və elə bir sysctl var ki, hələ də reboot etmək lazımdır və s. Ümumiyyətlə, hər kəs sevindi. Lakin mmap yaddaş bölgüsü böyük səhifələrdən istifadə edərək pozuldu. Müştərilərimizin əksəriyyəti böyük paylaşılan buferlərdən istifadə edir. Və biz 9.3-ə keçməməyi şiddətlə tövsiyə etdik, çünki orada qaimə yaxşı faizlə hesablanmağa başladı.
Amma digər tərəfdən camaat bu problemə diqqət çəkdi və 9.4-də bu hadisəni çox yaxşı işlədilər. Və 9.4-də postgresql.conf-da bir parametr meydana çıxdı, orada cəhd edə, yandıra və ya söndürə bilərsiniz.
Cəhd etmək ən təhlükəsiz seçimdir. PostgreSQL başladıqda, paylaşılan yaddaş ayırdıqda, bu yaddaşı nəhəng səhifələrdən tutmağa çalışır. Və işləmirsə, o, adi seçimə qayıdır. Əgər sizdə FreeBSD və ya Solaris varsa, o zaman cəhd edə bilərsiniz, o, həmişə təhlükəsizdir.
Əgər aktivdirsə, nəhəng səhifələrdən seçə bilməsə, sadəcə başlamır. Burada artıq - kimə və nə daha sevimlidir. Ancaq cəhd etsəniz, həqiqətən vurğulamağınız lazım olanı yoxlayın, çünki səhv üçün çoxlu boşluq var. Hazırda bu funksiya yalnız Linux-da işləyir.
Davam etməzdən əvvəl daha bir kiçik qeyd. Şəffaf nəhəng səhifələr hələ PostgreSQL haqqında deyil. Onlardan normal istifadə edə bilmir. Və belə bir iş yükü üçün Transparent nəhəng səhifələri ilə, böyük bir paylaşılan yaddaşa ehtiyac olduqda, üstünlüklər yalnız çox böyük həcmlərlə gəlir. Əgər terabayt yaddaşınız varsa, bu, rol oynaya bilər. Daha çox gündəlik tətbiqlərdən danışırıqsa, maşında 32, 64, 128, 256 GB yaddaşınız olduqda, adi nəhəng səhifələr Ok olur və biz sadəcə Şəffaflığı söndürürük.
Yaddaşla bağlı son şey fruputla birbaşa əlaqəli deyil, həyatı çox məhv edə bilər. Serverin daim dəyişdirilməsi bütün ötürmə qabiliyyətinə böyük təsir göstərəcəkdir.
Və bəzi məqamlarda çox xoşagəlməz olacaq. Əsas problem odur ki, müasir nüvələrdə davranış köhnə Linux nüvələrindən bir qədər fərqlidir. Və bu, olduqca xoşagəlməz bir addımdır, çünki biz dəyişdirmə ilə bəzi işlərdən danışarkən, OOM-qatilinin vaxtında gəlməməsi ilə başa çatır. Və vaxtında gəlməyən və PostgreSQL-dən kənara çıxan OOM-qatil xoşagəlməzdir. Hər kəs bu barədə, yəni son istifadəçiyə qədər biləcək.
Nə baş verir? Orada böyük miqdarda RAM var, hər şey yaxşı işləyir. Ancaq nədənsə server svopda dayanır və buna görə yavaşlayır. Deyəsən, yaddaş çoxdur, amma olur.
Əvvəllər biz vm.swappiness-i sıfıra təyin etməyi, yəni dəyişdirməni söndürməyi məsləhət gördük. Əvvəllər belə görünürdü ki, 32 GB operativ yaddaş və müvafiq paylaşılan buferlər böyük məbləğdir. Swapın əsas məqsədi yıxılacağımız təqdirdə qabıq atmaq üçün bir yerə sahib olmaqdır. Və o qədər də yaxşı alınmayıb. Bəs onda bu qabıqla nə edəcəksən? Mübadilə niyə lazım olduğu çox aydın olmayanda, xüsusən də belə bir ölçüdə bu, artıq belə bir vəzifədir.
Ancaq daha müasir, yəni nüvənin üçüncü versiyalarında davranış dəyişdi. Mübadiləni sıfıra təyin etsəniz, yəni onu söndürsəniz, gec və ya tez, hətta bir az RAM qaldıqda, ən intensiv istehlakçıları öldürmək üçün sizə bir OOM qatili gələcək. Çünki o hesab edəcək ki, belə bir iş yükü ilə hələ bir az qalıb və biz sıçrayacağıq, yəni sistem prosesini öldürməyərək, daha az vacib olanı öldürəcəyik. Bu daha az əhəmiyyətli paylaşılan yaddaşın ağır istehlakçısı, yəni poçt müdiri olacaqdır. Və bundan sonra bazanın bərpası lazım olmasa yaxşı olar.
Buna görə də, indi standart olaraq, xatırladığım qədər, paylamaların çoxu təxminən 6-dır, yəni nə qədər yaddaş qaldığından asılı olaraq dəyişdirmədən istifadə etməyə hansı nöqtədə başlamaq lazımdır. İndi biz vm.swappiness = 1 təyin etməyi məsləhət görürük, çünki o, praktiki olaraq onu söndürür, lakin gözlənilməz bir OOM öldürücü ilə gələn və hər şeyi öldürən kimi effektlər vermir.
Sonra nə var? Biz verilənlər bazalarının performansından danışanda və yavaş-yavaş, yavaş-yavaş disk kimiyik, hamı başını tutmağa başlayır. Çünki diskin yavaş, yaddaşın sürətli olması həqiqəti hər kəsə uşaqlıqdan tanışdır. Və hər kəs bilir ki, verilənlər bazasında disk performansı ilə bağlı problemlər olacaq.
PostgreSQL-də yoxlama nöqtələrindəki əsas problem diskin yavaş olması deyil. Bu, daha çox yaddaş və disk bant genişliyinin balanslaşdırılmaması ilə bağlıdır. Bununla belə, onlar müxtəlif yerlərdə balanslaşdırılmaya bilər. PostgreSQL konfiqurasiya edilməyib, OS konfiqurasiya edilməyib, hardware konfiqurasiya edilməyib və hardware səhvdir. Və bu problem yalnız hər şey lazım olduğu kimi getdiyi təqdirdə baş vermir, yəni ya yük yoxdur, ya da parametrlər və avadanlıq yaxşı seçilmişdir.
Bu nədir və nə kimi görünür? Adətən, PostgreSQL ilə işləyən insanlar bu işə bir dəfədən çox daxil olurlar. izah edəcəm. Dediyim kimi, PostgreSQL vaxtaşırı paylaşılan yaddaşdakı çirkli səhifələri diskə atmaq üçün yoxlama nöqtələri yaradır. Böyük miqdarda paylaşılan yaddaşımız varsa, yoxlama nöqtəsi diskə intensiv təsir göstərməyə başlayır, çünki fsync bu səhifələri boşaltır. O, nüvə buferinə daxil olur və fsync istifadə edərək diskə yazılır. Və bu işin həcmi böyükdürsə, onda xoşagəlməz bir effekti, yəni disklərin çox böyük istifadəsini müşahidə edə bilərik.
Burada iki şəkilim var. İndi bunun nə olduğunu izah edəcəyəm. Bunlar zamanla əlaqəli iki qrafikdir. Birinci qrafik diskdən istifadədir. Burada bu zaman demək olar ki, 90%-ə çatır. Fiziki disklərlə, RAID nəzarətçi ilə 90% istifadə ilə verilənlər bazanız varsa, bu pis xəbərdir. Bu o deməkdir ki, bir az daha çox və 100 gələcək və giriş / çıxış dayanacaq.
Bir disk massiviniz varsa, bir az fərqli bir hekayə var. Orada onun necə konfiqurasiya olunduğundan, hansı massivdən və s.-dən asılıdır.
Paralel olaraq, burada nəzarət nöqtəsinin necə baş verdiyini göstərən daxili postgres görünüşündən bir qrafik konfiqurasiya edilir. Buradakı yaşıl rəng o anda bu çirkli səhifələrin neçə tamponunun sinxronizasiya üçün bu keçid məntəqəsinə gəldiyini göstərir. Və burada bilmək lazım olan əsas şey budur. Görürük ki, burada çoxlu səhifələrimiz var və nə vaxtsa ödənişlə üzləşdik, yəni yazdıq və yazdıq, burada disk sistemi açıq şəkildə çox məşğuldur. Bizim nəzarət məntəqəmiz isə diskə çox güclü təsir göstərir. İdeal olaraq, vəziyyət daha çox belə görünməlidir, yəni burada rekordumuz daha az idi. Və biz bunu parametrlərlə düzəldə bilərik ki, belə davam etsin. Yəni təkrar emal azdır, amma hardasa biz burada nəsə yazırıq.
Bu problemi aradan qaldırmaq üçün nə etmək lazımdır? Əgər verilənlər bazası altında IO-nu dayandırmısınızsa, bu o deməkdir ki, sorğularını yerinə yetirmək üçün gələn bütün istifadəçilər gözləyəcəklər.
Əgər Linux nöqteyi-nəzərindən baxsanız, yaxşı aparat götürmüsünüzsə, onu düzgün konfiqurasiya etmisinizsə, PostgreSQL-i normal şəkildə konfiqurasiya etmisinizsə ki, bu nəzarət nöqtələrini daha az etsin, bir-biri arasında vaxtında yaysın, sonra Debian standart parametrlərinə daxil olursunuz. . Əksər Linux paylamaları üçün bu şəkil belədir: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Bunun mənası nədi? Kernel 2.6-dan bəri bir cin qızarması meydana çıxdı. Pdglush, kimin nəyi istifadə etməsindən asılı olaraq, arxa planda məşğul olan, kernel buferindən çirkli səhifələri atmaq və lazım olanda, nə olursa olsun, çirkli səhifələri atmaq, arxa plana atmaq kömək etmir.
Fon nə vaxt gəlir? Serverdə olan ümumi operativ yaddaşın 10%-i kernel buferindəki çirkli səhifələr tərəfindən tutulduqda, arxa planda xüsusi fırıldaqçı funksiyası çağırılır. Niyə o fondadır? Neçə səhifənin silinməsi parametr kimi götürülür. Və deyək ki, N səhifəni yazır. Və bir müddət bu şey yuxuya gedir. Sonra qayıdır və daha bir neçə səhifəni yazır.
Bu son dərəcə sadə bir hekayədir. Burada vəzifə bir hovuza bənzəyir, bir boruya töküləndə digərinə tökülür. Yoxlama məntəqəmiz gəldi və atmaq üçün bir neçə çirkli səhifə göndərdisə, pgflush kernel buferindən tədricən bu hər şey səliqəli şəkildə həll ediləcəkdir.
Bu çirkli səhifələr yığılmağa davam edərsə, onlar 20% -ə qədər toplanır, bundan sonra OS prioriteti hər şeyi diskə yazmaqdır, çünki enerji sönəcək və hər şey bizim üçün pis olacaq. Məsələn, bu məlumatları itirəcəyik.
Nə hiylə var? Məsələ ondadır ki, müasir dünyada bu parametrlər maşındakı bütün RAM-ın 20 və 10% -ni təşkil edir, sahib olduğunuz hər hansı bir disk sisteminin ötürmə qabiliyyəti baxımından tamamilə dəhşətlidir.
Təsəvvür edin ki, 128 GB operativ yaddaşınız var. 12,8 GB disk sisteminizə gəlir. Və orada hansı önbelleğiniz olursa olsun, orada hansı massiviniz olursa olsun, onlar o qədər də dözməyəcəklər.
Buna görə də, RAID nəzarətçinizin imkanlarından asılı olaraq bu nömrələrin dərhal tənzimlənməsini tövsiyə edirik. Mən dərhal burada 512 MB keş yaddaşa malik nəzarətçi üçün tövsiyə verdim.
Hər şey çox sadə hesab olunur. Siz vm.dirty_background-u baytlara yerləşdirə bilərsiniz. Və bu parametrlər əvvəlki ikisini əvəz edir. Ya nisbət standartdır, ya da baytları olanlar aktivləşdirilib, baytları olanlar işləyəcək. Ancaq mən bir DBA məsləhətçisi olduğum üçün və müxtəlif müştərilərlə işlədiyim üçün saman qoymağa çalışıram və buna görə də baytlarda, baytlarda. Heç kim heç bir zəmanət vermədi ki, yaxşı admin serverə yaddaş əlavə etməyəcək, onu yenidən işə salmayacaq və rəqəm eyni qalacaq. Sadəcə bu rəqəmləri hesablayın ki, hər şey zəmanətlə ora uyğun olsun.
Uyğunlaşmasanız nə olar? Mən yazmışam ki, hər hansı bir qızartı təsirli şəkildə dayandırır, amma əslində bu, bir ifadədir. Əməliyyat sisteminin böyük problemi var - onun çoxlu çirkli səhifələri var, buna görə də müştərilərinizin effektiv şəkildə yaratdığı IO dayanır, yəni proqram verilənlər bazasına sql sorğusu göndərmək üçün gəlib, o, gözləyir. Ona hər hansı bir giriş/çıxış ən aşağı prioritetdədir, çünki baza nəzarət məntəqəsi tərəfindən tutulur. Və o, bitirdikdə tamamilə anlaşılmazdır. Qeyri-fonda, qeyri-fonda yuyulmağa çatdıqda, bu, bütün IO-nun onun tərəfindən işğal edildiyini bildirir. Və bitənə qədər heç nə etməyəcəksiniz.
Bu hesabatın əhatə dairəsindən kənarda qalan daha iki mühüm məqam var. Bu parametrlər postgresql.conf-dakı parametrlərə, yəni yoxlama nöqtələrinin parametrlərinə uyğun olmalıdır. Və disk sisteminiz adekvat şəkildə konfiqurasiya edilməlidir. Əgər RAID-də bir önbelleğiniz varsa, onda onun batareyası olmalıdır. İnsanlar batareyasız yaxşı keş ilə RAID alırlar. RAID-də bir SSD varsa, onlar server olmalıdır, kondansatörlər olmalıdır. Budur genişləndirilmiş yoxlama siyahısı. Bu linkdə PostgreSQL-də disk performansını necə qurmaq barədə hesabatım var. Bütün bu yoxlama siyahıları var.
Başqa nə həyatı çox çətinləşdirə bilər? Bunlar iki variantdır. Onlar nisbətən yenidir. Varsayılan olaraq, onlar müxtəlif proqramlara daxil edilə bilər. Və onlar səhv işə salındıqda həyatı çətinləşdirə bilər.
İki nisbətən yeni parça var. Onlar artıq üçüncü nüvələrdə peyda olublar. Bunlar nanosaniyədə sched_migration_cost və defolt olaraq bir olan sched_autogroup_enabled-dir.
Və həyatı necə məhv edirlər? planlı_köçmə_qiyməti nədir? Linux planlaşdırıcısı prosesi bir CPU-dan digərinə köçürə bilər. Sorğuları yerinə yetirən PostgreSQL üçün başqa CPU-ya köçmək niyə tamamilə anlaşılmazdır. Əməliyyat sistemi nöqteyi-nəzərindən, pəncərələri openoffice və terminal arasında dəyişdiyiniz zaman bu, yaxşı ola bilər, lakin verilənlər bazası üçün - çox pisdir. Buna görə də, ağlabatan siyasət migration_cost-u ən azı bir neçə min nanosaniyə kimi böyük dəyərə təyin etməkdir.
Bu planlayıcı üçün nə demək olacaq? Güman ediləcək ki, bu müddət ərzində bu proses hələ də qaynar. Yəni, uzun müddət bir şey edən bir növ uzun əməliyyatınız varsa, planlaşdırıcı bunu başa düşəcəkdir. O, güman edəcək ki, bu müddət bitənə qədər bu prosesin heç bir yerə köçürülməsinə ehtiyac yoxdur. Eyni zamanda proses bir şey edərsə, o zaman heç bir yerə köçməyəcək, ona ayrılmış CPU-da sakitcə başa çatacaq. Və nəticə əladır.
İkinci nöqtə avtoqrupdur. Müasir verilənlər bazaları ilə əlaqəli olmayan xüsusi iş yükləri üçün yaxşı bir fikir var - bu, prosesləri onların işə salındığı virtual terminal üzrə qruplaşdırmaqdır. Bəzi tapşırıqlar üçün əlverişlidir. Təcrübədə PostgreSQL tək terminaldan işləyən prefork çox prosesli sistemdir. Kilid yazıcınız, yoxlama məntəqəniz var və bütün müştəri sorğularınız hər CPU üçün bir planlaşdırıcıda qruplaşdırılıb. Bir-birinə mane olmaq və onu daha çox məşğul etmək üçün boş olanda orada birlikdə gözləyəcəklər. Bu, belə bir yük vəziyyətində tamamilə lazımsız olan bir hekayədir və buna görə də söndürülməlidir.
Həmkarım Aleksey Lesovski sadə pgbench ilə testlər etdi, burada miqrasiya_xərclərini böyüklük sırası ilə artırdı və avtoqrupu söndürdü. Pis bir dəmir parçasındakı fərq demək olar ki, 10% oldu. Postgres poçt siyahısında insanların sorğu sürətində oxşar dəyişikliklər kimi nəticələri bildirdiyi bir müzakirə var 50% təsir etdi. Belə hekayələr az deyil.
Və nəhayət, enerjiyə qənaət siyasəti haqqında. Yaxşı haldır ki, Linux indi noutbukda istifadə oluna bilər. Və ehtimal ki, batareyanı yaxşı istehlak edəcək. Amma birdən məlum olur ki, bu serverdə də ola bilər.
Üstəlik, hansısa hosterdən server icarəyə götürsəniz, “yaxşı” hosterlər sizin daha yaxşı performans göstərdiyinizə əhəmiyyət vermirlər. Onların vəzifəsi dəmirin mümkün qədər səmərəli istifadə olunmasını təmin etməkdir. Buna görə, standart olaraq, əməliyyat sistemində laptopun enerjiyə qənaət rejimini yandıra bilərlər.
Əgər siz bunu çox yüklənmiş verilənlər bazası serverində istifadə edirsinizsə, onda sizin seçiminiz acpi_cpufreq + permormance-dir. Tələb olsa belə, artıq problemlər olacaq.
Intel_pstate bir az fərqli sürücüdür. İndi daha sonrakı və daha yaxşı işləyən birinə üstünlük verilir.
Və buna görə qubernator yalnız performansdır. Ondemand, powersave və hər şey - bu sizə aid deyil.
Əgər enerji qənaətini aktivləşdirsəniz, PostgreSQL-in izahlı təhlilinin nəticələri bir neçə böyüklük sırası ilə fərqlənə bilər, çünki praktikada CPU-nun verilənlər bazası altında tamamilə gözlənilməz şəkildə tökülməsinə səbəb olacaqsınız.
Bu şeylər standart olaraq aktivləşdirilə bilər. Defolt olaraq aktiv olub-olmadığını görmək üçün diqqətlə baxın. Bu, həqiqətən böyük problem ola bilər.
Və sonda mən PosgreSQL-Consulting DBA komandamızın uşaqlara, yəni Maks Boguk və Aleksey Lesovskiyə təşəkkür etmək istədim ki, onlar hər gün bu işdə təpələri doldururlar. Müştərilərimiz üçün isə biz ən yaxşısını etməyə çalışırıq ki, hər şey onların xeyrinə olsun. Bu, aviasiya təhlükəsizliyi təlimatlarına bənzəyir. Burada hər şey qanla yazılıb. Bu qoz-fındıqların hər biri bir növ problem prosesində aşkar edilir. Onları sizinlə bölüşməkdən məmnunam.
Suallar:
Çox sağ ol! Məsələn, bir şirkət pula qənaət etmək və verilənlər bazası və proqram məntiqini eyni serverdə yerləşdirmək istəyirsə və ya şirkət PostgreSQL-in konteynerdə işlədiyi mikroservis arxitekturalarının moda trendini izləyirsə. Nə mənası var? Sysctl qlobal olaraq bütün nüvəyə təsir göstərir. Mən eşitməmişəm ki, sysctl bir növ virtuallaşdırılıb ki, onlar konteynerdə ayrıca işləyirlər. Yalnız qrup var və onun yalnız bir hissəsi nəzarətə malikdir. Bununla necə yaşaya bilərsən? Və ya performans istəyirsinizsə, PostgreSQL-i ayrıca dəmir serverdə işlədin və onu tənzimləyin?
Sualınıza təxminən üç şəkildə cavab verdik. Əgər biz sazlana bilən bir dəmir serverdən danışmırıqsa və s., onda rahatlayın, bu parametrlər olmadan hər şey yaxşı işləyəcək. Əgər sizdə elə bir yük varsa ki, bu parametrləri etmək lazımdır, o zaman dəmir serverə bu parametrlərdən daha tez gələcəksiniz.
Problem nədir? Bu virtual maşındırsa, çox güman ki, bir çox probleminiz olacaq, məsələn, virtual maşınların əksəriyyətində kifayət qədər uyğun olmayan disk gecikməsi var. Disk ötürmə qabiliyyəti yaxşı olsa belə, yoxlama nöqtəsi zamanı və ya WAL-a yazarkən baş verən orta ötürmə qabiliyyətinə çox təsir etməyən tək uğursuz I/O əməliyyatı, verilənlər bazası bundan çox zərər görəcək. Və bu problemlərlə qarşılaşmadan əvvəl bunu görəcəksiniz.
Eyni serverdə NGINX varsa, siz də eyni problemlə üzləşəcəksiniz. O, ortaq yaddaş uğrunda mübarizə aparacaq. Və burada təsvir olunan problemlərə çata bilməyəcəksiniz.
Ancaq digər tərəfdən, bu parametrlərdən bəziləri hələ də sizin üçün aktual olacaq. Məsələn, sysctl ilə dirty_ratio təyin edin ki, o qədər də dəli olmasın - hər halda, bu kömək edəcək. Bu və ya digər şəkildə disklə qarşılıqlı əlaqəniz olacaq. Və səhv olacaq. Bu, ümumiyyətlə göstərdiyim parametrlərin standartıdır. Və hər halda, onları dəyişdirmək daha yaxşıdır.
Və NUMA ilə problemlər ola bilər. Məsələn, VmWare tam əks parametrlərlə NUMA ilə yaxşı işləyir. Və burada seçmək lazımdır - dəmir server və ya dəmir olmayan.
Amazon AWS ilə bağlı sualım var. Onların əvvəlcədən konfiqurasiya edilmiş şəkilləri var. Onlardan biri Amazon RDS adlanır. Onların əməliyyat sistemi üçün hər hansı fərdi parametrlər varmı?
Parametrlər var, lakin onlar fərqli parametrlərdir. Burada verilənlər bazasının bu biznesdən necə istifadə edəcəyi baxımından əməliyyat sistemini konfiqurasiya edirik. Və indi hara getməli olduğumuzu müəyyən edən parametrlər var, belə bir formalaşdırma. Yəni bizə o qədər resurs lazımdır ki, indi onları yeyəcəyik. Bundan sonra Amazon RDS bu resursları bağlayır və performans orada aşağı düşür. İnsanların bu məsələ ilə kimyaya necə başladığına dair ayrı-ayrı hekayələr var. Bəzən hətta olduqca uğurla. Ancaq bunun OS parametrləri ilə heç bir əlaqəsi yoxdur. Bu, buludların sındırılması kimidir. Bu fərqli hekayədir.
Nə üçün Şəffaf nəhəng səhifələrin Böyük TLB ilə müqayisədə heç bir təsiri yoxdur?
vermə. Bunu bir çox cəhətdən izah etmək olar. Amma əslində, sadəcə, vermirlər. PostgreSQL-in tarixi nədir? Başlanğıcda o, paylaşılan yaddaşın böyük bir hissəsini ayırır. Şəffaf onlar eyni zamanda və ya şəffaf deyil - heç bir əhəmiyyəti yoxdur. Onların başlanğıcda fərqlənmələri hər şeyi izah edir. Yaddaş çox olarsa və paylaşılan_yaddaş seqmentini yenidən qurmaq lazımdırsa, o zaman Şəffaf nəhəng səhifələr aktual olacaq. PostgreSQL-də o, sadəcə başlanğıcda nəhəng bir parça ilə vurğulanır və bu qədərdir, sonra orada xüsusi heç nə baş vermir. Siz, əlbəttə ki, ondan istifadə edə bilərsiniz, lakin bir şeyi yenidən ayırdıqda, paylaşılan_yaddaşın kəsilməsini əldə etmək şansı var. PostgreSQL-in bundan xəbəri yoxdur.
Mənbə: www.habr.com