Vyladění Linuxu pro zlepšení výkonu PostgreSQL. Ilja Kosmodemjanskij

Přepis zprávy Ilji Kosmodemjanského z roku 2015 „Linux tuning pro zlepšení výkonu PostgreSQL“

Upozornění: Podotýkám, že tato zpráva je datována listopadem 2015 – uplynuly více než 4 roky a uplynulo mnoho času. Verze 9.4 popisovaná v této zprávě již není podporována. Za poslední 4 roky vyšlo 5 nových vydání PostgreSQL a 15 verzí linuxového jádra. Pokud tato místa přepíšete, dostanete jinou zprávu. Zde je ale zásadní linuxové ladění pro PostgreSQL, které je aktuální i dnes.

Jmenuji se Ilya Kosmodemyansky. Pracuji pro společnost PostgreSQL-Consulting. A teď budu mluvit trochu o tom, co dělat s Linuxem ve vztahu k databázím obecně a PostgreSQL konkrétně, protože principy jsou dost podobné.

O čem se bude diskutovat? Pokud máte co do činění s PostgreSQL, pak musíte být do určité míry UNIX admin. Co to znamená? Pokud srovnáme Oracle a PostgreSQL, tak v Oracle musíte být z 80 % správcem databáze DBA a z 20 % správcem Linuxu.

PostgreSQL je o něco obtížnější. S PostgreSQL musíte mít mnohem lepší představu o tom, jak Linux funguje. A zároveň trochu běhat po lokomotivě, protože poslední dobou se vše pěkně v pohodě aktualizuje. A objevují se nová jádra a objevují se nové funkce, zlepšuje se výkon atd.

Proč mluvíme o Linuxu? Ani ne proto, že jsme na linuxové konferenci Petře, ale proto, že v moderních podmínkách je jedním z nejopodstatněnějších operačních systémů pro práci s databázemi obecně a s PostgreSQL zvlášť Linux. Protože FreeBSD se bohužel vyvíjí nějakým velmi zvláštním směrem. A budou problémy jak s výkonem, tak s mnoha dalšími věcmi. Výkon PostgreSQL na Windows je obecně samostatné drsné téma, které spočívá na faktu, že Windows nemají tak sdílenou paměť jako UNIX a PostgreSQL je o tomto byznysu, protože jde o víceprocesový systém.

A exotika jako Solaris, myslím, každého zajímá méně, takže jdeme na to.

Moderní distribuce Linuxu má více než 1 možností syctl v závislosti na tom, jak je jádro sestaveno. Přitom když se podíváme na různé oříšky, tak stále může být mnoho způsobů, jak něco upravit. Existují možnosti souborového systému, jak se připojit. Máte-li otázky, jak začít: co povolit v systému BIOS, jak nakonfigurovat hardware atd.

Jedná se o velmi velký objem, o kterém se dá mluvit několik dní a ne v jedné krátké zprávě, ale nyní se zaměřím na důležité věci, jak se vyhnout těm rakům, které vám neumožní dobře provozovat databázi na Linuxu, pokud ty je neopravíš.. A zároveň je důležité, že mnoho výchozích parametrů není zahrnuto v nastaveních, která jsou pro databázi správná. To znamená, že ve výchozím nastavení bude fungovat špatně nebo nebude fungovat vůbec.

Jaké jsou tradiční cíle ladění na Linuxu? Myslím, že jelikož se všichni zabýváte administrací Linuxu, není třeba vysvětlovat, co jsou cíle.

Můžete naladit:

• CPU.
• Paměť.
• Úložný prostor.
• jiný. O tom si povíme na závěr u svačinky. I například nastavení, jako je politika úspory energie, může ovlivnit výkon velmi nepředvídatelným a nepříliš příjemným způsobem.

Jaká jsou specifika PostgreSQL a databáze obecně? Problém je v tom, že nemůžete vyladit nějaký konkrétní oříšek a uvidíte, že se náš výkon hodně zlepšil.

Ano, takové vychytávky existují, ale databáze je složitá věc. Interaguje se všemi prostředky, které server má, a dává přednost plné interakci. Pokud se podíváte na aktuální pokyny společnosti Oracle o tom, jak používat hostitelský OS, je to jako vtip mongolského astronauta – nakrmte psa a na nic nesahejte. Dejme databázi všechny prostředky, databáze sama vše zničí.

V zásadě je situace do jisté míry úplně stejná s PostgreSQL. Rozdíl je v tom, že základna si také nedokáže vzít všechny zdroje pro sebe, čili někde na úrovni Linuxu je potřeba si to všechno utřídit sama.

Hlavní myšlenkou není vybrat si jeden cíl a začít ho ladit, například paměť, CPU nebo něco podobného, ​​ale analyzovat zátěž a snažit se co nejvíce zlepšit propustnost tak, aby zátěž, kterou dobří programátoři vytvořili pro nás, včetně našich uživatelů.

Zde je obrázek pro vysvětlení, co to je. Existuje vyrovnávací paměť OS Linux a sdílená paměť a sdílené vyrovnávací paměti PostgreSQL. PostgreSQL na rozdíl od Oracle funguje přímo pouze přes buffer jádra, čili aby se stránka z disku dostala do jeho sdílené paměti, musí projít bufferem jádra a zpět úplně stejnou situací.

Disky žijí pod tímto systémem. Nakreslil jsem to jako disky. Ve skutečnosti může existovat řadič RAID atd.

A tento vstup-výstup se tak či onak děje prostřednictvím tohoto případu.

PostgreSQL je klasická databáze. Je to uvnitř stránky. A veškerý vstup-výstup probíhá pomocí stránek. Zvyšujeme bloky v paměti po stránkách. A pokud se nic nestalo, jen je přečteme, pak se postupně potopí z této mezipaměti, ze sdílených vyrovnávacích pamětí a dostanou se zpět na disk.

Pokud jsme někde něco nahradili, pak je celá naše stránka označena jako špinavá. Zde jsem je označil modře. A to znamená, že tato stránka musí být synchronizována s blokovým úložištěm. To znamená, že když jsme to zašpinili, udělali jsme záznam ve WAL. A v určitém okamžiku přišel fenomén zvaný kontrolní bod. A tento deník zaznamenal informaci, že přišel. A to znamená, že všechny špinavé stránky, které zde byly v tu chvíli v těchto sdílených bufferech, byly synchronizovány s úložným diskem pomocí fsync přes vyrovnávací paměť jádra.

K čemu to je? Pokud jsme ztratili napětí, pak jsme se nedostali do situace, že by byla ztracena všechna data. Perzistentní paměť, o které nám všichni vyprávěli, je zatím v teorii databází – to je světlá budoucnost, o kterou se samozřejmě snažíme a líbí se nám, ale zatím stále žijí v minus 20 letech. A to vše je samozřejmě potřeba sledovat.

A úkolem maximalizace propustnosti je vyladit všechny tyto fáze tak, aby to všechno šlo rychle tam a zpět. Sdílená paměť je v podstatě mezipaměť stránek. V PostgreSQL jsme tam poslali požadavek select something, ono to získalo tato data z disku. Dostali se do sdílených bufferů. Proto, aby to fungovalo lépe, musí být spousta paměti.

Aby to vše fungovalo dobře a rychle, musíte správně nakonfigurovat operační systém ve všech fázích. A vybírejte vyvážené železo, protože pokud máte na nějakém místě nerovnováhu, pak můžete udělat hodně paměti, ale bude podáváno nedostatečnou rychlostí.

Pojďme si projít každý z těchto bodů.

Aby se tyto stránky pohybovaly tam a zpět rychleji, musíte dosáhnout následujícího:

• Nejprve je potřeba efektivněji pracovat s pamětí.
• Za druhé, tento přechod by měl být efektivnější, když stránky z paměti přejdou na disk.
• A do třetice musí být dobré disky.

Pokud máte na serveru 512 GB RAM a toto vše skončí na pevném disku SATA bez cache, pak se celý databázový server promění nejen v dýni, ale v dýni s rozhraním SATA. Narazíte na to přímo. A nic tě nezachrání.

Co se týče prvního bodu s pamětí, jsou tři věci, které dokážou hodně zkomplikovat život.

První je NUMA. NUMA je věc, která má zlepšit výkon. V závislosti na pracovní zátěži můžete optimalizovat různé věci. A ve své nové současné podobě není příliš dobrý pro aplikace, jako je databáze, která intenzivně využívá sdílené buffery mezipaměti stránek.

Ve zkratce. Jak pochopit, že s NUMA není něco v pořádku? Máte nějaké nepříjemné klepání, najednou je nějaký CPU přetížený. Zároveň analyzujete dotazy v PostgreSQL a vidíte, že tam nic podobného není. Tyto požadavky by neměly být tak náročné na CPU. Dá se to chytit dlouho. Od začátku je snazší použít správnou radu, jak nastavit NUMA pro PostgreSQL.

co se vlastně děje? NUMA znamená Non-Uniform Memory Access. Jaký je smysl? Máte CPU, vedle něj je jeho lokální paměť. A tato propojení paměti mohou vytáhnout paměť z jiných CPU.

Pokud běžíš numactl --hardware, tak vám vznikne takový velký list. Mimo jiné zde bude distanční hřiště. Budou tam čísla - 10-20, něco takového. Tato čísla nejsou nic jiného než počet skoků k vyzvednutí této vzdálené paměti a jejímu místnímu použití. V podstatě dobrý nápad. To zlepšuje výkon v řadě pracovních zátěží.

Nyní si představte, že máte jeden procesor, který se nejprve pokouší použít svou místní paměť a poté se snaží pro něco vytáhnout další paměť prostřednictvím propojení. A celá vaše mezipaměť stránek PostgreSQL se dostane do tohoto CPU - to je vše, kolik gigabajtů tam je. Vždy dostanete ten nejhorší případ, protože na CPU přímo v tom modulu je většinou málo paměti. A veškerá paměť, která je podávána, prochází těmito propojeními. Ukazuje se to pomalu a smutně. A máte procesor, který obsluhuje tento uzel je neustále přetížený. A přístupová doba této paměti je špatná, pomalá. Toto je situace, kterou nechcete, pokud používáte tento případ pro databázi.

Správnější varianta pro databázi tedy je, že operační systém Linux vůbec neví, co se tam děje. Aby oslovovala paměť tak, jak oslovuje.

proč tomu tak je? Zdálo by se, že by to mělo být naopak. To se děje z jednoho prostého důvodu, že potřebujeme hodně paměti pro cache stránek – desítky, stovky gigabajtů.

A pokud toto všechno alokujeme a uložíme tam naše data do mezipaměti, pak zisk z použití mezipaměti bude výrazně větší než zisk z takového mazaného přístupu k paměti. A tím získáme nesrovnatelně oproti tomu, že budeme přistupovat k paměti efektivněji pomocí NUMA.

Proto jsou v tuto chvíli dva přístupy, dokud nenastane světlá budoucnost a databáze sama nemůže přijít na to, na kterých CPU pracuje a odkud potřebuje něco vytáhnout.

Správným přístupem je proto NUMA úplně zakázatnapříklad při restartu. Ve většině případů jsou výhry v takovém pořadí, že není vůbec sporu, co je lepší.

Existuje ještě jedna možnost. Používáme ho častěji než ten první, protože když k nám klient přijde pro podporu, tak pro něj je restart serveru celá věc. Má tam obchod. A mají problémy kvůli NUMA. Proto se jej snažíme deaktivovat méně invazivními způsoby než restartováním, ale zde buďte opatrní a zkontrolujte, zda je deaktivován. Protože, jak zkušenost ukazuje, že deaktivujeme NUMA na nadřazeném procesu PostgreSQL, je to dobré, ale není vůbec nutné, aby to fungovalo. Musíme zkontrolovat a zjistit, že se opravdu vypnula.

Je tu dobrý příspěvek od Roberta Haase. Toto je jeden z autorů PostgreSQL. Jeden z klíčových vývojářů všech drobů nízké úrovně. A pokud budete následovat odkazy z tohoto příspěvku, popisuje několik barvitých příběhů o tom, jak NUMA ztěžovala lidem život. Podívejte se, prostudujte si kontrolní seznam správce systému, co je potřeba na serveru nakonfigurovat, aby naše databáze dobře fungovala. Tato nastavení je potřeba zaznamenat a zkontrolovat, protože jinak to nebude moc dobré.

Upozorňuji na to, že to platí pro všechna nastavení, o kterých budu mluvit. Obvykle jsou však databáze sestavovány v režimu master-slave kvůli odolnosti proti chybám. Nezapomeňte provést tato nastavení na slave, protože jednoho dne se vám stane nehoda a přepnete se na slave a ten se stane pánem.

V případě nouze, kdy je všechno velmi špatné, neustále vám zvoní telefon a přibíhá váš šéf s velkým klackem, nebudete mít čas přemýšlet o kontrole. A výsledky mohou být velmi katastrofální.

Dalším okamžikem jsou obrovské stránky. Obrovské stránky je obtížné testovat samostatně a nemá to smysl, i když existují benchmarky, které to umí. Dají se snadno vygooglit.

Jaký to má smysl? Máte nepříliš drahý server, který má hodně paměti RAM, například více než 30 GB. Nepoužíváte velké stránky. To znamená, že máte určitě režii na využití paměti. A tato režie není zdaleka nejpříjemnější.

proč tomu tak je? a co se děje? Operační systém alokuje paměť po malých kouscích. Tak pohodlné, tak historicky. A pokud půjdete do detailů, pak OS musí překládat virtuální adresy na fyzické. A tento proces není nejjednodušší, takže OS ukládá výsledek této operace do mezipaměti překladu Lookaside Buffer (TLB).

A protože TLB je mezipaměť, pak v této situaci vznikají všechny problémy s mezipamětí vlastní. Za prvé, pokud máte hodně paměti RAM a vše je alokováno v malých kouscích, pak se tato vyrovnávací paměť stane velmi velkou. A pokud je keška velká, pak je její hledání pomalejší. Režie je zdravá a zabírá místo sama o sobě, tj. něco špatně spotřebovává RAM. Tentokrát.

Zadruhé – čím více se v takové situaci cache rozroste, tím je pravděpodobnější, že budete mít cache misses. A účinnost této mezipaměti rychle klesá, jak roste její velikost. Operační systémy tedy přišly s jednoduchým přístupem. Linux ho používá už dlouho. Ve FreeBSD se objevil nedávno. Ale bavíme se o Linuxu. Jsou to obrovské stránky.

A zde je třeba poznamenat, že obrovské stránky, jako nápad, byly zpočátku protlačeny komunitami, které zahrnovaly Oracle a IBM, tedy výrobci databází usilovně přemýšleli o tom, že by to bylo užitečné, včetně databází.

A jak se s PostgreSQL spřátelit? Za prvé, velké stránky musí být povoleny v jádře Linuxu.

Za druhé, musí být explicitně specifikovány parametrem sysctl - kolik jich je. Čísla zde jsou z nějakého starého serveru. Můžete si spočítat, kolik přibližně máte sdílených vyrovnávacích pamětí, aby se tam vešly velké stránky.

A pokud máte celý server dedikovaný PostgreSQL, pak je dobrým výchozím bodem buď dát 25 % RAM pro sdílené buffery, nebo 75 %, pokud jste si jisti, že se vaše databáze do těchto 75 % určitě vejde. Výchozí bod jako první. A zvažte, že pokud máte 256 GB RAM, budete mít 64 GB vyrovnávací paměti. Počítejte přibližně s určitou rezervou - na co byste měli mít tento údaj nastaven.

Před verzí 9.2 (pokud se nepletu, tak od verze 8.2) bylo možné spřátelit se s obrovskými stránkami PostgreSQL pomocí knihovny třetích stran. A to by se mělo dělat vždy. Nejprve potřebujete jádro, aby bylo schopno správně alokovat velké stránky. A za druhé, aby je mohla používat aplikace, která s nimi pracuje. Takhle se to prostě používat nebude. Vzhledem k tomu, že PostgreSQL přiděluje paměť ve stylu systému 5, lze to provést pomocí libhugetlbfs - toto je úplný název knihovny.

9.3 zlepšil výkon paměti PostgreSQL a zrušil metodu přidělování paměti systému 5. Všichni byli velmi šťastní, protože jinak se pokusíte spustit dvě instance PostgreSQL na stejném počítači a on říká, že nemám dostatek sdílené paměti. A říká, že musíte opravit sysctl. A je tam takový sysctl, že stále potřebujete restartovat atd. Obecně byli všichni potěšeni. Ale alokace paměti mmap se zlomila pomocí velkých stránek. Většina našich klientů používá velké sdílené vyrovnávací paměti. A důrazně jsme doporučili nepřecházet na 9.3, protože tam se režie začala počítat v dobrých procentech.

Ale na druhou stranu komunita na tento problém upozornila a v 9.4 tuto akci velmi dobře přepracovala. A v 9.4 se v postgresql.conf objevil parametr, ve kterém můžete zapnout try, zapnout nebo vypnout.

Zkusit je nejbezpečnější možností. Když se PostgreSQL spustí, když alokuje sdílenou paměť, snaží se tuto paměť získat z velkých stránek. A pokud to nefunguje, vrátí se zpět k obvyklému výběru. A pokud máte FreeBSD nebo Solaris, můžete to zkusit, je to vždy bezpečné.

Pokud je zapnuto, pak se jednoduše nespustí, pokud nemohl vybrat z velkých stránek. Už tady - komu a co je roztomilejší. Ale pokud máte pokus, tak si zkontrolujte, že máte opravdu zvýrazněno to, co potřebujete, protože je tam hodně mezer pro chybu. V současné době tato funkce funguje pouze na Linuxu.

Ještě malá poznámka, než budeme pokračovat. Transparentní obrovské stránky zatím nejsou o PostgreSQL. Nemůže je normálně používat. A s transparentními obrovskými stránkami pro takové pracovní zatížení, kdy potřebujete velký kus sdílené paměti, výhody přicházejí pouze s velmi velkými objemy. Pokud máte terabajty paměti, může to hrát roli. Pokud se bavíme o každodenních aplikacích, kdy máte na stroji 32, 64, 128, 256 GB paměti, pak jsou obvyklé obrovské stránky OK a prostě vypneme Transparent.

A poslední věc o paměti přímo nesouvisí s fruputem, ta dokáže velmi zničit život. Veškerá propustnost bude značně ovlivněna tím, že server neustále swapuje.

A v některých bodech to bude velmi nepříjemné. A hlavním problémem je, že v moderních jádrech se chování mírně liší od starších linuxových jader. A tato věc, na kterou je dost nepříjemné šlápnout, protože když se bavíme o nějaké práci se swapem, končí to předčasným příchodem OOM-killera. A OOM-killer, který nepřišel včas a shodil PostgreSQL, je nepříjemný. Všichni o tom budou vědět, tedy až do posledního uživatele.

Co se děje? Máš tam velké množství RAM, vše funguje dobře. Ale z nějakého důvodu server visí ve swapu a kvůli tomu se zpomaluje. Zdálo by se, že je tam hodně paměti, ale stává se to.

Dříve jsme doporučovali nastavit vm.swappiness na nulu, tedy zakázat swap. Dříve se zdálo, že 32 GB RAM a odpovídající sdílené vyrovnávací paměti jsou obrovské množství. Hlavním účelem swapu je mít kam odhodit krustu, když spadneme. A to se moc nepovedlo. A co potom uděláte s touto kůrkou? To už je takový úkol, kdy není moc jasné, proč je potřeba swap, zvlášť takové velikosti.

Ale v modernějších, tj. ve třetích verzích jádra, se chování změnilo. A pokud swap nastavíte na nulu, tedy vypnete, dříve nebo později, i když vám nějaká RAM zbyde, k vám přijde OOM zabiják, který zabije ty nejintenzivnější konzumenty. Protože uváží, že nám při takovém vytížení ještě něco málo zbývá a vyskočíme, tedy nezabijeme systémový proces, ale zabijeme něco méně důležitého. Tím méně důležitým bude velký spotřebitel sdílené paměti, jmenovitě správce pošty. A poté bude dobré, když se základ nebude muset obnovovat.

Proto je nyní výchozí, pokud si pamatuji, většina distribucí někde kolem 6, tj. v jakém bodě začít používat swap, podle toho, kolik paměti zbývá. Nyní doporučujeme nastavit vm.swappiness = 1, protože to prakticky vypne, ale nedává takové efekty jako u nečekaného OOM zabijáka, který přišel a celou věc zabil.

Co bude dál? Když se bavíme o výkonu databází a postupně, postupně jsme jako disky, každý se začne chytat za hlavu. Protože pravda, že disk je pomalý a paměť rychlá, zná každý už od dětství. A každý ví, že v databázi budou problémy s výkonem disku.

Hlavním problémem výkonu PostgreSQL s nárůsty kontrolních bodů není pomalý disk. To je pravděpodobnější kvůli skutečnosti, že paměť a šířka pásma disku nejsou vyvážené. Na různých místech však nemusí být vyvážené. PostgreSQL není nakonfigurován, OS není nakonfigurován, hardware není nakonfigurován a hardware je chybný. A tento problém nenastává pouze v případě, že vše jde jak má, tedy buď není zátěž, nebo je dobře zvoleno nastavení a hardware.

Co to je a jak to vypadá? Obvykle lidé, kteří pracují s PostgreSQL, vstoupili do tohoto podnikání více než jednou. vysvětlím. Jak jsem řekl, PostgreSQL pravidelně provádí kontrolní body pro ukládání špinavých stránek ze sdílené paměti na disk. Pokud máme velké množství sdílené paměti, tak checkpoint začne intenzivně ovlivňovat disk, protože fsync tyto stránky vyhazuje. Dorazí do vyrovnávací paměti jádra a zapíše se na disk pomocí fsync. A pokud je objem tohoto pouzdra velký, pak můžeme pozorovat nepříjemný efekt, a to velmi velké využití disků.

Tady mám dva obrázky. Nyní vysvětlím, co to je. Jedná se o dva časově korelované grafy. První graf je využití disku. Zde v tomto okamžiku dosahuje téměř 90 %. Pokud máte pokles databáze s fyzickými disky, s RAID řadičem pod 90% využitím, pak je to špatná zpráva. To znamená, že o něco více a přijde 100 a vstup / výstup se zastaví.

Pokud máte diskové pole, pak je tu trochu jiný příběh. Tam záleží na tom, jak je to nakonfigurováno, jaké pole atd.

A paralelně je zde konfigurován graf z interního postgresového pohledu, který říká, jak ke kontrolnímu bodu dochází. A zelená barva zde ukazuje, kolik vyrovnávacích pamětí těchto špinavých stránek v tu chvíli dorazilo k tomuto kontrolnímu bodu pro synchronizaci. A to je tu hlavní vědět. Vidíme, že zde máme spoustu stránek a v určité chvíli jsme narazili na poplatek, tedy psali a psali, zde je diskový systém zjevně velmi vytížený. A náš kontrolní bod má na disk velmi silný vliv. V ideálním případě by situace měla vypadat spíše takto, čili jsme zde měli menší rekord. A můžeme to opravit nastavením, aby to takhle pokračovalo. To znamená, že recyklace je malá, ale někde tady něco píšeme.

Co je třeba udělat pro překonání tohoto problému? Pokud jste zastavili IO pod databází, znamená to, že všichni uživatelé, kteří přišli vyřídit své požadavky, budou čekat.

Pokud se podíváte z pohledu Linuxu, pokud jste vzali dobrý hardware, nakonfigurovali jej správně, nakonfigurovali PostgreSQL normálně tak, aby tyto kontrolní body dělal méně často, rozložil je v čase mezi sebou, pak vstoupíte do výchozích parametrů Debianu . Pro většinu distribucí Linuxu je to tento obrázek: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Co to znamená? Od jádra 2.6 se objevilo jedno vyprázdnění démona. Pdglush, podle toho, kdo co používá, který na pozadí vyhazuje špinavé stránky z vyrovnávací paměti jádra a zahazuje špinavé stránky, když je to nutné, bez ohledu na to, když házení na pozadí nepomáhá.

Kdy přichází zázemí? Když je 10 % celkové paměti RAM na serveru obsazeno špinavými stránkami ve vyrovnávací paměti jádra, je na pozadí volána speciální cheatová funkce. Proč je pozadí? Jako parametr bere, kolik stránek odepsat. A řekněme odepíše N stránek. A na chvíli tahle věc usne. A pak se vrátí a odepíše další stránky.

Toto je extrémně jednoduchý příběh. Tady je úkol jako s bazénem, ​​když se nalévá do jedné trubky, nalévá do druhé. Přišel náš kontrolní bod a pokud odeslal pár špinavých stránek k zahození, pak se postupně z vyrovnávací paměti jádra pgflush celá tato věc úhledně vyřeší.

Pokud se tyto špinavé stránky dále hromadí, nashromáždí se až 20%, poté je prioritou OS odepsat celou věc na disk, protože vyletí proud a bude pro nás všechno špatné. O tato data například přijdeme.

Jaký je trik? Trik je v tom, že tyto parametry v moderním světě 20 a 10 % veškeré paměti RAM, která je na stroji, jsou naprosto monstrózní z hlediska propustnosti jakéhokoli diskového systému, který máte.

Představte si, že máte 128 GB RAM. Na váš diskový systém přijde 12,8 GB. A ať tam máte jakoukoliv cache, ať tam máte jakékoli pole, tolik nevydrží.

Proto doporučujeme tato čísla okamžitě upravit v závislosti na možnostech vašeho RAID řadiče. Hned jsem sem dal doporučení na řadič, který má 512 MB cache.

Vše je považováno za velmi jednoduché. Vm.dirty_background můžete vložit do bajtů. A tato nastavení přepíší předchozí dvě. Buď je poměr výchozí, nebo jsou aktivovány ty s bajty, pak budou fungovat ty s bajty. Ale jelikož jsem DBA konzultant a pracuji s různými klienty, snažím se brčka pokládat a tedy když v bytech, tak v bytech. Nikdo nezaručil, že dobrý administrátor serveru nepřidá paměť, nerestartuje ho a číslo zůstane stejné. Jen si spočítejte tato čísla, aby tam vše se zárukou sedělo.

Co se stane, když nezapadneš? Napsal jsem, že účinně zastaví jakékoli splachování, ale ve skutečnosti je to figura řeči. Operační systém má velký problém – má hodně špinavých stránek, takže se efektivně zastaví IO, které vaši klienti generují, čili aplikace přišla odeslat sql dotaz do databáze, čeká. Jakýkoli vstup/výstup má nejnižší prioritu, protože základna je obsazena kontrolním bodem. A když skončí, je to naprosto nepochopitelné. A když jste dosáhli proplachování bez pozadí, bez pozadí, znamená to, že je jím obsazen celý váš IO. A dokud to neskončí, nebudete dělat nic.

Jsou zde ještě dva důležité body, které přesahují rámec této zprávy. Tato nastavení by měla odpovídat nastavení v postgresql.conf, tedy nastavení kontrolních bodů. A váš diskový systém musí být adekvátně nakonfigurován. Pokud máte mezipaměť na RAID, pak musí mít baterii. Lidé kupují RAID s dobrou mezipamětí bez baterie. Pokud máš SSD v RAID, tak to musí být serverové, musí tam být kondenzátory. Zde je rozšířený kontrolní seznam. Na tomto odkazu je moje zpráva o tom, jak nastavit výkon disku v PostgreSQL. Všechny ty kontrolní seznamy tam jsou.

Co ještě může hodně zkomplikovat život? To jsou dvě možnosti. Jsou relativně nové. Ve výchozím nastavení je lze zahrnout do různých aplikací. A stejně tak dokážou zkomplikovat život, pokud jsou špatně zapnuté.

Jedná se o dva relativně nové kusy. Objevily se již ve třetích jádrech. Jedná se o sched_migration_cost v nanosekundách a sched_autogroup_enabled, což je ve výchozím nastavení jedna.

A jak si kazí život? Co je sched_migration_cost? Plánovač Linuxu může migrovat proces z jednoho CPU na druhý. A pro PostgreSQL, který provádí dotazy, je migrace na jiný CPU naprosto nepochopitelná proč. Z pohledu operačního systému, když přepínáte okna mezi openoffice a terminálem, to může být v pořádku, ale pro databázi - je to velmi špatné. Proto je rozumnou politikou nastavit migraci_cost na nějakou velkou hodnotu, alespoň několik tisíc nanosekund.

Co to bude znamenat pro plánovač? Předpokládá se, že během této doby je tento proces stále horký. To znamená, že pokud nějakou dlouhou transakci děláte nějakou dlouhou dobu, plánovač to pochopí. Bude předpokládat, že dokud tento časový limit neuplyne, pak tento proces není třeba nikam migrovat. Pokud zároveň proces něco udělá, tak se nebude nikam migrovat, klidně skončí na CPU, které mu bylo přiděleno. A výsledek je výborný.

Druhým bodem je automatické seskupování. Je to dobrý nápad pro specifické úlohy, které nesouvisejí s moderními databázemi – jde o seskupení procesů podle virtuálního terminálu, ze kterého jsou spouštěny. Je to vhodné pro některé úkoly. V praxi je PostgreSQL prefork multiprocesní systém, který běží z jednoho terminálu. Máte zapisovač zámku, kontrolní bod a všechny vaše klientské požadavky jsou seskupeny do jednoho plánovače pro každý CPU. A budou tam spolu čekat, až bude volný, aby si navzájem překáželi a déle ho zaměstnali. Jedná se o příběh, který je v případě takové zátěže zcela zbytečný a proto by měl být vypnutý.

Můj kolega Alexey Lesovsky dělal testy s jednoduchým pgbenchem, kde o řád zvýšil migraci_cost a vypnul autogroup. Rozdíl na špatném kusu železa se ukázal být téměř 10%. Na mailing listu postgres je diskuze, kde lidé hlásí výsledky jako podobné změny v rychlosti dotazů ovlivnil 50%. Takových příběhů je poměrně dost.

A nakonec o politice úspory energie. Je dobře, že Linux lze nyní používat i na notebooku. A bude prý dobře spotřebovávat baterii. Ale najednou se ukáže, že se to může stát i na serveru.

Navíc, pokud si pronajímáte servery od nějakého hostitele, pak „dobrým“ hostitelům je jedno, že máte lepší výkon. Jejich úkolem je zajistit, aby jejich železo bylo využito co nejefektivněji. Ve výchozím nastavení tedy mohou na operačním systému zapnout úsporný režim notebooku.

Pokud to používáte na silně zatíženém databázovém serveru, pak je vaše volba acpi_cpufreq + permormance. I s ondemand již budou problémy.

Intel_pstate je trochu jiný ovladač. A nyní je dávána přednost tomuto, jako pozdějšímu a lépe fungujícímu.

A proto je guvernér pouze výkon. Ondemand, powersave a vše ostatní – to není o vás.

Výsledky vysvětlující analýzy se PostgreSQL mohou lišit o několik řádů, pokud zapnete powersave, protože v praxi budete mít CPU pod databází zcela nepředvídatelným způsobem.

Tyto věci lze ve výchozím nastavení povolit. Pečlivě se podívejte, zda byly ve výchozím nastavení povoleny. To může být opravdu velký problém.

A na závěr jsem chtěl poděkovat klukům z našeho týmu PosgreSQL-Consulting DBA, jmenovitě Maxi Bogukovi a Alexey Lesovsky, kteří každý den vyplňují nerovnosti v tomto byznysu. A pro naše klienty se snažíme dělat to nejlepší, aby jim to všechno klapalo. Je to jako s pokyny pro bezpečnost letectví. Vše je zde psáno krví. Každý z těchto ořechů je objeven v procesu nějakého druhu problému. Rád se o ně s vámi podělím.

otázky:

Děkuji! Pokud chce například společnost ušetřit peníze a hostit databázi a aplikační logiku na stejném serveru, nebo pokud společnost následuje módní trend mikroservisních architektur, ve kterých běží PostgreSQL v kontejneru. Jaký to má smysl? Sysctl globálně ovlivňuje celé jádro. Neslyšel jsem, že by sysctl byl nějak virtualizován, aby na kontejneru fungoval odděleně. Existuje pouze cgroup a pouze její část má kontrolu. Jak s tím můžeš žít? Nebo pokud chcete výkon, spusťte PostgreSQL na samostatném serveru železa a vylaďte jej?

Na vaši otázku jsme odpověděli asi třemi způsoby. Pokud se nebavíme o železném serveru, který lze vyladit atd., tak se uklidněte, vše bude fungovat bez těchto nastavení. Pokud máte takovou zátěž, že potřebujete provést tato nastavení, přijdete na server železa dříve než tato nastavení.

Co je za problém? Pokud se jedná o virtuální stroj, pak s největší pravděpodobností budete mít mnoho problémů, například s tím, že většina virtuálních strojů má poměrně nekonzistentní latenci disku. I když je propustnost disku dobrá, pak jediná neúspěšná I/O transakce, která příliš neovlivní průměrnou propustnost, ke které došlo v době kontrolního bodu nebo v době zápisu do WAL, tím databáze značně utrpí. A všimnete si toho dříve, než narazíte na tyto problémy.

Pokud máte NGINX na stejném serveru, budete mít také stejný problém. Bude bojovat o sdílenou paměť. A nedosáhnete problémů, které jsou zde popsány.

Ale na druhou stranu, některé z těchto parametrů pro vás budou stále relevantní. Například u sysctl nastavte dirty_ratio, aby to nebylo tak šílené - v každém případě to pomůže. Tak či onak, budete mít interakci s diskem. A bude to špatně. Toto je obecně výchozí nastavení parametrů, které jsem ukázal. A v každém případě je lepší je změnit.

A s NUMA mohou nastat problémy. VmWare například dobře spolupracuje s NUMA s přesně opačným nastavením. A zde si musíte vybrat - železný server nebo neželezný.

Mám otázku týkající se Amazon AWS. Mají přednastavené obrázky. Jeden z nich se nazývá Amazon RDS. Existují nějaká vlastní nastavení pro jejich operační systém?

Existují nastavení, ale jsou to jiná nastavení. Zde nakonfigurujeme operační systém z hlediska toho, jak bude databáze tento obchod využívat. A jsou parametry, které určují, kam teď máme jít, takové tvarování. To znamená, že potřebujeme tolik zdrojů, že je teď sníme. Poté Amazon RDS tyto prostředky upevní a výkon tam klesne. Existují různé příběhy o tom, jak lidé začínají s touto záležitostí chemizovat. Někdy i docela úspěšně. Ale to nemá nic společného s nastavením OS. Je to jako cloud hacking. To je jiný příběh.

Proč nemají transparentní obrovské stránky žádný účinek ve srovnání s obrovským TLB?

Nedávej. To lze vysvětlit mnoha způsoby. Ale ve skutečnosti to prostě nedají. Jaká je historie PostgreSQL? Při spuštění alokuje velký kus sdílené paměti. Průhledné jsou zároveň nebo neprůhledné - na tom vůbec nezáleží. To, že vyčnívají na začátku, vše vysvětluje. A pokud je paměti hodně a potřebujete znovu vytvořit segment shared_memory, pak budou relevantní průhledné velké stránky. V PostgreSQL se to prostě na začátku zvýrazní obrovským kusem a hotovo a pak už se tam nic zvláštního neděje. Můžete ji samozřejmě použít, ale existuje možnost získat curruption shared_memory, když něco znovu alokuje. PostgreSQL o tom neví.

Zdroj: www.habr.com