serveru<\/a> a v\u0161echno to nakonec p\u0159ijde na SATA pevn\u00fd disk bez jak\u00e9hokoli cache, cel\u00fd datab\u00e1zov\u00fd server se prom\u011bn\u00ed v n\u011bco v\u00edc ne\u017e d\u00fdni, ale v d\u00fdni se SATA rozhran\u00edm. S t\u00edm se budete muset p\u0159\u00edmo pot\u00fdkat. A nic v\u00e1s nezachr\u00e1n\u00ed.<\/p>\n<\/p>\n
<\/p>\n
Pokud jde o prvn\u00ed bod s pam\u011bt\u00ed, existuj\u00ed t\u0159i v\u011bci, kter\u00e9 mohou \u017eivot zna\u010dn\u011b zkomplikovat. <\/p>\n
<\/p>\n
Prvn\u00ed z nich je NUMA. NUMA je v\u011bc navr\u017een\u00e1 pro zlep\u0161en\u00ed v\u00fdkonu. V z\u00e1vislosti na z\u00e1t\u011b\u017ei lze optimalizovat r\u016fzn\u00e9 v\u011bci. A ve sv\u00e9m nov\u00e9m sou\u010dasn\u00e9m stavu nen\u00ed p\u0159\u00edli\u0161 dobr\u00e1 pro aplikace, jako jsou datab\u00e1ze, kter\u00e9 intenzivn\u011b pou\u017e\u00edvaj\u00ed sd\u00edlen\u00e9 bufry cache. <\/p>\n
<\/p>\n
<\/p>\n
Jednodu\u0161e \u0159e\u010deno. Jak poznat, \u017ee s NUMA je n\u011bco v nepo\u0159\u00e1dku? M\u00e1te n\u011bjak\u00fd nep\u0159\u00edjemn\u00fd \u0161um, n\u00e1hle zjist\u00edte, \u017ee je n\u011bjak\u00fd CPU p\u0159et\u00ed\u017een\u00fd. P\u0159itom analyzujete dotazy v PostgreSQL a vid\u00edte, \u017ee tam nic takov\u00e9ho nen\u00ed. Tyto dotazy by nem\u011bly tak intenzivn\u011b zat\u011b\u017eovat CPU. M\u016f\u017ee to b\u00fdt obt\u00ed\u017en\u00e9 odhalit. Snaz\u0161\u00ed je od za\u010d\u00e1tku vyu\u017e\u00edt spr\u00e1vn\u00e9 doporu\u010den\u00ed, jak nastavit NUMA pro PostgreSQL.<\/p>\n
<\/p>\n
<\/p>\n
Co se ve skute\u010dnosti d\u011bje? NUMA je Non-Uniform Memory Access. O co jde? M\u00e1te CPU, vedle n\u011bj je jeho m\u00edstn\u00ed pam\u011b\u0165. A tato pam\u011b\u0165 m\u016f\u017ee propojovat pam\u011b\u0165 z jin\u00fdch CPU.<\/p>\n
<\/p>\n
Pokud spust\u00edte numactl --hardware<\/code>, dostanete takov\u00fd velk\u00fd v\u00fdpis. Mezi jin\u00fdm tam bude pole distances. Budou tam \u010d\u00edsla \u2013 10-20, n\u011bco takov\u00e9ho. Tato \u010d\u00edsla jsou ni\u010d\u00edm jin\u00fdm ne\u017e po\u010dtem skok\u016f, aby se tato vzd\u00e1len\u00e1 pam\u011b\u0165 mohla p\u0159ipojit a pou\u017e\u00edvat lok\u00e1ln\u011b. V z\u00e1sad\u011b je to dobr\u00fd n\u00e1pad. To v\u00fdznamn\u011b zrychluje v\u00fdkon p\u0159i ur\u010dit\u00fdch z\u00e1t\u011b\u017e\u00edch.<\/p>\n<\/p>\n
P\u0159edstavte si, \u017ee m\u00e1te jeden CPU, kter\u00fd se nejprve sna\u017e\u00ed pou\u017e\u00edvat svou lok\u00e1ln\u00ed pam\u011b\u0165, a pak se pokou\u0161\u00ed p\u0159et\u00e1hnout dal\u0161\u00ed pam\u011b\u0165 p\u0159es interconnect pro n\u011bco jin\u00e9ho. A do t\u00e9to CPU se dost\u00e1v\u00e1 cel\u00fd v\u00e1\u0161 page cache PostgreSQL \u2013 n\u011bkolik gigabajt\u016f. V\u017edy se dost\u00e1v\u00e1te do nejhor\u0161\u00ed situace, proto\u017ee na CPU je p\u0159\u00edmo v tomto modulu pam\u011bti obvykle m\u00e1lo. A ve\u0161ker\u00e1 pam\u011b\u0165, kter\u00e1 je obsluhov\u00e1na, proch\u00e1z\u00ed t\u011bmito interconnecty. To je pomal\u00e9 a smutn\u00e9. A m\u00e1te procesor, kter\u00fd obsluhuje tento uzel, trvale p\u0159et\u00ed\u017een\u00fd. A \u010das p\u0159\u00edstupu k t\u00e9to pam\u011bti je \u0161patn\u00fd, pomal\u00fd. Tohle je situace, kter\u00e9 se chcete vyhnout, pokud pou\u017e\u00edv\u00e1te toto pro datab\u00e1zi. <\/p>\n
<\/p>\n
Proto je pro datab\u00e1ze spr\u00e1vn\u011bj\u0161\u00ed, aby opera\u010dn\u00ed syst\u00e9m Linux v\u016fbec nev\u011bd\u011bl, co se tam d\u011bje. Aby se k pam\u011bti choval tak, jak se m\u00e1. <\/p>\n
<\/p>\n
Pro\u010d je to tak? Na prvn\u00ed pohled by se to m\u011blo zd\u00e1t naopak. D\u016fvod je prost\u00fd: pot\u0159ebujeme hodn\u011b pam\u011bti pro page cache \u2013 des\u00edtky, stovky gigabajt\u016f. <\/p>\n
<\/p>\n
A pokud jsme to v\u0161echno alokovali a na\u0161e data si tam cacheujeme, zisk z pou\u017eit\u00ed cache bude podstatn\u011b v\u011bt\u0161\u00ed ne\u017e zisk z takov\u00e9ho chytr\u00e9ho p\u0159\u00edstupu k pam\u011bti. T\u00edmto zp\u016fsobem z\u00edsk\u00e1me nesrovnateln\u011b v\u00edce v porovn\u00e1n\u00ed s t\u00edm, \u017ee bychom efektivn\u011bji p\u0159istupovali do pam\u011bti pomoc\u00ed NUMA.<\/p>\n
<\/p>\n
Dosud existuj\u00ed dva p\u0159\u00edstupy, dokud nenastane jasn\u00e1 budoucnost, kdy datab\u00e1ze nebude um\u011bt sama rozpoznat, na jak\u00fdch CPU pracuje a odkud n\u011bco pot\u0159ebuje p\u0159et\u00e1hnout. <\/p>\n
<\/p>\n
<\/p>\n
Proto je spr\u00e1vn\u00fd p\u0159\u00edstup \u00fapln\u011b vypnout NUMA<\/strong>, nap\u0159\u00edklad p\u0159i restartov\u00e1n\u00ed. Ve v\u011bt\u0161in\u011b p\u0159\u00edpad\u016f jsou zisky takov\u00e9, \u017ee se v\u016fbec neobjevuje ot\u00e1zka, jak je to lep\u0161\u00ed. <\/p>\n<\/p>\n
Existuje jin\u00e1 mo\u017enost. Tu pou\u017e\u00edv\u00e1me \u010dast\u011bji ne\u017e tu prvn\u00ed, proto\u017ee kdy\u017e k n\u00e1m v podpore p\u0159ijde klient, restart serveru je pro n\u011bj velk\u00e1 z\u00e1le\u017eitost. Je tam jeho podnik\u00e1n\u00ed. A probl\u00e9my kv\u016fli NUMA za\u017e\u00edvaj\u00ed. Proto se sna\u017e\u00edme ji vypnout m\u00e9n\u011b invazivn\u00edmi zp\u016fsoby ne\u017e restartov\u00e1n\u00edm, ale tady opatrn\u011b zkontrolujte, \u017ee byla skute\u010dn\u011b vypnuta. Proto\u017ee, jak ukazuje zku\u0161enost, kdy\u017e NUMA vyp\u00edn\u00e1me u rodi\u010dovsk\u00e9ho procesu PostgreSQL, je to dobr\u00e9, ale zdaleka to nemus\u00ed fungovat. Mus\u00edte kontrolovat a sledovat, \u017ee se skute\u010dn\u011b vypnula. <\/p>\n
<\/p>\n
Existuje dobr\u00fd post od Roberta Haase. Je to jeden z komit\u00e9r\u016f PostgreSQL, jeden z kl\u00ed\u010dov\u00fdch v\u00fdvoj\u00e1\u0159\u016f v\u0161ech n\u00edzko\u00farov\u0148ov\u00fdch komponent. A pokud se pod\u00edv\u00e1te na odkazy z tohoto p\u0159\u00edsp\u011bvku, popisuje n\u011bkolik poutav\u00fdch p\u0159\u00edb\u011bh\u016f o tom, jak lidem NUMA komplikovala \u017eivot. Pod\u00edvejte se, prostudujte kontroln\u00ed seznam pro administr\u00e1tory, co je t\u0159eba nastavit na serveru, aby na\u0161e datab\u00e1ze fungovala dob\u0159e. Tyto nastaven\u00ed je t\u0159eba zaznamenat a kontrolovat, proto\u017ee jinak to nebude p\u0159\u00edli\u0161 dob\u0159e. <\/p>\n
<\/p>\n
R\u00e1d bych upozornil, \u017ee se to t\u00fdk\u00e1 v\u0161ech nastaven\u00ed, o kter\u00fdch budu hovo\u0159it. Obvykle se datab\u00e1ze sestavuj\u00ed v re\u017eimu master-slave pro zaji\u0161t\u011bn\u00ed dostupnosti. Nezapome\u0148te prov\u00e9st tato nastaven\u00ed na slave, proto\u017ee v jeden kr\u00e1sn\u00fd okam\u017eik m\u016f\u017ee doj\u00edt k hav\u00e1rii a p\u0159epnete na slave, kter\u00fd se stane mistrem. <\/p>\n
<\/p>\n
V havarijn\u00ed situaci, kdy je v\u0161echno velmi \u0161patn\u00e9, v\u00e1m neust\u00e1le zvon\u00ed telefon a \u0161\u00e9f b\u011b\u017e\u00ed s velk\u00fdm kladivem, nebudete m\u00edt \u010das p\u0159em\u00fd\u0161let o kontrole. A v\u00fdsledky mohou b\u00fdt velmi katastrof\u00e1ln\u00ed.<\/p>\n
<\/p>\n
<\/p>\n
Dal\u0161\u00ed v\u011bc \u2013 to jsou obrovsk\u00e9 str\u00e1nky. Obrovsk\u00e9 str\u00e1nky se komplikuj\u00ed odd\u011blen\u011b testovat, a ani to ned\u00e1v\u00e1 smysl, a\u010dkoliv existuj\u00ed benchmarky, kter\u00e9 to dok\u00e1\u017eou. Ty se snadno najdou. <\/p>\n
<\/p>\n
O co jde? M\u00e1te server, kter\u00fd nen\u00ed p\u0159\u00edli\u0161 drah\u00fd, ale m\u00e1 hodn\u011b opera\u010dn\u00ed pam\u011bti, nap\u0159\u00edklad v\u00edce ne\u017e 30 GB. Obrovsk\u00e9 str\u00e1nky se nepou\u017e\u00edvaj\u00ed. To znamen\u00e1, \u017ee ur\u010dit\u011b m\u00e1te overhead p\u0159i vyu\u017e\u00edv\u00e1n\u00ed pam\u011bti. A tento overhead nen\u00ed zrovna p\u0159\u00edjemn\u00fd. <\/p>\n
<\/p>\n
<\/p>\n
Pro\u010d to tak je? A co se d\u011bje? Opera\u010dn\u00ed syst\u00e9m p\u0159id\u011bluje pam\u011b\u0165 po mal\u00fdch kousc\u00edch. Je to pohodln\u00e9, tak to historicky vzniklo. A pokud se pono\u0159\u00edte do podrobnost\u00ed, tak OS mus\u00ed p\u0159ev\u00e1d\u011bt virtu\u00e1ln\u00ed adresy na fyzick\u00e9. A tento proces nen\u00ed zrovna jednoduch\u00fd, proto hasil OS v\u00fdsledek t\u00e9to operace ukl\u00e1d\u00e1 do vyrovn\u00e1vac\u00ed pam\u011bti Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
A proto\u017ee TLB je vyrovn\u00e1vac\u00ed pam\u011b\u0165, v takov\u00e9 situaci vznikaj\u00ed v\u0161echny probl\u00e9my, kter\u00e9 vyrovn\u00e1vac\u00ed pam\u011b\u0165 m\u00e1. Za prv\u00e9, pokud m\u00e1te velmi hodn\u011b opera\u010dn\u00ed pam\u011bti a ta je cel\u00e1 p\u0159id\u011blen\u00e1 po mal\u00fdch kousc\u00edch, tak se tento buffer st\u00e1v\u00e1 velmi velk\u00fdm. A pokud je vyrovn\u00e1vac\u00ed pam\u011b\u0165 velk\u00e1, tak se v n\u00ed hled\u00e1 pomaleji. Overhead je zna\u010dn\u00fd a s\u00e1m zab\u00edr\u00e1 m\u00edsto, tj. opera\u010dn\u00ed pam\u011b\u0165 spot\u0159ebov\u00e1v\u00e1 n\u011bco nespr\u00e1vn\u00e9ho. To je prvn\u00ed probl\u00e9m. <\/p>\n
<\/p>\n
Dv\u011b \u2013 \u010d\u00edm v\u00edce se v t\u00e9to situaci rozr\u016fst\u00e1 cache, t\u00edm v\u011bt\u0161\u00ed je pravd\u011bpodobnost, \u017ee dojde k cache miss. A efektivita t\u00e9to cache rychle kles\u00e1 s n\u00e1r\u016fstem jej\u00ed velikosti. Proto v opera\u010dn\u00edch syst\u00e9mech vymysleli jednoduch\u00fd p\u0159\u00edstup. V Linuxu se ji\u017e dlouho pou\u017e\u00edv\u00e1. Ve FreeBSD se ned\u00e1vno objevil. Ale mluv\u00edme o Linuxu. To jsou huge pages.<\/p>\n
<\/p>\n
A tady je t\u0159eba poznamenat, \u017ee my\u0161lenka huge pages byla p\u016fvodn\u011b prosazena komunitami, kter\u00e9 zahrnovaly Oracle a IBM, tedy v\u00fdrobci datab\u00e1z\u00ed d\u016fkladn\u011b p\u0159em\u00fd\u0161leli o tom, \u017ee to bude u\u017eite\u010dn\u00e9, v\u010detn\u011b datab\u00e1z\u00ed. <\/p>\n
<\/p>\n
<\/p>\n
A jak to sladit s PostgreSQL? Za prv\u00e9, v j\u00e1dru Linuxu mus\u00ed b\u00fdt zapnuty huge pages.<\/p>\n
<\/p>\n
Za druh\u00e9, musej\u00ed b\u00fdt v\u00fdslovn\u011b uvedeny parametrem sysctl \u2013 kolik jich je. \u010c\u00edsla jsou z n\u011bjak\u00e9ho star\u00e9ho serveru. M\u016f\u017eete spo\u010d\u00edtat, kolik p\u0159ibli\u017en\u011b m\u00e1te shared buffers, aby se do huge pages ve\u0161ly. <\/p>\n
<\/p>\n
A pokud m\u00e1te cel\u00fd server v\u011bnovan\u00fd PostgreSQL, dobr\u00fd v\u00fdchoz\u00ed bod je bu\u010f 25 % opera\u010dn\u00ed pam\u011bti v\u011bnovat na shared buffery, nebo 75 %, pokud si jste jisti, \u017ee ve skute\u010dn\u011b 75 % se va\u0161e datab\u00e1ze jist\u011b vejde. Prvn\u00ed v\u00fdchoz\u00ed bod. A spo\u010d\u00edtejte, pokud m\u00e1te 256 GB opera\u010dn\u00ed pam\u011bti, odpov\u00eddaj\u00edc\u00edch 64 GB bude va\u0161ich shared buffer\u016f. Spo\u010d\u00edtejte p\u0159ibli\u017en\u011b s n\u011bjakou rezervou \u2013 na co byste tuto \u010d\u00edslici m\u011bli nastavit.<\/p>\n
<\/p>\n
Do verze 9.2 (pokud se nem\u00fdl\u00edm, od verze 8.2) bylo mo\u017en\u00e9 pomoc\u00ed extern\u00ed knihovny sladit PostgreSQL s huge pages. A to je v\u017edy pot\u0159eba ud\u011blat. Za prv\u00e9, pot\u0159ebujete, aby j\u00e1dro um\u011blo spr\u00e1vn\u011b alokovat huge pages. A za druh\u00e9, aby aplikace, kter\u00e1 s nimi pracuje, mohla vyu\u017e\u00edt jejich potenci\u00e1l. Jen tak je nevyu\u017eije. Proto\u017ee PostgreSQL alokoval pam\u011b\u0165 ve stylu system 5, to bylo mo\u017en\u00e9 prov\u00e9st pomoc\u00ed libhugetlbfs \u2013 to je cel\u00e9 jm\u00e9no knihovny.<\/p>\n
<\/p>\n
Ve verzi 9.3 byla zlep\u0161ena v\u00fdkonnost PostgreSQL p\u0159i pr\u00e1ci s pam\u011bt\u00ed a byl opu\u0161t\u011bn syst\u00e9m 5 pro alokaci pam\u011bti. V\u0161ichni byli velmi r\u00e1di, proto\u017ee jinak se sna\u017e\u00edte spustit dva instance PostgreSQL na jednom stroji, a on \u0159\u00edk\u00e1, \u017ee mu chyb\u00ed sd\u00edlen\u00e1 pam\u011b\u0165. A \u0159\u00edk\u00e1, \u017ee je t\u0159eba upravit sysctl. A ten sysctl je takov\u00fd, \u017ee je pot\u0159eba je\u0161t\u011b restartovat atd. Celkov\u011b bylo hodn\u011b radosti. Ale alokace pam\u011bti mmap rozbila pou\u017eit\u00ed huge pages. V\u011bt\u0161ina na\u0161ich klient\u016f pou\u017e\u00edv\u00e1 velk\u00e9 sd\u00edlen\u00e9 buffery. A my d\u016frazn\u011b doporu\u010dujeme, abyste nep\u0159ech\u00e1zeli na 9.3, proto\u017ee tam overhead za\u010d\u00ednal dosahovat zna\u010dn\u00fdch procent.<\/p>\n
<\/p>\n
Ale komunita si t\u00e9to probl\u00e9my v\u0161imla a ve verzi 9.4 to velmi dob\u0159e p\u0159epracovali. A ve verzi 9.4 se objevila mo\u017enost v postgresql.conf, kde m\u016f\u017eete nastavit try, on nebo off.<\/p>\n
<\/p>\n
Try je nejbezpe\u010dn\u011bj\u0161\u00ed nastaven\u00ed. P\u0159i startu PostgreSQL, kdy\u017e alokuje sd\u00edlenou pam\u011b\u0165, sna\u017e\u00ed se z\u00edskat tuto pam\u011b\u0165 z huge pages. A pokud se to nepoda\u0159\u00ed, vr\u00e1t\u00ed se k b\u011b\u017en\u00e9 alokaci. A pokud m\u00e1te FreeBSD nebo Solaris, m\u016f\u017eete nastavit try, to je v\u017edy bezpe\u010dn\u00e9. <\/p>\n
<\/p>\n
Pokud je nastaveno on, tak se prost\u011b nespust\u00ed, pokud se mu nepoda\u0159\u00ed alokovat z huge pages. Tady u\u017e jde o to, co je pro v\u00e1s mil\u00e9. Ale pokud m\u00e1te nastaveno try, m\u011bli byste zkontrolovat, zda se v\u00e1m opravdu alokovalo to, co pot\u0159ebujete, proto\u017ee prostor pro chyby je zde zna\u010dn\u00fd. Tento funk\u010dnost nyn\u00ed funguje pouze na Linuxu.<\/p>\n
<\/p>\n
Je\u0161t\u011b jednota mal\u00e1 pozn\u00e1mka, ne\u017e p\u016fjdeme d\u00e1l. Transparent huge pages zat\u00edm nejsou o PostgreSQL. Nem\u016f\u017ee je vyu\u017e\u00edt norm\u00e1ln\u011b. A p\u0159i pou\u017eit\u00ed Transparent huge pages pro takov\u00e9 workloady, kdy pot\u0159ebujete velk\u00fd kus sd\u00edlen\u00e9 pam\u011bti, se v\u00fdhody dostavuj\u00ed pouze p\u0159i opravdu velk\u00fdch objemech. Pokud m\u00e1te terabyty pam\u011bti, m\u016f\u017ee to hr\u00e1t roli. Pokud mluv\u00edme o v\u00edce b\u011b\u017en\u00fdch aplikac\u00edch, kdy m\u00e1te 32, 64, 128, 256 GB pam\u011bti na stroji, tak b\u011b\u017en\u00e9 huge pages jsou v po\u0159\u00e1dku, a transparentn\u00ed prost\u011b vyp\u00edn\u00e1me. <\/p>\n
<\/p>\n
<\/p>\n
A posledn\u00ed v\u011bc, kter\u00e1 se t\u00fdk\u00e1 pam\u011bti, nen\u00ed p\u0159\u00edmo spojena s propustnost\u00ed, ale m\u016f\u017ee velmi zt\u00ed\u017eit \u017eivot. Cel\u00e1 propustnost bude siln\u011b ovlivn\u011bna t\u00edm, \u017ee server neust\u00e1le swapuje. <\/p>\n
<\/p>\n
A to bude velmi nep\u0159\u00edjemn\u00e9 v n\u011bkolika ohledech. Hlavn\u00ed nep\u0159\u00edjemnost spo\u010d\u00edv\u00e1 v tom, \u017ee v modern\u00edch j\u00e1drech se chov\u00e1n\u00ed m\u00edrn\u011b li\u0161\u00ed od star\u0161\u00edch jader Linuxu. A na to se velmi t\u011b\u017eko do\u0161l\u00e1pne, proto\u017ee kdy\u017e mluv\u00edme o n\u011bjak\u00e9 pr\u00e1ci se swapem, kon\u010d\u00ed to pozdn\u00edm p\u0159\u00edchodem OOM-killera. A OOM-killer, kter\u00fd p\u0159i\u0161el pozd\u011b a zabil PostgreSQL, je opravdu nep\u0159\u00edjemn\u00e9. O tom se dozv\u00ed v\u0161ichni, tj. a\u017e po posledn\u00edho u\u017eivatele. <\/p>\n
<\/p>\n
<\/p>\n
Co se d\u011bje? M\u00e1te tam velk\u00e9 mno\u017estv\u00ed pam\u011bti, v\u0161e funguje dob\u0159e. Ale z n\u011bjak\u00e9ho d\u016fvodu server vis\u00ed ve swapu a kv\u016fli tomu zpomaluje. Zd\u00e1lo by se, \u017ee pam\u011bti je dostatek, ale takto se to d\u011bje. <\/p>\n
<\/p>\n
<\/p>\n
D\u0159\u00edve jsme doporu\u010dovali nastavit vm.swappiness na nulu, tj. vypnout swap. D\u0159\u00edve se zd\u00e1lo, \u017ee 32 GB opera\u010dn\u00ed pam\u011bti a odpov\u00eddaj\u00edc\u00ed sd\u00edlen\u00e9 buffery \u2013 to je obrovsk\u00e9 mno\u017estv\u00ed. Hlavn\u00edm \u00fa\u010delem swapu je poskytovat m\u00edsto, kam se d\u00e1 d\u00e1t j\u00e1dro, kdy\u017e sel\u017ee. A to u\u017e moc nefungovalo. A co pak s t\u00edm j\u00e1drem ud\u011blat? To u\u017e je \u00fakol, u kter\u00e9ho nen\u00ed jasn\u00e9, pro\u010d je swap tak velk\u00fd pot\u0159ebn\u00fd. <\/p>\n
<\/p>\n
Ale v modern\u011bj\u0161\u00edch, tj. ve t\u0159et\u00edch verz\u00edch jader, se chov\u00e1n\u00ed zm\u011bnilo. A pokud nastav\u00edte swap na nulu, tj. vypnete ho, d\u0159\u00edve \u010di pozd\u011bji, i p\u0159i ponechan\u00e9 ur\u010dit\u00e9 opera\u010dn\u00ed pam\u011bti, k v\u00e1m p\u0159ijde OOM-killer, aby zabil nejintenzivn\u011bj\u0161\u00ed spot\u0159ebitele. Proto\u017ee bude pova\u017eovat, \u017ee p\u0159i t\u00e9to z\u00e1t\u011b\u017ei n\u00e1m je\u0161t\u011b tro\u0161ku zb\u00fdv\u00e1 a vysko\u010d\u00ed, tj. nezabil syst\u00e9mov\u00fd proces, ale zabil n\u011bco m\u00e9n\u011b d\u016fle\u017eit\u00e9ho. T\u00edm m\u00e9n\u011b d\u016fle\u017eit\u00fdm se uk\u00e1\u017ee b\u00fdt intenzivn\u00ed spot\u0159ebitel sd\u00edlen\u00e9 pam\u011bti, konkr\u00e9tn\u011b postmaster. A po tom bude dob\u0159e, pokud nebude nutn\u00e9 obnovovat datab\u00e1zi. <\/p>\n
<\/p>\n
Proto nyn\u00ed defaultn\u011b, pokud si pamatuji, v\u011bt\u0161ina distribuc\u00ed je n\u011bkde okolo 6, tj. v jak\u00e9m okam\u017eiku za\u010d\u00edt pou\u017e\u00edvat swap v z\u00e1vislosti na tom, kolik pam\u011bti zb\u00fdv\u00e1. Nyn\u00ed doporu\u010dujeme nastavit vm.swappiness = 1, proto\u017ee to prakticky vyp\u00edn\u00e1, ale ned\u00e1v\u00e1 takov\u00e9 efekty, jako kdy\u017e OOM-killer p\u0159ijde ne\u010dekan\u011b a v\u0161e zabil.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Co d\u00e1l? Kdy\u017e mluv\u00edme o v\u00fdkonu datab\u00e1z\u00ed a postupn\u011b se dost\u00e1v\u00e1me k disk\u016fm, v\u0161ichni se chytaj\u00ed za hlavu. Proto\u017ee pravda o tom, \u017ee disk je pomal\u00fd a pam\u011b\u0165 rychl\u00e1, je v\u0161em zn\u00e1m\u00e1 od d\u011btstv\u00ed. A v\u0161ichni v\u011bd\u00ed, \u017ee v datab\u00e1zi budou probl\u00e9my s diskov\u00fdm v\u00fdkonem.<\/p>\n
<\/p>\n
Hlavn\u00ed probl\u00e9m s v\u00fdkonem PostgreSQL, spojen\u00fd s v\u00fdkyvy p\u0159i kontroln\u00edch bodech, nevznik\u00e1 kv\u016fli tomu, \u017ee je disk pomal\u00fd. Je to sp\u00ed\u0161e proto, \u017ee propustnost pam\u011bti a disku nen\u00ed vyv\u00e1\u017een\u00e1. Ta m\u016f\u017ee b\u00fdt nevyv\u00e1\u017een\u00e1 na r\u016fzn\u00fdch m\u00edstech. PostgreSQL nen\u00ed nakonfigurov\u00e1no, opera\u010dn\u00ed syst\u00e9m nen\u00ed nakonfigurov\u00e1n, hardware nen\u00ed nakonfigurov\u00e1n a hardware je nespr\u00e1vn\u00fd. K t\u00e9to probl\u00e9mu nedoch\u00e1z\u00ed jen tehdy, kdy\u017e je v\u0161echno nastaven\u00e9 spr\u00e1vn\u011b, tj. bu\u010f nen\u00ed z\u00e1t\u011b\u017e, nebo jsou nastaven\u00ed a hardware dob\u0159e p\u0159izp\u016fsoben\u00e9. <\/p>\n
<\/p>\n
<\/p>\n
Co to je a jak to vypad\u00e1? Obvykle lid\u00e9, kte\u0159\u00ed pracuj\u00ed s PostgreSQL, se do t\u00e9to z\u00e1le\u017eitosti dostali opakovan\u011b. Vysv\u011btl\u00edm. Jak jsem \u0159\u00edkal, PostgreSQL pravideln\u011b prov\u00e1d\u00ed kontroln\u00ed body, aby ulo\u017eil \u0161pinav\u00e9 str\u00e1nky ze sd\u00edlen\u00e9 pam\u011bti na disk. Pokud m\u00e1me velk\u00fd objem sd\u00edlen\u00e9 pam\u011bti, kontroln\u00ed bod za\u010dne intenzivn\u011b ovliv\u0148ovat disk, proto\u017ee zapisuje tyto str\u00e1nky pomoc\u00ed fsync. Dosa\u017een\u00e9 data putuj\u00ed do j\u00e1dra bufferu a zapisuj\u00ed se na disky za pomoci fsync. A pokud je objem tohoto procesu velk\u00fd, m\u016f\u017eeme pozorovat nep\u0159\u00edjemn\u00fd efekt, a to velmi vysokou vyu\u017eitelnost disk\u016f.<\/p>\n
<\/p>\n
Tady m\u00e1m dv\u011b obr\u00e1zky. Te\u010f vysv\u011btl\u00edm, co to je. To jsou dva grafy korelovan\u00e9 podle \u010dasu. Prvn\u00ed graf \u2013 to je vyu\u017eitelnost disku. V tuto chv\u00edli dosahuje t\u00e9m\u011b\u0159 90 %. Pokud m\u00e1te datab\u00e1zovou z\u00e1t\u011b\u017e s fyzick\u00fdmi disky, s RAID \u0159adi\u010dem, a vyu\u017eitelnost je pod 90 %, to jsou \u0161patn\u00e9 zpr\u00e1vy. To znamen\u00e1, \u017ee je\u0161t\u011b kousek a dos\u00e1hnete 100 a vstup-v\u00fdstup se zastav\u00ed. <\/p>\n
<\/p>\n
Pokud m\u00e1te diskov\u00fd arraj, je to trochu jin\u00fd p\u0159\u00edb\u011bh. Z\u00e1vis\u00ed to na tom, jak je nastaven, jak\u00fd to je arraj atd. <\/p>\n
<\/p>\n
Sou\u010dasn\u011b je zde nakonfigurov\u00e1n graf z intern\u00ed postgresov\u00e9 pohledu, kter\u00fd ukazuje, jak prob\u00edh\u00e1 checkpoint. A zelenou barvou je zde indikov\u00e1no, kolik buffer\u016f, t\u011bchto \u0161pinav\u00fdch str\u00e1nek, v tuto chv\u00edli dorazilo v tomto checkpointu k synchronizaci. A to je hlavn\u00ed, co zde pot\u0159ebujete v\u011bd\u011bt. Vid\u00edme, \u017ee zde m\u00e1me spoustu str\u00e1nek, a v n\u011bjak\u00e9m okam\u017eiku jsme narazili na limit, tedy jsme psali-psali, zde je z\u0159ejm\u00e9, \u017ee diskov\u00fd syst\u00e9m je velmi siln\u011b zat\u00ed\u017een. A n\u00e1\u0161 checkpoint m\u00e1 velmi siln\u00fd dopad na disk. Ide\u00e1ln\u011b by situace m\u011bla vypadat sp\u00ed\u0161e takto, tedy zde by bylo m\u00e9n\u011b z\u00e1pisu. A pomoc\u00ed nastaven\u00ed to m\u016f\u017eeme opravit, abychom to tak m\u011bli i nad\u00e1le. Tedy, zat\u00ed\u017een\u00ed je mal\u00e9, ale n\u011bkde n\u011bco zde zapisujeme. <\/p>\n
<\/p>\n
Co je pot\u0159eba ud\u011blat, abyste tento probl\u00e9m vy\u0159e\u0161ili? Pokud se v\u00e1m zastavilo IO pod datab\u00e1z\u00ed, znamen\u00e1 to, \u017ee v\u0161ichni u\u017eivatel\u00e9, kte\u0159\u00ed p\u0159i\u0161li vykon\u00e1vat sv\u00e9 dotazy, budou \u010dekat. <\/p>\n
<\/p>\n
<\/p>\n
Pokud se pod\u00edv\u00e1te z pohledu Linuxu, pokud m\u00e1te dobr\u00fd hardware, spr\u00e1vn\u011b ho nastav\u00edte a norm\u00e1ln\u011b nastav\u00edte PostgreSQL, aby tyto checkointy d\u011blalo m\u00e9n\u011b \u010dasto, rozprost\u0159elo je v \u010dase mezi sebou, naraz\u00edte na v\u00fdchoz\u00ed parametry Debianu. Pro v\u011bt\u0161inu distribuc\u00ed Linuxu plat\u00ed n\u00e1sleduj\u00edc\u00ed obr\u00e1zek: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Co to znamen\u00e1? Od j\u00e1dra 2.6 se objevil jeden demon pro vymaz\u00e1n\u00ed. Pgflush, v z\u00e1vislosti na tom, kdo co pou\u017e\u00edv\u00e1, kter\u00fd se zab\u00fdv\u00e1 backgroundn\u00edm vymaz\u00e1v\u00e1n\u00edm \u0161pinav\u00fdch str\u00e1nek z j\u00e1dra bufferu a vymaz\u00e1v\u00e1n\u00edm, kdykoliv je to nutn\u00e9, dokud backgroundn\u00ed vymaz\u00e1v\u00e1n\u00ed nepom\u00e1h\u00e1. <\/p>\n
<\/p>\n
Kdy nast\u00e1v\u00e1 background? Kdy\u017e 10 % z cel\u00e9 opera\u010dn\u00ed pam\u011bti, kter\u00e1 je na serveru, je obsazeno \u0161pinav\u00fdmi str\u00e1nkami v kernel bufferu, je zavol\u00e1na speci\u00e1ln\u00ed funkce pro vymaz\u00e1n\u00ed na pozad\u00ed. Pro\u010d je to backgroundn\u00ed? P\u0159ij\u00edm\u00e1 jako parametr, kolik str\u00e1nek vymazat. A nap\u0159\u00edklad vymaz\u00e1v\u00e1 N str\u00e1nek. A na n\u011bjakou dobu tato v\u011bc usne. A pak se znovu vr\u00e1t\u00ed a vymaz\u00e1v\u00e1 n\u011bjak\u00fd dal\u0161\u00ed po\u010det str\u00e1nek. <\/p>\n
<\/p>\n
To je nesm\u00edrn\u011b jednoduch\u00fd p\u0159\u00edb\u011bh. Je to jako s baz\u00e9nem, kdy\u017e do jedn\u00e9 trubky te\u010de voda, do druh\u00e9 zase odt\u00e9k\u00e1. N\u00e1\u0161 checkpoint p\u0159i\u0161el a pokud poslal m\u00e1lo \u0161pinav\u00fdch str\u00e1nek na vymaz\u00e1n\u00ed, tak se postupn\u011b z kernel bufferu pgflush v\u0161e tohle jemn\u011b rozplyne. <\/p>\n
<\/p>\n
Pokud se tyto \u0161pinav\u00e9 str\u00e1nky nad\u00e1le hromad\u00ed, dosahuj\u00ed a\u017e 20 %, pot\u00e9 je prioritou opera\u010dn\u00edho syst\u00e9mu je zapsat na disk, proto\u017ee dojde k v\u00fdpadku nap\u00e1jen\u00ed a v\u0161e dopadne \u0161patn\u011b. Ztrat\u00edme tato data, nap\u0159\u00edklad. <\/p>\n
<\/p>\n
Jak\u00fd je trik? Trik spo\u010d\u00edv\u00e1 v tom, \u017ee tyto parametry, kter\u00e9 p\u0159edstavuj\u00ed 20 a 10 % z cel\u00e9 opera\u010dn\u00ed pam\u011bti v za\u0159\u00edzen\u00ed, jsou z hlediska propustnosti jak\u00e9hokoli diskov\u00e9ho syst\u00e9mu naprosto monstr\u00f3zn\u00ed.<\/strong> <\/p>\n<\/p>\n
P\u0159edstavte si, \u017ee m\u00e1te 128 GB opera\u010dn\u00ed pam\u011bti. 12,8 GB se dostane do va\u0161eho diskov\u00e9ho syst\u00e9mu. A bez ohledu na to, jak\u00fd m\u00e1te tam cache nebo pole, to nevydr\u017e\u00ed. <\/p>\n
<\/p>\n
<\/p>\n
Proto doporu\u010dujeme tyto \u010d\u00edsla hned nastavit podle schopnost\u00ed va\u0161eho RAID \u0159adi\u010de.<\/strong> M\u00e1m zde ihned doporu\u010den\u00ed pro \u0159adi\u010d, kter\u00fd m\u00e1 512 MB cache. <\/p>\n<\/p>\n
V\u0161echno se po\u010d\u00edt\u00e1 velmi jednodu\u0161e. M\u016f\u017eete nastavit vm.dirty_background v bajtech. A tato nastaven\u00ed ru\u0161\u00ed p\u0159edchoz\u00ed dv\u011b. A\u0165 u\u017e pom\u011br podle defaultu, nebo aktivovan\u00e9 ty s bajty, tedy budou fungovat ty s bajty. Ale jeliko\u017e jsem DBA konzultant a pracuji s r\u016fzn\u00fdmi klienty, sna\u017e\u00edm se pokr\u00fdt v\u0161echny mo\u017enosti, a proto, pokud v bajtech, tak v bajtech. Nikdo nezaru\u010dil, \u017ee hodn\u00fd admin nep\u0159id\u00e1 pam\u011b\u0165 serveru, nep\u0159evede ho zp\u011bt, a \u010d\u00edslo z\u016fstane stejn\u00e9. Jednodu\u0161e po\u010d\u00edtejte ta \u010d\u00edsla tak, aby se v\u0161echno vlezlo s jistotou. <\/p>\n
<\/p>\n
Co se stane, pokud se nevejdete? Je uvedeno, \u017ee efektivn\u011b se zastavuje jak\u00e9koli flushov\u00e1n\u00ed, ale ve skute\u010dnosti je to obrazn\u00fd v\u00fdraz. Opera\u010dn\u00ed syst\u00e9m m\u00e1 velk\u00fd probl\u00e9m \u2013 m\u00e1 hodn\u011b \u0161pinav\u00fdch str\u00e1nek, tak\u017ee efektivn\u011b se zastavuje ten IO, kter\u00fd generuj\u00ed va\u0161i klienti, tj. aplikace, kter\u00e1 pos\u00edl\u00e1 SQL dotaz do datab\u00e1ze, \u010dek\u00e1. Jak\u00fdkoli vstup-v\u00fdstup do n\u00ed je v nejni\u017e\u0161\u00ed priorit\u011b, proto\u017ee datab\u00e1ze je zanepr\u00e1zdn\u011bna checkpointem. A kdy to dokon\u010d\u00ed, nen\u00ed jasn\u00e9. A kdy\u017e dos\u00e1hnete ne-fondu, ne-pozad\u00ed flushingu, znamen\u00e1 to, \u017ee ve\u0161ker\u00e9 IO je t\u00edmto zanepr\u00e1zdn\u011bno. A dokud to neskon\u010d\u00ed, nic neud\u011bl\u00e1te. <\/p>\n
<\/p>\n
Je tu je\u0161t\u011b dva d\u016fle\u017eit\u00e9 momenty, kter\u00e9 p\u0159esahuj\u00ed tento refer\u00e1t. Tato nastaven\u00ed mus\u00ed odpov\u00eddat nastaven\u00edm v postgresql.conf, tj. nastaven\u00ed checkpoint\u016f. A v\u00e1\u0161 diskov\u00fd syst\u00e9m mus\u00ed b\u00fdt adekv\u00e1tn\u011b nastaven. Pokud m\u00e1te cache na RAID, m\u011bla by na n\u011bm b\u00fdt baterie.<\/strong> Lid\u00e9 kupuj\u00ed RAID s dobr\u00fdm cache bez baterie. Pokud m\u00e1te SSD v RAID, mus\u00ed to b\u00fdt serverov\u00e9, m\u011bly by tam b\u00fdt kondenz\u00e1tory.<\/strong> Tady je podrobn\u00fd checklist. Na tomto odkazu je moje zpr\u00e1va o nastaven\u00ed v\u00fdkonu disku v PostgreSQL. Tam jsou v\u0161echny tyto checklisty. <\/p>\n<\/p>\n
<\/p>\n
Co je\u0161t\u011b m\u016f\u017ee velmi zkomplikovat \u017eivot? To jsou dva parametry. Jsou relativn\u011b nov\u00e9. Mohou b\u00fdt ve v\u00fdchoz\u00edm nastaven\u00ed zapnuty v r\u016fzn\u00fdch aplikac\u00edch. A mohou zkomplikovat \u017eivot nejen v p\u0159\u00edpad\u011b, \u017ee budou nespr\u00e1vn\u011b zapnuty. <\/p>\n
<\/p>\n
<\/p>\n
Existuj\u00ed dv\u011b relativn\u011b nov\u00e9 v\u011bci. Objevily se ji\u017e ve t\u0159et\u00edch j\u00e1drech. To je sched_migration_cost v nanosekund\u00e1ch a sched_autogroup_enabled, kter\u00e1 je ve v\u00fdchoz\u00edm nastaven\u00ed zapnuta. <\/p>\n
<\/p>\n
A jak zhor\u0161uj\u00ed \u017eivot? Co je sched_migration_cost? Linuxov\u00fd pl\u00e1nova\u010d m\u016f\u017ee migrovat proces z jednoho CPU na druh\u00fd. A pro PostgreSQL, kter\u00e9 vykon\u00e1v\u00e1 dotazy, je migrace na jin\u00fd CPU zcela nepochopiteln\u00e1. Z pohledu opera\u010dn\u00edho syst\u00e9mu, kdy\u017e p\u0159ep\u00edn\u00e1te okna mezi openoffice a termin\u00e1lem, to m\u016f\u017ee b\u00fdt u\u017eite\u010dn\u00e9, ale pro datab\u00e1zi \u2013 to je velmi \u0161patn\u00e9.<\/strong> Proto je rozumn\u00e1 politika nastavit migration_cost na n\u011bjakou vysokou hodnotu, alespo\u0148 n\u011bkolik tis\u00edc nanosekund.<\/strong> <\/p>\n<\/p>\n
Co to bude znamenat pro pl\u00e1nova\u010d? Bude se domn\u00edvat, \u017ee po tuto dobu je tento proces st\u00e1le aktivn\u00ed. Tedy pokud m\u00e1 n\u011bjakou dlouhou transakci, kter\u00e1 n\u011bco dlouho d\u011bl\u00e1, pl\u00e1nova\u010d to pochop\u00ed. Bude se domn\u00edvat, \u017ee dokud neuplyne tento \u010dasov\u00fd limit, nem\u00e1 d\u016fvod tento proces migrovat. Pokud tento proces n\u011bco d\u011bl\u00e1, nebude migrov\u00e1n, klidn\u011b dokon\u010d\u00ed svou pr\u00e1ci na tom CPU, kter\u00e9 mu bylo p\u0159id\u011bleno. A v\u00fdsledek je skv\u011bl\u00fd. <\/p>\n
<\/p>\n
Druh\u00e1 v\u011bc \u2013 to je autogroup. Je to dobr\u00fd n\u00e1pad pro specifick\u00e9 pracovn\u00ed z\u00e1t\u011b\u017ee, kter\u00e9 nemaj\u00ed nic spole\u010dn\u00e9ho se modern\u00edmi datab\u00e1zemi \u2013 skupinovat procesy podle virtu\u00e1ln\u00edho termin\u00e1lu, ze kter\u00e9ho byly spu\u0161t\u011bny. To je u\u017eite\u010dn\u00e9 pro ur\u010dit\u00e9 \u00fakoly. Ve skute\u010dnosti je PostgreSQL mnohoprocessn\u00ed syst\u00e9m s preforkem, kter\u00fd se spou\u0161t\u00ed z jednoho termin\u00e1lu. M\u00e1te zamknut\u00e9ho zapisova\u010de, checkpoint a v\u0161echny va\u0161e klientsk\u00e9 po\u017eadavky se shrom\u00e1\u017ed\u00ed na jednom pl\u00e1nova\u010di, na jednom CPU. A budou tam trp\u011bliv\u011b \u010dekat, a\u017e se uvoln\u00ed, aby si navz\u00e1jem p\u0159ek\u00e1\u017eeli a zab\u00edrali ho co nejd\u00e9le. To je p\u0159\u00edb\u011bh, kter\u00fd je naprosto zbyte\u010dn\u00fd p\u0159i takov\u00e9m zat\u00ed\u017een\u00ed, a proto to je t\u0159eba vypnout.<\/strong><\/p>\n<\/p>\n
<\/p>\n
M\u016fj kolega Alexej Lesovskij prov\u00e1d\u011bl testy se z\u00e1kladn\u00edm pgbench, kde zv\u00fd\u0161il o \u0159\u00e1d migration_cost a vypnul autogroup. Rozd\u00edl na \u0161patn\u00e9m hardwaru \u010dinil t\u00e9m\u011b\u0159 10 %<\/strong>. Existuje diskuse v po\u0161tovn\u00ed skupin\u011b PostgreSQL, kde lid\u00e9 uv\u00e1d\u011bj\u00ed v\u00fdsledky, jak podobn\u00e9 zm\u011bny ovlivnily rychlost po\u017eadavku o 50 %<\/strong>. Takov\u00fdch p\u0159\u00edb\u011bh\u016f je docela hodn\u011b.<\/p>\n<\/p>\n
<\/p>\n
A nakonec o politice \u00faspory energie. Je dobr\u00e9, \u017ee nyn\u00ed lze Linux pou\u017e\u00edvat na notebooku. A \u00fadajn\u011b by m\u011bl dob\u0159e spot\u0159ebov\u00e1vat baterii. Ale n\u00e1hle se ukazuje, \u017ee na serveru to tak\u00e9 m\u016f\u017ee b\u00fdt. <\/p>\n
<\/p>\n
Nav\u00edc, pokud si pronaj\u00edm\u00e1te servery od n\u011bjak\u00e9ho poskytovatele, ti \"hodn\u00ed\" hostitel\u00e9<\/a> se nestaraj\u00ed o to, abyste m\u011bli lep\u0161\u00ed v\u00fdkon. Jejich \u00fakolem je zajistit, aby jejich hardware byl maxim\u00e1ln\u011b efektivn\u011b vyu\u017e\u00edv\u00e1n. Proto mohou m\u00edt ve v\u00fdchoz\u00edm nastaven\u00ed na opera\u010dn\u00edm syst\u00e9mu zapnut\u00fd re\u017eim \u00faspory energie pro notebooky.<\/p>\n<\/p>\n
Pokud na serveru s datab\u00e1z\u00ed pod intenzivn\u00ed z\u00e1t\u011b\u017e\u00ed pou\u017e\u00edv\u00e1te toto vybaven\u00ed, va\u0161\u00ed volbou je acpi_cpufreq + performance. I s ondemandem u\u017e budou probl\u00e9my.<\/strong> <\/p>\n<\/p>\n
Intel_pstate je u\u017e trochu jin\u00fd ovlada\u010d. A v sou\u010dasnosti se d\u00e1v\u00e1 p\u0159ednost tomuto, proto\u017ee je nov\u011bj\u0161\u00ed a l\u00e9pe funguje.<\/p>\n
<\/p>\n
A podle toho je guvern\u00e9r jen performance. Ondemand, powersave a v\u0161echno ostatn\u00ed \u2013 to nen\u00ed pro v\u00e1s. <\/p>\n
<\/p>\n
V\u00fdsledky z explain analyze PostgreSQL se mohou li\u0161it o n\u011bkolik \u0159\u00e1d\u016f, pokud zapnete powersave, proto\u017ee prakticky v\u00e1\u0161 CPU bude pl\u00e1nov\u00e1n zcela nep\u0159edv\u00eddateln\u00fdm zp\u016fsobem pod datab\u00e1z\u00ed.<\/p>\n
<\/p>\n
Tyto v\u011bci mohou b\u00fdt zapnuty ve v\u00fdchoz\u00edm nastaven\u00ed. Pozorn\u011b se pod\u00edvejte \u2013 nezapnuli je n\u00e1hodou ve v\u00fdchoz\u00edm nastaven\u00ed. To m\u016f\u017ee b\u00fdt opravdu velk\u00fd probl\u00e9m. <\/p>\n
<\/p>\n
<\/p>\n
A nakonec bych cht\u011bl pod\u011bkovat kluk\u016fm z na\u0161eho DBA t\u00fdmu PosgreSQL-Consulting, konkr\u00e9tn\u011b Maxovi Bohukovi a Alexejovi Lesovsk\u00e9mu, kte\u0159\u00ed se ka\u017ed\u00fd den u\u010d\u00ed z r\u016fzn\u00fdch situac\u00ed. Pro na\u0161e klienty se sna\u017e\u00edme ud\u011blat v\u0161echno co nejl\u00e9pe, aby to po\u0159\u00e1dn\u011b fungovalo. Je to jako s instrukcemi pro leteckou bezpe\u010dnost. V\u0161echno je ps\u00e1no krv\u00ed. Ka\u017ed\u00e1 z t\u011bchto mati\u010dek byla objevena b\u011bhem n\u011bjak\u00e9ho probl\u00e9mu. S radost\u00ed se s v\u00e1mi o n\u011b pod\u011bl\u00edm.<\/p>\n
<\/p>\n
Ot\u00e1zky:<\/p>\n
<\/p>\n
D\u011bkuji! Pokud nap\u0159\u00edklad chce firma u\u0161et\u0159it a um\u00edstit datab\u00e1zi a aplika\u010dn\u00ed logiku na jeden server, nebo pokud firma n\u00e1sleduje modern\u00ed trend mikroservisn\u00edch architektur, kde PostgreSQL b\u011b\u017e\u00ed v kontejneru. Jak\u00fd je v tom h\u00e1\u010dek? Sysctl ovliv\u0148uje v\u0161echna j\u00e1dra glob\u00e1ln\u011b. Nesly\u0161el jsem, \u017ee by sysctl n\u011bjak virtualizovali, aby fungovaly v r\u016fzn\u00fdch kontejnerech. Existuj\u00ed pouze cgroup, a tam je kontrola jen na \u010d\u00e1st. Jak s t\u00edm m\u016f\u017eete \u017e\u00edt? Nebo pokud chcete v\u00fdkon, spus\u0165te PostgreSQL na samostatn\u00e9m fyzick\u00e9m serveru a optimalizujte ho?<\/em><\/p>\n<\/p>\n
Na va\u0161i ot\u00e1zku jsme odpov\u011bd\u011bli p\u0159ibli\u017en\u011b t\u0159emi zp\u016fsoby. Pokud se nejedn\u00e1 o fyzick\u00fd server, kter\u00fd m\u016f\u017eete optimalizovat atd., bu\u010fte klidn\u00ed, bez t\u011bchto nastaven\u00ed to bude fungovat dob\u0159e. Pokud m\u00e1te takovou z\u00e1t\u011b\u017e, \u017ee je t\u0159eba d\u011blat tato nastaven\u00ed, fyzick\u00fd server pot\u0159ebujete d\u0159\u00edve, ne\u017e se dostanete k t\u011bmto nastaven\u00edm.<\/p>\n
<\/p>\n
V \u010dem je probl\u00e9m? Pokud je to virtu\u00e1ln\u00ed stroj, pravd\u011bpodobn\u011b budete m\u00edt spoustu probl\u00e9m\u016f, nap\u0159\u00edklad s t\u00edm, \u017ee na v\u011bt\u0161in\u011b virtu\u00e1ln\u00edch stroj\u016f je latence disku dost nekonzistentn\u00ed. I kdy\u017e je propustnost disk\u016f dobr\u00e1, jedna selh\u00e1vaj\u00edc\u00ed transakce operace vstupu-v\u00fdstupu, kter\u00e1 nem\u00e1 velk\u00fd vliv na pr\u016fm\u011brnou propustnost, a kter\u00e1 nastala v okam\u017eiku checkpointu nebo p\u0159i z\u00e1pisu do WAL, zp\u016fsob\u00ed, \u017ee datab\u00e1ze utrp\u00ed. To si v\u0161imnete d\u0159\u00edve, ne\u017e naraz\u00edte na tyto probl\u00e9my. <\/p>\n
<\/p>\n
Pokud bude NGINX na stejn\u00e9m serveru, bude to m\u00edt stejn\u00fd probl\u00e9m. Bude se pr\u00e1t o sd\u00edlenou pam\u011b\u0165. A\u017e se dostanete k probl\u00e9m\u016fm, kter\u00e9 jsou zde pops\u00e1ny.<\/p>\n
<\/p>\n
Na druhou stranu, n\u011bkter\u00e9 z t\u011bchto parametr\u016f pro v\u00e1s budou st\u00e1le relevantn\u00ed. Nap\u0159\u00edklad, s nastaven\u00edm sysctl dirty_ratio, aby nebylo a\u017e tak \u0161\u00edlen\u00e9 \u2013 v ka\u017ed\u00e9m p\u0159\u00edpad\u011b to pom\u016f\u017ee. Tak \u010di onak, dojde k interakci s diskem. A ta bude fungovat podle nespr\u00e1vn\u00e9ho sch\u00e9matu. To jsou ve skute\u010dnosti v\u00fdchoz\u00ed parametry, kter\u00e9 jsem ukazoval. A v ka\u017ed\u00e9m p\u0159\u00edpad\u011b je lep\u0161\u00ed je zm\u011bnit. <\/p>\n
<\/p>\n
S NUMA mohou b\u00fdt probl\u00e9my. Nap\u0159\u00edklad VmWare dob\u0159e funguje s NUMA s \u00fapln\u011b opa\u010dn\u00fdmi nastaven\u00edmi. A tady je t\u0159eba si vybrat \u2013 fyzick\u00fd server nebo nefyzi\u010dk\u00fd. <\/p>\n
<\/p>\n
M\u00e1m ot\u00e1zku ohledn\u011b Amazon AWS. Maj\u00ed p\u0159ednastaven\u00e9 image. Jedn\u00edm z nich se naz\u00fdv\u00e1 Amazon RDS. Maj\u00ed tam n\u011bjak\u00e9 vlastn\u00ed nastaven\u00ed pro jejich opera\u010dn\u00ed syst\u00e9m?<\/em><\/p>\n<\/p>\n
Jsou tam nastaven\u00ed, ale to jsou jin\u00e1 nastaven\u00ed. Tady nastavujeme opera\u010dn\u00ed syst\u00e9m z pohledu toho, jak datab\u00e1ze tohle pou\u017eije. A tam jsou parametry, kter\u00e9 ur\u010duj\u00ed, kam te\u010f j\u00edt, jak\u00fd shaping. Tedy pot\u0159ebujeme tolik zdroj\u016f, kter\u00e9 te\u010f pot\u0159ebujeme \u010derpat. Po tom Amazon RDS tyto zdroje p\u0159ipojuje, a tam v\u00fdkon kles\u00e1. Existuj\u00ed samostatn\u00e9 p\u0159\u00edb\u011bhy, jak lid\u00e9 s t\u00edm za\u010dnou experimentovat. N\u011bkdy i docela \u00fasp\u011b\u0161n\u011b. Ale to nem\u00e1 nic spole\u010dn\u00e9ho s nastaven\u00edm OS. To je vlastn\u011b hacking cloudu. To je jin\u00fd p\u0159\u00edb\u011bh.<\/p>\n
<\/p>\n
Pro\u010d Transparent huge pages ned\u00e1vaj\u00ed efekt v porovn\u00e1n\u00ed s Huge TLB?<\/em><\/p>\n<\/p>\n
Ned\u00e1vaj\u00ed. To lze vysv\u011btlit mnoha zp\u016fsoby. Ale fakticky prost\u011b ned\u00e1vaj\u00ed. Jak\u00e1 je historie PostgreSQL? P\u0159i spu\u0161t\u011bn\u00ed vy\u010dle\u0148uje velk\u00fd kus sd\u00edlen\u00e9 pam\u011bti. Transparentn\u00ed nebo ne transparentn\u00ed \u2013 naprosto nez\u00e1le\u017e\u00ed. Skute\u010dnost, \u017ee se vy\u010dle\u0148uj\u00ed p\u0159i spu\u0161t\u011bn\u00ed, to v\u0161echno vysv\u011btluje. A pokud je pam\u011bti velmi mnoho a je nutn\u00e9 p\u0159eorganizovat segment shared_memory, pak bude Transparent huge pages relevantn\u00ed. U PostgreSQL je to prost\u011b na za\u010d\u00e1tku vy\u010dlen\u011bno obrovsk\u00fdm kusem a nic zvl\u00e1\u0161tn\u00edho se d\u00e1l ned\u011bje. Samoz\u0159ejm\u011b jej lze pou\u017e\u00edt, ale existuje riziko po\u0161kozen\u00ed shared_memory, kdy se pokus\u00ed p\u0159eallocovat n\u011bco. PostgreSQL o tom p\u0159ece nev\u00ed.<\/p>\n
Zdroj: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2015 \u0433\u043e\u0434\u0430 \u0418\u043b\u044c\u0438 \u041a\u043e\u0441\u043c\u043e\u0434\u0435\u043c\u044c\u044f\u043d\u0441\u043a\u043e\u0433\u043e "Linux tuning to improve PostgreSQL performance" Disclaimer: \u0417\u0430\u043c\u0435\u0447\u0443 \u0447\u0442\u043e \u0434\u043e\u043a\u043b\u0430\u0434 \u044d\u0442\u043e\u0442 \u0434\u0430\u0442\u0438\u0440\u043e\u0432\u0430\u043d \u043d\u043e\u044f\u0431\u0440\u0435\u043c 2015 \u0433\u043e\u0434\u0430 \u2014 \u043f\u0440\u043e\u0448\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u0435 4 \u043b\u0435\u0442 \u0438 \u043f\u0440\u043e\u0448\u043b\u043e \u043c\u043d\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u043c\u0430\u044f \u0432 \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0432\u0435\u0440\u0441\u0438\u044f 9.4 \u0443\u0436\u0435 \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 4 \u0433\u043e\u0434\u0430 \u0432\u044b\u0448\u043b\u043e 5 \u043d\u043e\u0432\u044b\u0445 \u0440\u0435\u043b\u0438\u0437\u043e\u0432 PostgreSQL \u0432\u044b\u0448\u043b\u043e \u0438 15 \u0432\u0435\u0440\u0441\u0438\u0439 \u044f\u0434\u0440\u0430 Linux. \u0415\u0441\u043b\u0438 \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84083,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Lad\u011bn\u00ed](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n