Vyladenie Linuxu na zlepšenie výkonu PostgreSQL. Iľja Kosmodemjanskij

Prepis správy Ilju Kosmodemyanského z roku 2015 „Ladenie Linuxu na zlepšenie výkonu PostgreSQL“

Upozornenie: Beriem na vedomie, že táto správa je z novembra 2015 – prešli viac ako 4 roky a prešlo veľa času. Verzia 9.4, o ktorej sa hovorí v správe, už nie je podporovaná. Za posledné 4 roky bolo vydaných 5 nových verzií PostgreSQL a 15 verzií linuxového jadra. Ak tieto pasáže prepíšete, dostanete inú správu. Tu však zvažujeme zásadné ladenie Linuxu pre PostgreSQL, ktoré je aktuálne aj dnes.

Volám sa Ilya Kosmodemyansky. Pracujem v PostgreSQL-Consulting. A teraz poviem trochu o tom, čo robiť s Linuxom vo vzťahu k databázam všeobecne a PostgreSQL konkrétne, pretože princípy sú dosť podobné.

O čom sa budeme baviť? Ak komunikujete s PostgreSQL, tak do určitej miery musíte byť UNIX admin. Čo to znamená? Ak porovnáme Oracle a PostgreSQL, tak v Oracle musíte byť 80% DBA admin databázy a 20% Linux admin.

S PostgreSQL je to trochu komplikovanejšie. S PostgreSQL potrebujete oveľa lepšie pochopiť, ako Linux funguje. A zároveň sa trošku rozbehnúť za rušňom, lebo v poslednom čase sa všetko celkom pekne zaktualizovalo. A vydávajú sa nové jadrá a objavujú sa nové funkcie, zlepšuje sa výkon atď.

Prečo hovoríme o Linuxe? Ani nie preto, že sme na linuxovej konferencii Peter, ale preto, že v moderných podmienkach je jedným z najoprávnenejších operačných systémov na používanie databáz všeobecne a PostgreSQL zvlášť Linux. Pretože FreeBSD sa, žiaľ, vyvíja nejakým veľmi zvláštnym smerom. A budú problémy ako s výkonom, tak aj s mnohými inými vecami. Výkon PostgreSQL v systéme Windows je vo všeobecnosti samostatný závažný problém, založený na skutočnosti, že Windows nemá rovnakú zdieľanú pamäť ako UNIX, zatiaľ čo PostgreSQL je s tým spojený, pretože ide o viacprocesový systém.

A myslím, že každého menej zaujíma exotika ako Solaris, tak poďme na to.

Moderná distribúcia Linuxu má viac ako 1 000 možností syctl v závislosti od toho, ako zostavujete jadro. Zároveň, ak sa pozrieme na rôzne oriešky, môžeme si niečo upraviť na mnoho spôsobov. Existujú parametre súborového systému, ako ich pripojiť. Ak máte otázky o tom, ako ho spustiť: čo povoliť v systéme BIOS, ako nakonfigurovať hardvér atď.

Toto je veľmi veľký objem, o ktorom sa dá diskutovať počas niekoľkých dní a nie v jednej krátkej správe, ale teraz sa zameriam na dôležité veci, ako sa vyhnúť tým rakom, ktoré vám zaručene zabránia v správnom používaní databázy v systéme Linux, ak neopravujte ich. A zároveň dôležitým bodom je, že mnohé predvolené parametre nie sú zahrnuté v nastaveniach, ktoré sú pre databázu správne. To znamená, že štandardne bude fungovať zle alebo vôbec.

Aké tradičné ciele ladenia existujú v systéme Linux? Myslím si, že keďže sa všetci zaoberáte správou Linuxu, nie je potrebné zvlášť vysvetľovať, čo sú ciele.

Môžete naladiť:

• CPU.
• Pamäť.
• Storage.
• Iné. O tom si povieme na konci pri občerstvení. Aj napríklad parametre ako politika úspory energie môžu ovplyvniť výkon veľmi nepredvídateľným a nie práve najpríjemnejším spôsobom.

Aké sú špecifiká PostgreSQL a databázy všeobecne? Problém je v tom, že nemôžete vyladiť žiadnu individuálnu maticu a uvidíte, že sa náš výkon výrazne zlepšil.

Áno, existujú také vychytávky, ale databáza je zložitá vec. Interaguje so všetkými zdrojmi, ktoré server má, a uprednostňuje maximálnu interakciu. Ak sa pozriete na aktuálne odporúčania Oracle, ako používať hostiteľský OS, bude to ako vtip o tom mongolskom kozmonautovi – nakŕmte psa a ničoho sa nedotýkajte. Dajme databáze všetky zdroje, databáza sama všetko vyrieši.

V princípe je situácia do istej miery úplne rovnaká s PostgreSQL. Rozdiel je v tom, že databáza ešte nie je schopná vziať si všetky zdroje pre seba, t.j. niekde na úrovni Linuxu si to musíte všetko vyriešiť sami.

Hlavnou myšlienkou nie je vybrať jeden cieľ a začať ho ladiť, napríklad pamäť, CPU alebo niečo podobné, ale analyzovať záťaž a pokúsiť sa čo najviac zlepšiť priepustnosť tak, aby záťaž, ktorú dobrí programátori vytvorili, pre nás vrátane našich používateľov.

Tu je obrázok, ktorý vysvetľuje, čo to je. Existuje vyrovnávacia pamäť OS Linux a zdieľaná pamäť a zdieľané vyrovnávacie pamäte PostgreSQL. PostgreSQL na rozdiel od Oracle funguje priamo iba cez vyrovnávaciu pamäť jadra, teda aby sa stránka z disku dostala do jej zdieľanej pamäte, musí prejsť cez vyrovnávaciu pamäť jadra a späť, presne tá istá situácia.

Disky žijú pod týmto systémom. Nakreslil som to ako disky. V skutočnosti môže existovať radič RAID atď.

A tento vstup-výstup sa tak či onak deje prostredníctvom tejto hmoty.

PostgreSQL je klasická databáza. Vnútri je stránka. A všetok vstup a výstup prebieha pomocou stránok. Vytvárame bloky do pamäte pomocou stránok. A ak sa nič nestalo, len si ich prečítame, potom postupne miznú z tejto vyrovnávacej pamäte, zo zdieľaných vyrovnávacích pamätí a skončia späť na disku.

Ak niekde niečo nahradíme, potom je celá stránka označená ako špinavá. Tu som ich označil modrou farbou. A to znamená, že táto stránka musí byť synchronizovaná s blokovým ukladaním. To znamená, že keď sme to zašpinili, urobili sme záznam vo WAL. A v nejakom nádhernom okamihu prišiel fenomén nazývaný kontrolný bod. A v tomto denníku bola zaznamenaná informácia, že prišiel. A to znamená, že všetky nečisté stránky, ktoré tu boli v tom momente v týchto zdieľaných vyrovnávacích pamätiach, boli synchronizované s úložným diskom pomocou fsync cez vyrovnávaciu pamäť jadra.

Prečo sa to robí? Ak sme stratili napätie, nedostali sme sa do situácie, že by sa stratili všetky dáta. Perzistentná pamäť, o ktorej nám každý hovoril, je zatiaľ v teórii databáz - to je svetlá budúcnosť, o ktorú sa, samozrejme, snažíme a páči sa nám to, ale zatiaľ žijú v mínus 20 rokoch. A toto všetko je samozrejme potrebné sledovať.

A úlohou maximalizácie priepustnosti je doladiť všetky tieto fázy tak, aby sa to všetko rýchlo pohybovalo tam a späť. Zdieľaná pamäť je v podstate vyrovnávacia pamäť stránok. V PostgreSQL sme poslali výberový dotaz alebo niečo také, načítalo tieto údaje z disku. Skončili v zdieľaných nárazníkoch. Preto, aby to fungovalo lepšie, musí existovať veľa pamäte.

Aby to všetko fungovalo dobre a rýchlo, musíte správne nakonfigurovať operačný systém vo všetkých fázach. A voľte vyvážený hardvér, pretože ak máte na niektorom mieste nerovnováhu, môžete zarobiť veľa pamäte, ale nebude obsluhovaná dostatočnou rýchlosťou.

A prejdime si každý z týchto bodov.

Aby sa tieto stránky pohybovali tam a späť rýchlejšie, musíte dosiahnuť nasledovné:

• Po prvé, musíte efektívnejšie pracovať s pamäťou.
• Po druhé, tento prechod pri prechode stránok z pamäte na disk by mal byť efektívnejší.
• A do tretice musia byť dobré disky.

Ak máte na serveri 512 GB RAM a všetko skončí na pevnom disku SATA bez vyrovnávacej pamäte, potom sa celý databázový server zmení nielen na tekvicu, ale aj na tekvicu s rozhraním SATA. Narazíte priamo na to. A nič ťa nezachráni.

Pokiaľ ide o prvý bod s pamäťou, existujú tri veci, ktoré môžu veľmi sťažiť život.

Prvým z nich je NUMA. NUMA je vec, ktorá je vytvorená na zlepšenie výkonu. V závislosti od pracovného zaťaženia je možné optimalizovať rôzne veci. A vo svojej novej súčasnej podobe nie je veľmi dobrý pre aplikácie, ako sú databázy, ktoré intenzívne využívajú zdieľané vyrovnávacie pamäte cache stránok.

Stručne. Ako zistíte, že s NUMA nie je niečo v poriadku? Máte nejaké nepríjemné klepanie, zrazu je nejaký CPU preťažený. Zároveň analyzujete dopyty v PostgreSQL a vidíte, že tam nič podobné nie je. Tieto dotazy by nemali byť také náročné na CPU. Toto môžete chytiť dlho. Je jednoduchšie použiť správne odporúčanie od samého začiatku, ako nakonfigurovať NUMA pre PostgreSQL.

Čo sa to vlastne deje? NUMA znamená Non-Uniform Memory Access. Aký to má zmysel? Máte CPU, vedľa neho je jeho lokálna pamäť. A toto prepojenie pamäte môže vytiahnuť pamäť z iných CPU.

Ak bežíte numactl --hardware, potom vám vznikne taký veľký list. Okrem iného tam bude dištančné ihrisko. Budú tam čísla - 10-20, niečo také. Tieto čísla nie sú nič iné ako počet skokov na vyzdvihnutie tejto vzdialenej pamäte a jej lokálne použitie. V princípe dobrý nápad. To výrazne zrýchľuje výkon pri rôznych pracovných zaťaženiach.

Teraz si predstavte, že máte jeden procesor, ktorý sa najprv pokúša použiť svoju lokálnu pamäť a potom sa pokúša získať ďalšiu pamäť cez prepojenie pre niečo. A tento procesor dostane celú vyrovnávaciu pamäť stránok PostgreSQL – to je všetko, niekoľko gigabajtov. Vždy dostanete ten najhorší prípad, pretože na CPU je zvyčajne málo pamäte v samotnom module. A všetka pamäť, ktorá je obsluhovaná, prechádza cez tieto prepojenia. Ukazuje sa to pomaly a smutne. A váš procesor, ktorý obsluhuje tento uzol, je neustále preťažený. A prístupová doba tejto pamäte je zlá, pomalá. Toto je situácia, ktorú nechcete, ak ju používate pre databázu.

Preto je správnejšia možnosť pre databázu, aby operačný systém Linux vôbec nevedel, čo sa tam deje. Takže pristupuje k pamäti tak, ako má.

prečo je to tak? Zdalo by sa, že by to malo byť naopak. Deje sa to z jednoduchého dôvodu: na vyrovnávaciu pamäť stránok potrebujeme veľa pamäte – desiatky, stovky gigabajtov.

A ak by sme toto všetko alokovali a uložili tam naše údaje do vyrovnávacej pamäte, potom zisk z používania vyrovnávacej pamäte bude výrazne väčší ako zisk z takéhoto zložitého prístupu do pamäte. A vyťažíme tak neporovnateľne v porovnaní s tým, že k pamäti budeme pristupovať efektívnejšie pomocou NUMA.

Preto sú tu momentálne dva prístupy, kým nepríde svetlá budúcnosť a samotná databáza nie je schopná zistiť, na ktorých CPU beží a odkiaľ niečo potrebuje ťahať.

Preto je správny prístup úplne zakázať NUMA, napríklad pri reštarte. Vo väčšine prípadov sú výhry takých rádových hodnôt, že otázka, ktorá je lepšia, vôbec nevzniká.

Existuje aj iná možnosť. Používame ho častejšie ako ten prvý, pretože keď k nám klient príde požiadať o podporu, reštartovanie servera je preňho veľký problém. Má tam živnosť. A majú problémy kvôli NUMA. Preto sa ho snažíme deaktivovať menej invazívnymi spôsobmi ako reštartom, ale buďte opatrní a skontrolujte, či je deaktivovaný. Pretože, ako ukazujú skúsenosti, je dobré, že deaktivujeme NUMA v nadradenom procese PostgreSQL, ale nie je vôbec potrebné, aby to fungovalo. Musíme skontrolovať a zistiť, že sa naozaj vypla.

Je tu dobrý príspevok od Roberta Haasa. Toto je jeden z autorov PostgreSQL. Jeden z kľúčových vývojárov všetkých drobov nízkej úrovne. A ak budete nasledovať odkazy z tohto príspevku, popisujú niekoľko pestrých príbehov o tom, ako NUMA skomplikovala život ľuďom. Pozrite sa, preštudujte si kontrolný zoznam správcu systému, čo je potrebné nakonfigurovať na serveri, aby naša databáza dobre fungovala. Tieto nastavenia si treba zapísať a skontrolovať, pretože inak to nebude veľmi dobré.

Upozorňujeme, že to platí pre všetky nastavenia, o ktorých budem hovoriť. Zvyčajne sa však databázy zhromažďujú v režime master-slave kvôli odolnosti voči chybám. Nezabudnite vykonať tieto nastavenia na slave, pretože jedného dňa budete mať nehodu a prepnete sa na slave a ten sa stane pánom.

V núdzovej situácii, keď je všetko veľmi zlé, váš telefón neustále zvoní a váš šéf pribehne s veľkou palicou, nebudete mať čas premýšľať nad kontrolou. A výsledky môžu byť dosť katastrofálne.

Ďalším bodom sú obrovské stránky. Obrovské stránky sa ťažko testujú samostatne a nemá zmysel to robiť, hoci existujú benchmarky, ktoré to dokážu. Sú jednoduché na Google.

Aký to má zmysel? Máte nie veľmi drahý server s množstvom pamäte RAM, napríklad viac ako 30 GB. Nepoužívate veľké stránky. To znamená, že určite máte réžiu, pokiaľ ide o využitie pamäte. A táto réžia nie je ani zďaleka najpríjemnejšia.

prečo je to tak? Tak čo sa deje? Operačný systém rozdeľuje pamäť na malé kúsky. Je to také pohodlné, tak sa to stalo historicky. A ak ideme do detailov, OS musí prekladať virtuálne adresy na fyzické. A tento proces nie je najjednoduchší, takže OS ukladá výsledok tejto operácie do vyrovnávacej pamäte Translation Lookaside Buffer (TLB).

A keďže TLB je vyrovnávacia pamäť, v tejto situácii vznikajú všetky problémy súvisiace s vyrovnávacou pamäťou. Po prvé, ak máte veľa pamäte RAM a všetko je alokované v malých častiach, potom sa táto vyrovnávacia pamäť stane veľmi veľkou. A ak je vyrovnávacia pamäť veľká, vyhľadávanie v nej je pomalšie. Réžia je zdravá a sama zaberá miesto, t.j. RAM je spotrebovaná niečím nesprávnym. Tentokrát.

Po druhé – čím viac cache v takejto situácii rastie, tým je pravdepodobnejšie, že budete mať cache miss. A účinnosť tejto vyrovnávacej pamäte rapídne klesá so zväčšovaním jej veľkosti. Operačné systémy preto prišli s jednoduchým prístupom. V Linuxe sa používa už dlho. Vo FreeBSD sa objavil nie tak dávno. Ale bavíme sa o Linuxe. Toto sú obrovské stránky.

A tu treba poznamenať, že obrovské stránky ako nápad pôvodne presadzovali komunity, ktoré zahŕňali Oracle a IBM, t. j. výrobcovia databáz si silne mysleli, že by to bolo užitočné aj pre databázy.

A ako sa to dá spriateliť s PostgreSQL? Po prvé, veľké stránky musia byť povolené v jadre Linuxu.

Po druhé, musia byť explicitne špecifikované parametrom sysctl - koľko ich je. Čísla tu sú z nejakého starého servera. Môžete si vypočítať, koľko zdieľaných vyrovnávacích pamätí máte, aby sa tam zmestili obrovské stránky.

A ak je celý váš server vyhradený pre PostgreSQL, potom je dobrým východiskovým bodom alokovať buď 25 % pamäte RAM do zdieľaných vyrovnávacích pamätí, alebo 75 %, ak ste si istí, že vaša databáza sa do týchto 75 % určite zmestí. Východiskový bod jedna. A zvážte, ak máte 256 GB RAM, potom budete mať 64 GB veľkých vyrovnávacích pamätí. Vypočítajte približne s určitou rezervou - na čo by mal byť tento údaj nastavený.

Pred verziou 9.2 (ak sa nemýlim, od verzie 8.2) bolo možné prepojiť PostgreSQL s obrovskými stránkami pomocou knižnice tretích strán. A to by sa malo robiť vždy. Najprv potrebujete jadro, aby bolo schopné správne alokovať veľké stránky. A po druhé, aby ich mohla používať aplikácia, ktorá s nimi pracuje. Nebude sa používať len tak. Keďže PostgreSQL alokoval pamäť v štýle system 5, dalo by sa to urobiť pomocou libhugetlbfs - toto je úplný názov knižnice.

Vo verzii 9.3 sa zlepšil výkon PostgreSQL pri práci s pamäťou a metóda prideľovania pamäte systému 5 bola opustená. Všetci boli veľmi spokojní, pretože inak sa pokúsite spustiť dve inštancie PostgreSQL na jednom počítači a on hovorí, že nemám dostatok zdieľanej pamäte. A hovorí, že sysctl treba opraviť. A je tam taký sysctl, že stále potrebujete reštartovať atď. Vo všeobecnosti boli všetci spokojní. Ale alokácia pamäte mmap prelomila používanie veľkých stránok. Väčšina našich klientov používa veľké zdieľané vyrovnávacie pamäte. A dôrazne sme odporúčali neprechádzať na 9.3, lebo tam sa réžia začala počítať v dobrých percentách.

Komunita ale venovala pozornosť tomuto problému a v 9.4 túto akciu veľmi dobre prepracovala. A v 9.4 sa v postgresql.conf objavil parameter, v ktorom môžete povoliť vyskúšať, zapnúť alebo vypnúť.

Vyskúšať je najbezpečnejšia možnosť. Keď sa PostgreSQL spustí, keď pridelí zdieľanú pamäť, pokúsi sa získať túto pamäť z veľkých stránok. A ak to nefunguje, vráti sa späť k normálnemu výberu. A ak máte FreeBSD alebo Solaris, môžete to skúsiť, je to vždy bezpečné.

Ak je zapnuté, potom sa jednoducho nespustí, ak si nemohol vybrať z veľkých stránok. Tu už ide o to, kto a čo je krajšie. Ak to však máte, skontrolujte, či máte naozaj zvýraznené to, čo potrebujete, pretože je tu veľký priestor na chyby. V súčasnosti táto funkcia funguje iba v systéme Linux.

Ešte malá poznámka predtým, ako pôjdeme ďalej. Transparentné obrovské stránky ešte nie sú o PostgreSQL. Nemôže ich normálne používať. A s transparentnými obrovskými stránkami pre takéto pracovné zaťaženie, keď je potrebný veľký kus zdieľanej pamäte, výhody prichádzajú len s veľmi veľkými objemami. Ak máte terabajty pamäte, môže to prísť do hry. Ak hovoríme o každodennejších aplikáciách, keď máte vo svojom počítači 32, 64, 128, 256 GB pamäte, potom sú obvyklé veľké stránky v poriadku a jednoducho zakážeme priehľadnosť.

A posledná vec o pamäti nesúvisí priamo s ovocím, môže vám skutočne zničiť život. Všetka priepustnosť bude výrazne ovplyvnená skutočnosťou, že server neustále swapuje.

A to bude v mnohých smeroch veľmi nepríjemné. A hlavným problémom je, že moderné jadrá sa správajú trochu inak ako staršie linuxové jadrá. A táto vec je dosť nepríjemná na prešľap, pretože keď sa bavíme o nejakej práci so swapom, tá končí predčasným príchodom OOM-killera. A nepríjemný je aj OOM-killer, ktorý neprišiel včas a zahodil PostgreSQL. Každý o tom bude vedieť, teda až do posledného používateľa.

Čo sa deje? Máte tam veľké množstvo RAM, všetko funguje dobre. Ale z nejakého dôvodu server visí vo swape a kvôli tomu sa spomalí. Zdalo by sa, že je tam veľa pamäte, ale to sa stáva.

Predtým sme odporúčali nastaviť vm.swappiness na nulu, teda vypnúť swap. Predtým sa zdalo, že 32 GB RAM a zodpovedajúce zdieľané vyrovnávacie pamäte sú obrovské množstvo. Hlavným účelom swapu je mať kam odhodiť kôrku, ak odpadneme. A už sa to nejako zvlášť nenapĺňalo. A čo potom urobíte s touto kôrou? Toto je úloha, pri ktorej nie je veľmi jasné, prečo je potrebný swap, najmä takej veľkosti.

Ale v modernejších, t. j. tretích verziách jadra, sa správanie zmenilo. A ak swap nastavíte na nulu, čiže ho vypnete, tak skôr či neskôr, aj keď tam ešte nejaká RAM zostane, príde k vám OOM zabijak, ktorý zabije tých najintenzívnejších konzumentov. Pretože zváži, že pri takom vyťažení nám ešte kúsok zostáva a vyskočíme, teda nie zaklincovať systémový proces, ale zaklincovať niečo menej dôležité. Tento menej dôležitý bude intenzívnym konzumentom zdieľanej pamäte, menovite vedúci pošty. A potom bude dobré, ak sa základňa nebude musieť obnoviť.

Preto je teraz predvolená hodnota, pokiaľ si pamätám, väčšina distribúcií niekde okolo 6, t.j. v akom bode by ste mali začať používať swap v závislosti od toho, koľko pamäte zostáva. Teraz odporúčame nastaviť vm.swappiness = 1, pretože to prakticky vypne, ale nedáva rovnaké efekty ako s OOM-killerom, ktorý nečakane dorazil a celú vec zabil.

Čo bude ďalej? Keď sa bavíme o výkone databáz a postupnom prechode k diskom, každý sa začne chytať za hlavu. Pretože pravdu, že disk je pomalý a pamäť rýchla, pozná každý z detstva. A každý vie, že databáza bude mať problémy s výkonom disku.

Hlavný problém s výkonom PostgreSQL spojený s výkyvmi kontrolných bodov sa nevyskytuje, pretože disk je pomalý. Je to pravdepodobne spôsobené tým, že pamäť a šírka pásma disku nie sú vyvážené. Na rôznych miestach však nemusia byť vyvážené. PostgreSQL nie je nakonfigurovaný, OS nie je nakonfigurovaný, hardvér nie je nakonfigurovaný a hardvér je nesprávny. A tento problém nenastane iba vtedy, ak sa všetko deje tak, ako má, teda buď nie je záťaž, alebo sú nastavenia a hardvér dobre zvolené.

Čo to je a ako to vyzerá? Zvyčajne ľudia, ktorí pracujú s PostgreSQL, vstúpili do tejto záležitosti viac ako raz. vysvetlím. Ako som už povedal, PostgreSQL pravidelne robí kontrolné body, aby vypísal špinavé stránky zo zdieľanej pamäte na disk. Ak máme veľké množstvo zdieľanej pamäte, potom začne mať checkpoint intenzívny dopad na disk, pretože tieto stránky vysype pomocou fsync. Prichádza do vyrovnávacej pamäte jadra a zapisuje sa na disky pomocou fsync. A ak je objem tohto podnikania veľký, potom môžeme pozorovať nepríjemný efekt, a to veľmi veľké využitie diskov.

Tu mám dva obrázky. Teraz vysvetlím, čo to je. Ide o dva časovo korelované grafy. Prvým grafom je využitie disku. Tu v tomto časovom bode dosahuje takmer 90 %. Ak máte zlyhanie databázy s fyzickými diskami s využitím radiča RAID na 90 %, potom je to zlá správa. To znamená, že trochu viac a dosiahne 100 a I/O sa zastaví.

Ak máte diskové pole, potom je to trochu iný príbeh. Závisí to od toho, ako je nakonfigurovaný, o aký druh poľa ide atď.

Paralelne sa tu konfiguruje graf z interného postgresového pohľadu, ktorý hovorí, ako sa kontrolný bod vyskytuje. A zelená farba tu ukazuje, koľko vyrovnávacích pamätí, týchto špinavých stránok, v tej chvíli dorazilo k tomuto kontrolnému bodu na synchronizáciu. A to je hlavná vec, ktorú tu potrebujete vedieť. Vidíme, že tu máme veľa stránok a v určitom okamihu sme narazili na tabuľu, teda písali a písali, tu je diskový systém zjavne veľmi vyťažený. A náš kontrolný bod má veľmi silný vplyv na disk. V ideálnom prípade by situácia mala vyzerať viac takto, t.j. mali sme tu menej nahrávok. A môžeme to napraviť nastaveniami, aby to tak bolo aj naďalej. To znamená, že recyklácia je malá, ale niekde tu niečo píšeme.

Čo je potrebné urobiť na prekonanie tohto problému? Ak ste zastavili IO pod databázou, znamená to, že všetci používatelia, ktorí prišli splniť svoje požiadavky, budú čakať.

Ak sa pozriete z pohľadu Linuxu, ak ste vzali dobrý hardvér, správne ho nakonfigurovali, normálne nakonfigurovali PostgreSQL tak, aby tieto kontrolné body robil menej často, rozložil ich v čase medzi sebou, potom vstúpite do predvolených parametrov Debianu. Pre väčšinu distribúcií Linuxu je to tento obrázok: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Čo to znamená? Jeden splachovací démon sa objavil z jadra 2.6. Pdglush, v závislosti od toho, kto ktorý používa, ktorý sa zaoberá vyhadzovaním špinavých stránok z vyrovnávacej pamäte jadra na pozadí a zhadzovaním, keď je potrebné zahodiť špinavé stránky bez ohľadu na to, keď zhadzovanie pozadia nepomôže.

Kedy príde pozadie? Keď 10 % z celkovej pamäte RAM dostupnej na serveri zaberajú nečisté stránky vo vyrovnávacej pamäti jadra, na pozadí sa zavolá špeciálna funkcia odpisu. Prečo je to pozadie? Ako parameter berie do úvahy, koľko strán odpísať. A povedzme, že odpíše N strán. A na chvíľu táto vec zaspí. A potom príde znova a skopíruje ďalšie strany.

Toto je mimoriadne jednoduchý príbeh. Tu je problém ako s bazénom, keď sa leje do jednej rúry, tečie do druhej. Náš kontrolný bod dorazil a ak poslal niekoľko špinavých stránok na zahodenie, postupne sa celá vec úhľadne vyrieši z vyrovnávacej pamäte jadra pgflush.

Ak sa tieto špinavé stránky naďalej hromadia, nahromadia sa až o 20%, potom je prioritou OS odpísať to celé na disk, pretože vypadne napájanie a všetko bude pre nás zlé. O tieto dáta prídeme napr.

Aký je trik? Trik je v tom, že tieto parametre v modernom svete sú 20 a 10% z celkovej pamäte RAM, ktorá je na stroji, sú úplne monštruózne, pokiaľ ide o priepustnosť akéhokoľvek diskového systému, ktorý máte.

Predstavte si, že máte 128 GB RAM. Do vášho diskového systému prichádza 12,8 GB. A bez ohľadu na to, akú vyrovnávaciu pamäť tam máte, bez ohľadu na to, aké pole tam máte, nevydržia tak dlho.

Preto odporúčame, aby ste tieto čísla okamžite upravili na základe možností vášho radiča RAID. Hneď som tu odporučil radič, ktorý má 512 MB vyrovnávacej pamäte.

Všetko sa považuje za veľmi jednoduché. Vm.dirty_background môžete vložiť v bajtoch. A tieto nastavenia zrušia predchádzajúce dve. Buď je pomer štandardne nastavený, alebo sú aktivované tie s bajtami, potom budú fungovať tie s bajtami. Ale keďže som DBA konzultant a pracujem s rôznymi klientmi, snažím sa kresliť slamky a teda ak v bajtoch, tak v bajtoch. Nikto neposkytol žiadnu záruku, že dobrý správca nepridá viac pamäte na server, nereštartuje ho a číslo zostane rovnaké. Len si spočítajte tieto čísla, aby sa tam všetko so zárukou zmestilo.

Čo sa stane, ak sa nezmestíte? Napísal som, že akékoľvek splachovanie je účinne zastavené, ale v skutočnosti je to len slovné spojenie. Operačný systém má veľký problém – má veľa špinavých stránok, takže IO, ktoré generujú vaši klienti, je efektívne zastavené, t.j. aplikácia prišla poslať sql dotaz do databázy, čaká. Akýkoľvek vstup/výstup do nej má najnižšiu prioritu, pretože databáza je obsadená kontrolným bodom. A kedy skončí, je úplne nejasné. A keď ste dosiahli splachovanie bez pozadia, znamená to, že všetky vaše IO sú ním obsadené. A kým to neskončí, neurobíte nič.

Sú tu ešte dva dôležité body, ktoré presahujú rámec tejto správy. Tieto nastavenia by sa mali zhodovať s nastaveniami v postgresql.conf, t. j. s nastaveniami kontrolných bodov. A váš diskový systém musí byť primerane nakonfigurovaný. Ak máte vyrovnávaciu pamäť na RAID, potom musí mať batériu. Ľudia kupujú RAID s dobrou vyrovnávacou pamäťou bez batérie. Ak máš SSD v RAID, tak to musia byť serverové, musia tam byť kondenzátory. Tu je podrobný kontrolný zoznam. Tento odkaz obsahuje moju správu o tom, ako nakonfigurovať výkonný disk v PostgreSQL. Sú tam všetky tieto kontrolné zoznamy.

Čo ešte môže veľmi skomplikovať život? Toto sú dva parametre. Sú relatívne nové. Štandardne môžu byť zahrnuté v rôznych aplikáciách. A rovnako môžu sťažiť život, ak sú nesprávne zapnuté.

Existujú dve relatívne nové veci. Objavili sa už v tretích jadrách. Toto je sched_migration_cost v nanosekundách a sched_autogroup_enabled, čo je predvolene jedna.

A ako ti ničia život? Čo je to sched_migration_cost? V systéme Linux môže plánovač migrovať proces z jedného CPU na druhý. A pre PostgreSQL, ktorý vykonáva dotazy, je migrácia na iný CPU úplne nejasná. Z pohľadu operačného systému, keď prepínate okná medzi openoffice a terminálom, môže to byť dobré, ale pre databázu je to veľmi zlé. Preto je rozumnou politikou nastaviť migračné náklady na nejakú veľkú hodnotu, aspoň niekoľko tisíc nanosekúnd.

Čo to bude znamenať pre plánovač? Uvažuje sa, že počas tejto doby je proces stále horúci. To znamená, že ak máte dlhotrvajúcu transakciu, ktorá už dlho niečo robí, plánovač to pochopí. Bude predpokladať, že kým tento časový limit neuplynie, nie je potrebné tento proces nikam migrovať. Ak zároveň proces niečo urobí, nebude nikam migrovaný, bude ticho pracovať na CPU, ktoré mu bolo pridelené. A výsledok je výborný.

Druhým bodom je automatické zoskupenie. Je to dobrý nápad pre špecifické pracovné zaťaženia, ktoré nesúvisia s modernými databázami – ide o zoskupenie procesov podľa virtuálneho terminálu, z ktorého sa spúšťajú. To je vhodné pre niektoré úlohy. V praxi je PostgreSQL viacprocesový systém s preforkom, ktorý beží z jedného terminálu. Máte zapisovač zámkov, kontrolný bod a všetky vaše požiadavky klientov budú zoskupené do jedného plánovača na procesor. A budú tam svorne čakať, kým bude voľný, aby sa navzájom rušili a dlhšie ho zamestnávali. Ide o príbeh, ktorý je v prípade takejto záťaže úplne zbytočný a preto ho treba vypnúť.

Môj kolega Alexey Lesovsky robil testy s jednoduchým pgbench, kde rádovo zvýšil Migration_cost a vypol autogroup. Rozdiel na zlom hardvéri bol takmer 10%. Na postgresovom mailing liste je diskusia, kde ľudia dávajú výsledky podobných zmien rýchlosti dotazov ovplyvnený 50%. Takýchto príbehov je pomerne veľa.

A nakoniec o politike úspory energie. Dobrá vec je, že Linux je teraz možné použiť na notebooku. A vraj dobre vybije batériu. Ale zrazu sa ukáže, že sa to môže stať aj na serveri.

Navyše, ak si prenajímate servery od nejakého hostiteľa, tak „dobrým“ hostiteľom je jedno, že máte lepší výkon. Ich úlohou je zabezpečiť, aby sa ich železo využívalo čo najefektívnejšie. Preto môžu v predvolenom nastavení povoliť režim úspory energie notebooku v operačnom systéme.

Ak používate tieto veci na serveri s databázou pod veľkým zaťažením, potom je vaša voľba acpi_cpufreq + permormance. Dokonca aj s dopytom budú problémy.

Intel_pstate je trochu iný ovládač. A teraz sa dáva prednosť tomuto, pretože je neskôr a funguje lepšie.

A preto je guvernér iba výkon. Ondemand, powersave a všetko ostatné nie je o vás.

Výsledky vysvetľujúcej analýzy PostgreSQL sa môžu líšiť o niekoľko rádov, ak povolíte úsporu energie, pretože prakticky CPU pod vašou databázou bude bežať úplne nepredvídateľným spôsobom.

Tieto položky môžu byť zahrnuté v predvolenom nastavení. Pozorne sa pozrite, či ho predvolene zapli. To môže byť naozaj veľký problém.

A na záver by som sa chcel poďakovať chalanom z nášho PosgreSQL-Consulting DBA tímu, menovite Maxovi Bogukovi a Alexeyovi Lesovskému, ktorí v tejto veci robia pokroky každý deň. A snažíme sa pre našich klientov robiť to najlepšie, čo vieme, aby im to všetko klapalo. Je to ako s bezpečnostnými pokynmi v letectve. Všetko je tu napísané krvou. Každý z týchto orechov sa nachádza v procese nejakého problému. Rád sa o ne s vami podelím.

Otázky:

Ďakujem! Ak chce napríklad firma ušetriť peniaze a umiestniť databázovú a aplikačnú logiku na jeden server, alebo ak firma nasleduje módny trend mikroservisných architektúr, v ktorých PostgreSQL beží v kontajneri. Aký je trik? Sysctl ovplyvní globálne celé jadro. Nepočul som o tom, že by sysctls boli nejako virtualizované, aby fungovali oddelene na kontajneri. Je tam len cgroup a tam je len časť ovládacieho prvku. Ako s tým môžeš žiť? Alebo ak chcete výkon, spustite PostgreSQL na samostatnom hardvérovom serveri a vylaďte ho?

Na vašu otázku sme odpovedali asi tromi spôsobmi. Ak nehovoríme o hardvérovom serveri, ktorý je možné vyladiť atď., Potom sa upokojte, všetko bude fungovať bez týchto nastavení. Ak máte také zaťaženie, že potrebujete vykonať tieto nastavenia, prídete na server železa skôr ako na tieto nastavenia.

Aký je problém? Ak ide o virtuálny počítač, pravdepodobne budete mať veľa problémov, napríklad s tým, že na väčšine virtuálnych počítačov je latencia disku dosť nekonzistentná. Aj keď je priepustnosť disku dobrá, potom jedna neúspešná I/O transakcia, ktorá výrazne neovplyvní priemernú priepustnosť, ku ktorej došlo v čase kontrolného bodu alebo v čase zápisu do WAL, tým bude databáza značne trpieť. A všimnete si to skôr, ako narazíte na tieto problémy.

Ak máte NGINX na rovnakom serveri, budete mať tiež rovnaký problém. Bude bojovať o spoločnú pamäť. A nedostanete sa k problémom, ktoré sú tu opísané.

Ale na druhej strane, niektoré z týchto parametrov budú pre vás stále relevantné. Napríklad nastavte dirty_ratio pomocou sysctl, aby to nebolo také šialené - v každom prípade to pomôže. Tak či onak, budete mať interakciu s diskom. A bude to podľa nesprávneho vzoru. Toto je vo všeobecnosti predvolené nastavenie pre parametre, ktoré som ukázal. A v každom prípade je lepšie ich zmeniť.

Môžu sa však vyskytnúť problémy s NUMA. VmWare napríklad funguje dobre s NUMA s presne opačným nastavením. A tu si musíte vybrať - železný server alebo neželezný server.

Mám otázku týkajúcu sa Amazon AWS. Majú vopred nakonfigurované obrázky. Jeden z nich sa nazýva Amazon RDS. Existujú nejaké vlastné nastavenia pre ich operačný systém?

Sú tam nastavenia, ale sú to iné nastavenia. Tu nakonfigurujeme operačný systém z hľadiska toho, ako bude databáza túto vec využívať. A sú parametre, ktoré určujú, kam by sme sa teraz mali uberať, napríklad tvarovanie. To znamená, že potrebujeme toľko zdrojov, že ich teraz zožerieme. Potom Amazon RDS tieto zdroje sprísňuje a výkon tam klesá. Existujú jednotlivé príbehy o tom, ako sa ľudia začínajú s touto záležitosťou pohrávať. Niekedy dokonca celkom úspešne. Ale to nemá nič spoločné s nastaveniami OS. Je to ako hacknutie cloudu. To je iný príbeh.

Prečo transparentné obrovské stránky nemajú žiadny účinok v porovnaní s obrovským TLB?

Nedať. Dá sa to vysvetliť mnohými spôsobmi. Ale v skutočnosti to jednoducho nedávajú. Aká je história PostgreSQL? Pri spustení alokuje veľkú časť zdieľanej pamäte. Či sú transparentné alebo nie, je úplne irelevantné. To, že vyčnievajú na začiatku, všetko vysvetľuje. A ak máte veľa pamäte a potrebujete prebudovať segment shared_memory, potom budú relevantné priehľadné obrovské stránky. V PostgreSQL je to jednoducho alokované v obrovskom kuse na začiatku a to je všetko a potom sa tam nič zvláštne nedeje. Môžete to, samozrejme, použiť, ale existuje možnosť poškodenia zdieľanej pamäte, keď niečo prerozdelí. PostgreSQL o tom nevie.

Zdroj: hab.com