Astfel, abordarea corect\u0103 este s\u0103 dezactiv\u0103m complet NUMA.<\/strong>, de exemplu, la repornire. \u00cen majoritatea cazurilor, c\u00e2\u0219tigurile sunt at\u00e2t de mari, \u00eenc\u00e2t nu mai exist\u0103 nicio \u00eentrebare despre ce este mai bine. <\/p>\n<\/p>\n
Exist\u0103 o alt\u0103 variant\u0103. O folosim mai des dec\u00e2t pe prima, deoarece, atunci c\u00e2nd avem un client care are nevoie de suport, pentru el repornirea serverului este un \u00eentreg proces. Are acolo o afacere \u00een desf\u0103\u0219urare. \u0218i ei au probleme din cauza NUMA. Prin urmare, \u00eencerc\u0103m s\u0103 dezactiv\u0103m \u00eentr-un mod mai pu\u021bin invaziv dec\u00e2t prin reboot, dar aici trebuie s\u0103 verifica\u021bi cu aten\u021bie c\u0103 aceasta s-a dezactivat. Pentru c\u0103, a\u0219a cum arat\u0103 experien\u021ba, dac\u0103 dezactiv\u0103m NUMA pentru procesul p\u0103rinte PostgreSQL, este bine, dar nu este deloc obligatoriu c\u0103 aceasta va func\u021biona. Trebuie s\u0103 verifici \u0219i s\u0103 te asiguri c\u0103 s-a dezactivat cu adev\u0103rat. <\/p>\n
<\/p>\n
Exist\u0103 un articol interesant de Robert Haas. Este unul dintre commiters PostgreSQL. Unul dintre dezvoltatorii cheie ai tuturor aspectelor de baz\u0103. Dac\u0103 trece\u021bi prin linkurile din acest articol, ve\u021bi g\u0103si c\u00e2teva pove\u0219ti interesante despre cum NUMA le-a complicat via\u021ba oamenilor. Vede\u021bi, studia\u021bi lista de verificare pentru adminii de sistem, ce trebuie configurat pe server pentru a ne asigura c\u0103 baza de date func\u021bioneaz\u0103 bine. Aceste set\u0103ri trebuie notate \u0219i verificate, altfel va fi destul de nepl\u0103cut. <\/p>\n
<\/p>\n
Atrag aten\u021bia c\u0103 acest lucru se refer\u0103 la toate set\u0103rile despre care voi vorbi. Dar, de obicei, bazele de date sunt configurate \u00een mod master-slave pentru redundan\u021b\u0103. Nu uita\u021bi s\u0103 face\u021bi aceste set\u0103ri \u0219i pe slave, deoarece la un moment dat s-ar putea s\u0103 ave\u021bi o avarie \u0219i ve\u021bi comuta pe slave, iar acesta va deveni master. <\/p>\n
<\/p>\n
\u00centr-o situa\u021bie de urgen\u021b\u0103, c\u00e2nd totul este foarte r\u0103u, telefonul v\u0103 sun\u0103 constant \u0219i \u0219eful vine cu un baston mare, nu ve\u021bi avea timp s\u0103 v\u0103 g\u00e2ndi\u021bi s\u0103 verifica\u021bi. \u0218i rezultatele pot fi destul de dezastroase.<\/p>\n
<\/p>\n
<\/p>\n
Urm\u0103torul aspect este huge pages. Huge pages sunt dificile de testat separat \u0219i nu are sens s\u0103 o face\u021bi, de\u0219i exist\u0103 benchmark-uri care pot face acest lucru. Ele sunt u\u0219or de g\u0103sit pe internet. <\/p>\n
<\/p>\n
Care este ideea? Ave\u021bi un server relativ ieftin, cu mult\u0103 memorie RAM, de exemplu, mai mult de 30 GB. Nu folosi\u021bi huge pages. Asta \u00eenseamn\u0103 c\u0103 exist\u0103 cu siguran\u021b\u0103 overhead \u00een utilizarea memoriei. Iar acest overhead nu este deloc pl\u0103cut. <\/p>\n
<\/p>\n
<\/p>\n
De ce se \u00eent\u00e2mpl\u0103 asta? Ce se petrece? Sistemul de operare aloc\u0103 memorie \u00een buc\u0103\u021bi mici. Asa este convenabil, a\u0219a a fost istoric. \u0218i dac\u0103 detaliem, OS-ul trebuie s\u0103 transleze adresele virtuale \u00een cele fizice. \u0218i acest proces nu este cel mai simplu, de aceea OS-ul stocheaz\u0103 rezultatul acestei opera\u021bii \u00een Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
\u0218i deoarece TLB-ul este un cache, \u00een astfel de situa\u021bii apar toate problemele specifice cache-ului. \u00cen primul r\u00e2nd, dac\u0103 ave\u021bi foarte mult\u0103 memorie RAM \u0219i aceasta este alocat\u0103 \u00een buc\u0103\u021bi mici, bufferul devine foarte mare. Iar dac\u0103 cache-ul este mare, c\u0103utarea devine mai lent\u0103. Overhead-ul este considerabil \u0219i acesta \u00een sine ocup\u0103 spa\u021biu, adic\u0103 memoria RAM este consumat\u0103 de ceva nepotrivit. Asta e una. <\/p>\n
<\/p>\n
Dou\u0103 \u2013 cu c\u00e2t cache-ul se extinde mai mult \u00een aceast\u0103 situa\u021bie, cu at\u00e2t este mai mare \u0219ansa s\u0103 ave\u021bi cache misses. Eficien\u021ba acestui cache scade rapid pe m\u0103sur\u0103 ce dimensiunea sa cre\u0219te. De aceea, \u00een sistemele de operare a fost adoptat\u0103 o abordare simpl\u0103. \u00cen Linux, aceasta este utilizat\u0103 de mult timp. \u00cen FreeBSD a ap\u0103rut nu de mult. Dar vorbim despre Linux. Acestea sunt huge pages.<\/p>\n
<\/p>\n
Trebuie men\u021bionat c\u0103 huge pages, ca idee, a fost ini\u021bial sus\u021binut\u0103 de comunit\u0103\u021bi care includeau Oracle \u0219i IBM, adic\u0103 produc\u0103torii de baze de date s-au g\u00e2ndit serios c\u0103 va fi util\u0103 \u0219i pentru baze de date. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i cum s\u0103 le integr\u0103m cu PostgreSQL? \u00cen primul r\u00e2nd, \u00een kernel-ul Linux trebuie s\u0103 fie activate huge pages.<\/p>\n
<\/p>\n
\u00cen al doilea r\u00e2nd, acestea trebuie specificate explicit printr-un parametru sysctl \u2013 c\u00e2te sunt. Numerele aici provin de la un server mai vechi. Pute\u021bi calcula c\u00e2te shared buffers ave\u021bi aproximativ, astfel \u00eenc\u00e2t huge pages s\u0103 \u00eencap\u0103 acolo. <\/p>\n
<\/p>\n
Dac\u0103 \u00eentregul server este dedicat PostgreSQL, o bun\u0103 punct de plecare este fie s\u0103 aloca\u021bi 25 % din memoria RAM pentru shared buffers, fie 75 %, dac\u0103 sunte\u021bi sigur c\u0103 baza de date se va \u00eencadra \u00een aceste 75 %. Aceasta este prima punct de plecare. \u0218i calcula\u021bi, dac\u0103 ave\u021bi 256 GB de memorie RAM, atunci, conform calculului, ve\u021bi avea 64 GB pentru shared buffers. Face\u021bi calculul aproximativ cu un mic surplus \u2013 c\u00e2t ar trebui s\u0103 aib\u0103 aceast\u0103 cifr\u0103.<\/p>\n
<\/p>\n
P\u00e2n\u0103 la versiunea 9.2 (dac\u0103 nu m\u0103 \u00een\u0219el, de la versiunea 8.2) era posibil s\u0103 integra\u021bi PostgreSQL cu huge pages printr-o bibliotec\u0103 extern\u0103. Aceasta este \u00eentotdeauna necesar. \u00cen primul r\u00e2nd, ave\u021bi nevoie ca nucleul s\u0103 poat\u0103 aloca corect huge pages. \u00cen al doilea r\u00e2nd, aplica\u021bia care lucreaz\u0103 cu acestea trebuie s\u0103 fie capabil\u0103 s\u0103 le utilizeze. Pur \u0219i simplu nu le va utiliza. Deoarece PostgreSQL aloca memorie \u00een stilul system 5, acest lucru se putea face prin libhugetlbfs \u2013 acesta este numele complet al bibliotecii.<\/p>\n
<\/p>\n
\u00cen versiunea 9.3, a fost \u00eembun\u0103t\u0103\u021bit\u0103 performan\u021ba PostgreSQL \u00een ceea ce prive\u0219te gestionarea memoriei \u0219i s-a renun\u021bat la metoda de alocare a memoriei system 5. Toat\u0103 lumea a fost foarte \u00eenc\u00e2ntat\u0103, deoarece altfel, atunci c\u00e2nd \u00eencerci s\u0103 rulezi dou\u0103 instan\u021be PostgreSQL pe o ma\u0219in\u0103, prime\u0219ti mesajul c\u0103 nu ai suficient\u0103 memorie partajat\u0103. \u00ce\u021bi spune c\u0103 trebuie s\u0103 ajustezi sysctl. \u0218i acel sysctl este at\u00e2t de complicat \u00eenc\u00e2t trebuie s\u0103 te reinventezi \u0219i a\u0219a mai departe. \u00cen general, toat\u0103 lumea a fost bucuroas\u0103. Dar alocarea memoriei prin mmap a afectat utilizarea huge pages. Majoritatea clien\u021bilor no\u0219tri folosesc buffer-uri partajate mari. \u0218i am recomandat insistent s\u0103 nu se treac\u0103 la 9.3, deoarece overhead-ul \u00eencepea s\u0103 conteze serios \u00een procente.<\/p>\n
<\/p>\n
\u00cens\u0103, comunitatea a observat aceast\u0103 problem\u0103 \u0219i \u00een versiunea 9.4 au reg\u00e2ndit foarte bine acest aspect. \u00cen 9.4 a ap\u0103rut un parametru \u00een postgresql.conf, care permite activarea op\u021biunii try, on sau off.<\/p>\n
<\/p>\n
Try \u2013 este cel mai sigur parametru. La pornirea PostgreSQL, c\u00e2nd acesta aloc\u0103 memorie partajat\u0103, \u00eencearc\u0103 s\u0103 ob\u021bin\u0103 acea memorie din huge pages. \u0218i dac\u0103 nu reu\u0219e\u0219te, revine la alocarea obi\u0219nuit\u0103. Dac\u0103 utiliza\u021bi FreeBSD sau Solaris, pute\u021bi seta try, este \u00eentotdeauna sigur. <\/p>\n
<\/p>\n
Dac\u0103 este on, nu va porni pur \u0219i simplu, dac\u0103 nu a reu\u0219it s\u0103 aloce din huge pages. Aici depinde doar de preferin\u021bele fiec\u0103ruia. Dar dac\u0103 a\u021bi ales try, verifica\u021bi c\u0103 a\u021bi ob\u021binut cu adev\u0103rat ceea ce trebuie alocat, deoarece sunt multe spa\u021bii pentru gre\u0219eli. Acest func\u021bionalitate func\u021bioneaz\u0103 doar pe Linux.<\/p>\n
<\/p>\n
\u00cenc\u0103 o mic\u0103 observa\u021bie, \u00eenainte de a merge mai departe. Transparent huge pages \u2013 nu se refer\u0103, deocamdat\u0103, la PostgreSQL. Acesta nu poate beneficia de ele \u00een mod corespunz\u0103tor. \u0218i \u00een cazul Transparent huge pages, pentru un astfel de workload, c\u00e2nd este necesar\u0103 o por\u021biune mare de memorie partajat\u0103, avantajele apar doar la volume foarte mari. Dac\u0103 ave\u021bi terabytes de memorie, atunci acest lucru ar putea fi relevant. Dac\u0103 discut\u0103m despre utiliz\u0103ri mai obi\u0219nuite, c\u00e2nd ave\u021bi 32, 64, 128, 256 GB de memorie pe ma\u0219in\u0103, atunci huge pages obi\u0219nuite sunt acceptabile, iar Transparent trebuie pur \u0219i simplu dezactivat. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i ultimul lucru, legat de memorie, care nu este direct asociat cu throughput-ul, poate afecta foarte mult experien\u021ba. \u00centreaga capacitate de procesare va fi foarte afectat\u0103 de faptul c\u0103 serverul constant swap-uie\u0219te. <\/p>\n
<\/p>\n
\u0218i asta va fi foarte nepl\u0103cut \u00een mai multe momente. Principalul neajuns const\u0103 \u00een faptul c\u0103, \u00een nucleele moderne, comportamentul difer\u0103 pu\u021bin de cel al nuclelor Linux mai vechi. Acesta este un aspect pe care este destul de nepl\u0103cut s\u0103-l \u00eent\u00e2mpini, pentru c\u0103, atunci c\u00e2nd vorbim despre o anumit\u0103 lucrare cu swap-ul, se \u00eencheie cu sosirea tardiv\u0103 a OOM-killer-ului. Iar OOM-killer-ul care a sosit tardiv \u0219i a eliminat PostgreSQL este o nepl\u0103cere. Toat\u0103 lumea va afla despre asta, adic\u0103 p\u00e2n\u0103 la ultimul utilizator. <\/p>\n
<\/p>\n
<\/p>\n
Ce se \u00eent\u00e2mpl\u0103? Ave\u021bi acolo o cantitate mare de memorie RAM, totul func\u021bioneaz\u0103 bine. Dar de ce serverul se blocheaz\u0103 \u00een swap \u0219i se \u00eencetine\u0219te din aceast\u0103 cauz\u0103? P\u0103rea c\u0103 este mult\u0103 memorie, dar se \u00eent\u00e2mpl\u0103 a\u0219a. <\/p>\n
<\/p>\n
<\/p>\n
\u00cen trecut, sf\u0103tuiam s\u0103 set\u0103m vm.swappiness la zero, adic\u0103 s\u0103 dezactiv\u0103m swap-ul. Se p\u0103rea c\u0103 32 GB de memorie RAM \u0219i buffer-ele partajate corespunz\u0103toare reprezint\u0103 o cantitate imens\u0103. Principalul scop al swap-ului era s\u0103 existe un loc unde s\u0103 arunc\u0103m un snapshot, \u00een cazul \u00een care ne deconect\u0103m. Acesta nu \u00ee\u0219i mai \u00eendeplinea cu adev\u0103rat rolul. \u0218i ce vei face ulterior cu acel snapshot? Aceasta devine o problem\u0103, c\u00e2nd nu este clar de ce este necesar swap-ul, mai ales de o asemenea dimensiune. <\/p>\n
<\/p>\n
Dar \u00een nucleele moderne, adic\u0103 \u00een versiunile a treia, comportamentul s-a schimbat. \u0218i dac\u0103 setezi swap-ul la zero, adic\u0103 \u00eel dezactivezi, mai devreme sau mai t\u00e2rziu, chiar \u0219i cu o cantitate de memorie RAM disponibil\u0103, OOM-killer-ul va veni s\u0103 ucid\u0103 cei mai mari consumatori. Pentru c\u0103 el va considera c\u0103, av\u00e2nd un astfel de volum de lucru, ne-a mai r\u0103mas pu\u021bin \u0219i vom ie\u0219i, adic\u0103 nu va ucide un proces sistemic, ci va elimina ceva mai pu\u021bin important. Acest lucru mai pu\u021bin important va fi un consumator intens de memorie partajat\u0103, adic\u0103 postmaster-ul. \u0218i dup\u0103 aceea, va fi bine dac\u0103 nu va trebui s\u0103 restaurezi baza de date. <\/p>\n
<\/p>\n
Prin urmare, acum, conform informa\u021biilor pe care le am, majoritatea distribu\u021biilor setez\u0103 \u00een mod implicit cam 6, adic\u0103 \u00een ce moment \u00eencepe utilizarea swap-ului \u00een func\u021bie de cantitatea de memorie r\u0103mas\u0103. Acum recomand\u0103m s\u0103 set\u0103m vm.swappiness = 1, deoarece acest lucru practic \u00eel dezactiveaz\u0103, dar nu produce efectele pe care le cauzeaz\u0103 sosirea nea\u0219teptat\u0103 a OOM-killer-ului \u0219i tot acest proces de eliminare.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Ce urmeaz\u0103? Atunci c\u00e2nd discut\u0103m despre performan\u021ba bazelor de date \u0219i ne apropiem treptat de discuri, toat\u0103 lumea \u00eencepe s\u0103 se panicheze. Pentru c\u0103 adev\u0103rul c\u0103 discul este lent \u0219i memoria rapid\u0103 este bine cunoscut de to\u021bi. \u0218i toat\u0103 lumea \u0219tie c\u0103 \u00een baza de date vor ap\u0103rea probleme cu performan\u021ba discului.<\/p>\n
<\/p>\n
Problema principal\u0103 cu performan\u021ba PostgreSQL, legat\u0103 de v\u00e2rfurile checkpoint-urilor, nu apare din cauza faptului c\u0103 discul este lent. Este mai degrab\u0103 pentru c\u0103 l\u0103\u021bimea de band\u0103 a memoriei \u0219i discului nu sunt echilibrate. Acestea pot fi dezechilibrate \u00een diferite loca\u021bii. PostgreSQL nu este configurat corect, sistemul de operare nu este configurat, hardware-ul nu este configurat \u0219i hardware-ul este gre\u0219it. Aceast\u0103 problem\u0103 nu apare doar dac\u0103 totul se desf\u0103\u0219oar\u0103 conform planului, adic\u0103 fie nu exist\u0103 \u00eenc\u0103rcare, fie configur\u0103rile \u0219i hardware-ul sunt bine corelate. <\/p>\n
<\/p>\n
<\/p>\n
Ce este asta \u0219i cum arat\u0103? De obicei, persoanele care lucreaz\u0103 cu PostgreSQL s-au implicat \u00een acest proces de mai multe ori. Voi explica. A\u0219a cum am spus, PostgreSQL face periodic checkpoint-uri pentru a salva paginile murdare din memoria partajat\u0103 pe disc. Dac\u0103 avem un volum mare de memorie partajat\u0103, atunci checkpoint-ul \u00eencepe s\u0103 afecteze intens discul, deoarece salveaz\u0103 aceste pagini cu fsync. Acesta ajunge \u00een buffer-ul kernel \u0219i este scris pe discuri cu ajutorul fsync. \u0218i dac\u0103 volumul acestui proces este mare, putem observa un efect nepl\u0103cut, \u0219i anume o utilizare foarte mare a discurilor.<\/p>\n
<\/p>\n
Aici am dou\u0103 imagini. Voi explica acum ce este. Acestea sunt dou\u0103 grafice corelate \u00een timp. Primul grafic \u2013 este utilizarea discului. Aici atinge aproape 90% \u00een acest moment. Dac\u0103 ave\u021bi o baz\u0103 de date cu discuri fizice \u0219i cu un controler RAID, utilizarea aproape de 90% este o veste proast\u0103. \u00censeamn\u0103 c\u0103 \u00eenc\u0103 pu\u021bin \u0219i va ajunge la 100, iar intrarea-ie\u0219irea se va opri. <\/p>\n
<\/p>\n
Dac\u0103 ave\u021bi un array de discuri, atunci este o alt\u0103 poveste. Asta depinde de modul \u00een care este configurat, ce tip de array \u0219i a\u0219a mai departe. <\/p>\n
<\/p>\n
\u00cen paralel, aici este configurat un grafic dintr-o vedere intern\u0103 Postgres care arat\u0103 cum decurge checkpoint-ul. \u0218i cu verde este marcat num\u0103rul de buffere, adic\u0103 paginile murdare care \u00een acest moment au fost trimise \u00een acest checkpoint pentru sincronizare. Acesta este aspectul principal pe care trebuie s\u0103-l \u0219tim. Vedem c\u0103 aici avem multe pagini venind \u0219i, \u00eentr-un anumit moment, ne-am lovit de limit\u0103, adic\u0103 am scris continuu, iar sistemul de disc este evident foarte ocupat. \u0218i checkpoint-ul nostru influen\u021beaz\u0103 semnificativ discul. Ideal, situa\u021bia ar trebui s\u0103 arate mai degrab\u0103 a\u0219a, adic\u0103 ar trebui s\u0103 fie mai pu\u021bin\u0103 scriere. \u0218i putem ajusta set\u0103rile pentru a face ca situa\u021bia s\u0103 r\u0103m\u00e2n\u0103 astfel. Adic\u0103, utilizarea este mic\u0103, dar totu\u0219i scriem ceva aici. <\/p>\n
<\/p>\n
Ce trebuie s\u0103 facem pentru a dep\u0103\u0219i aceast\u0103 problem\u0103? Dac\u0103 I\/O-ul pentru baza de date s-a oprit, asta \u00eenseamn\u0103 c\u0103 to\u021bi utilizatorii care au venit s\u0103 execute cererile lor vor fi \u00een a\u0219teptare. <\/p>\n
<\/p>\n
<\/p>\n
Dac\u0103 ne uit\u0103m din perspectiva Linux-ului, dac\u0103 ai un hardware bun, l-ai configurat corect \u0219i ai configurat PostgreSQL astfel \u00eenc\u00e2t s\u0103 efectueze aceste checkpoint-uri mai rar, dispun\u00e2ndu-le \u00een timp, ajungi la parametrii impliciti ai Debian-ului. Pentru majoritatea distribu\u021biilor Linux, situa\u021bia este urm\u0103toarea: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Ce \u00eenseamn\u0103 asta? Cu kernel-ul 2.6 a ap\u0103rut un demon de flushing. Pgflush, \u00een func\u021bie de cine-l folose\u0219te, se ocup\u0103 cu desc\u0103rcarea paginilor murdare din buffer-ul kernel \u00een fundal \u0219i desc\u0103rcarea acestora c\u00e2nd este necesar, chiar \u0219i atunci c\u00e2nd desc\u0103rcarea \u00een fundal nu ajut\u0103. <\/p>\n
<\/p>\n
C\u00e2nd apare fundalul? C\u00e2nd 10% din \u00eentreaga memorie RAM de pe server este ocupat\u0103 de paginile murdare din buffer-ul kernel, este apelat\u0103 o func\u021bie special\u0103 pentru desc\u0103rcarea \u00een fundal. De ce este aceasta fundal? Ea prime\u0219te ca parametru c\u00e2te pagini s\u0103 descarce. De exemplu, descarc\u0103 N pagini. \u0218i pentru o vreme, acest proces intr\u0103 \u00een starea de odihn\u0103. Apoi, revine \u0219i descarc\u0103 un alt num\u0103r de pagini. <\/p>\n
<\/p>\n
Este o poveste extrem de simpl\u0103. Aici este o problem\u0103 similar\u0103 cu un bazin, c\u00e2nd \u00eentr-un \u021beav\u0103 se toarn\u0103 ap\u0103, \u00een cealalt\u0103 se umple. Aici a venit checkpoint-ul \u0219i, dac\u0103 nu a trimis suficiente pagini murdare la desc\u0103rcare, acestea vor fi absorbite treptat din buffer-ul kernel de pgflush. <\/p>\n
<\/p>\n
Dac\u0103 aceste pagini murdare continu\u0103 s\u0103 acumulese, acestea ajung la 20%, dup\u0103 care sistemul de operare prioritizeaz\u0103 s\u0103 scrie toate acestea pe disc, deoarece dac\u0103 alimentarea pic\u0103, vom avea probleme. Vom pierde aceste date, de exemplu. <\/p>\n
<\/p>\n
Care este trucul? Trucul const\u0103 \u00een faptul c\u0103 ace\u0219ti parametri, \u00een lumea modern\u0103, sunt 20% \u0219i 10% din toat\u0103 memoria RAM disponibil\u0103 pe ma\u0219in\u0103, sunt complet inacceptabili din punctul de vedere al l\u0103\u021bimii de band\u0103 a oric\u0103rei sisteme de disc pe care o ave\u021bi.<\/strong> <\/p>\n<\/p>\n
Imagina\u021bi-v\u0103 c\u0103 ave\u021bi 128 GB de memorie RAM. 12,8 GB ajung \u00een sistemul dumneavoastr\u0103 de discuri. Indiferent de cache-ul pe care \u00eel ave\u021bi acolo, indiferent de matricea pe care o ave\u021bi, acestea nu vor putea face fa\u021b\u0103. <\/p>\n
<\/p>\n
<\/p>\n
De aceea, recomand\u0103m s\u0103 ajusta\u021bi aceste cifre \u00een func\u021bie de capacit\u0103\u021bile controller-ului dumneavoastr\u0103 RAID.<\/strong> Am aici o recomandare pentru un controller cu 512 MB de cache. <\/p>\n<\/p>\n
Se calculeaz\u0103 foarte simplu. Pute\u021bi seta vm.dirty_background \u00een bytes. Aceste set\u0103ri anuleaz\u0103 precedentele dou\u0103. Fie raportul implicit, fie cele activate \u00een bytes vor func\u021biona cele \u00een bytes. Dar, deoarece sunt consultant DBA \u0219i lucrez cu diferi\u021bi clien\u021bi, \u00eencerc s\u0103 m\u0103 protejez \u0219i, prin urmare, dac\u0103 este \u00een bytes, atunci \u00een bytes. Nimeni nu a dat nicio garan\u021bie c\u0103 un administrator binevoitor nu va ad\u0103uga memorie serverului, nu \u00eel va reporni, iar cifra va r\u0103m\u00e2ne aceea\u0219i. Calcula\u021bi aceste cifre astfel \u00eenc\u00e2t s\u0103 fie garantat c\u0103 totul se \u00eencadreaz\u0103. <\/p>\n
<\/p>\n
Ce se va \u00eent\u00e2mpla dac\u0103 nu reu\u0219i\u021bi s\u0103 v\u0103 \u00eencadra\u021bi? Am scris c\u0103 orice flushing se opre\u0219te eficient, dar de fapt este o figur\u0103 de stil. Sistemul de operare are o problem\u0103 major\u0103 - are multe pagini murdare, a\u0219a c\u0103 efectiv se opre\u0219te IO, care este generat de clien\u021bii dumneavoastr\u0103, adic\u0103 aplica\u021bia sql trimite cererea c\u0103tre baza de date, a\u0219teapt\u0103. Orice input-output c\u0103tre aceasta este la cele mai joase priorit\u0103\u021bi, deoarece baza de date este ocupat\u0103 cu checkpoint-ul. \u0218i c\u00e2nd va termina acest lucru nu este deloc clar. \u0218i c\u00e2nd atinge\u021bi flushing-ul non-fond, non-background, atunci asta \u00eenseamn\u0103 c\u0103 tot IO-ul este ocupat de el. \u0218i p\u00e2n\u0103 nu se termin\u0103, nu ve\u021bi putea face nimic. <\/p>\n
<\/p>\n
Aici sunt \u00eenc\u0103 dou\u0103 puncte importante care dep\u0103\u0219esc acest raport. Aceste set\u0103ri ar trebui s\u0103 se potriveasc\u0103 cu set\u0103rile din postgresql.conf, adic\u0103 set\u0103rile pentru checkpoints. \u0218i sistemul dumneavoastr\u0103 de discuri trebuie s\u0103 fie configurat corespunz\u0103tor. Dac\u0103 ave\u021bi un cache pe RAID, acesta ar trebui s\u0103 aib\u0103 o baterie.<\/strong> Oamenii cump\u0103r\u0103 RAID-uri cu cache bun f\u0103r\u0103 baterie. Dac\u0103 ave\u021bi SSD \u00een RAID, acestea ar trebui s\u0103 fie server-based, \u0219i ar trebui s\u0103 aib\u0103 condensatoare.<\/strong> Aici este o list\u0103 detaliat\u0103 de verficare. La acest link este raportul meu despre cum s\u0103 configura\u021bi performan\u021ba discului \u00een PostgreSQL. Toate aceste liste de verificare sunt acolo. <\/p>\n<\/p>\n
<\/p>\n
Ce ar putea complica foarte mult via\u021ba? Acestea sunt dou\u0103 parametrii. Sunt relativ noi. Pot fi activate \u00een mod implicit \u00een diferite aplica\u021bii. \u0218i pot complica via\u021ba la fel de mult, dac\u0103 sunt activate gre\u0219it. <\/p>\n
<\/p>\n
<\/p>\n
Exist\u0103 dou\u0103 lucruri relativ noi. Au ap\u0103rut deja \u00een nucleele a treia. Acestea sunt sched_migration_cost \u00een nanosecunde \u0219i sched_autogroup_enabled, care este activat implicit. <\/p>\n
<\/p>\n
\u0218i cum le stric\u0103 via\u021ba? Ce este sched_migration_cost? Scheduler-ul Linux poate migra un proces de pe un CPU pe altul. \u0218i pentru PostgreSQL, care execut\u0103 interog\u0103ri, migrarea pe un alt CPU nu este deloc clar de ce ar fi necesar\u0103. Din punct de vedere al sistemului de operare, c\u00e2nd schimba\u021bi feronre\u021bele \u00eentre openoffice \u0219i terminal, poate fi bine, dar pentru baza de date - este foarte r\u0103u.<\/strong> Prin urmare, o politic\u0103 ra\u021bional\u0103 este s\u0103 seta\u021bi migration_cost la o valoare mare, cel pu\u021bin c\u00e2teva mii de nanosecunde.<\/strong> <\/p>\n<\/p>\n
Ce ar \u00eensemna asta pentru scheduler? Va considera c\u0103, pe durata acestui timp, acest proces este \u00eenc\u0103 activ. Adic\u0103, dac\u0103 ave\u021bi o tranzac\u021bie lung\u0103 care se ocup\u0103 de ceva, scheduler-ul va \u00een\u021belege asta. Va considera c\u0103 p\u00e2n\u0103 nu trece acea perioad\u0103 de timeout, nu este necesar s\u0103 migreze acel proces. Dac\u0103 \u00een acela\u0219i timp procesul face ceva, nu va fi migrarea, va continua lini\u0219tit pe CPU-ul care i-a fost alocat. Iar rezultatul este excelent. <\/p>\n
<\/p>\n
Al doilea punct - este autogroup. Exist\u0103 o idee bun\u0103 pentru workload-uri specifice, care nu au leg\u0103tur\u0103 cu baza de date modern\u0103 - aceea de a grupa procesele \u00een func\u021bie de terminalul virtual de unde au fost lansate. Este convenabil pentru anumite sarcini. \u00cen practic\u0103, PostgreSQL este un sistem multi-proces cu prefork, care porne\u0219te dintr-un terminal. Ave\u021bi un lock writer, checkpoint \u0219i toate cererile clien\u021bilor se vor grupa pe un singur scheduler, pe un singur CPU. Acolo vor a\u0219tepta prietene\u0219te, c\u00e2nd acesta se va elibera, pentru a se perturb\u0103 reciproc \u0219i a-l ocupa mai mult. Aceasta este o situa\u021bie complet inutil\u0103 \u00een cazul unei astfel de \u00eenc\u0103rc\u0103ri \u0219i de aceea trebuie dezactivat\u0103.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Colegul meu Alexey Lesovski a efectuat teste cu un simplu pgbench, unde a crescut cu un ordin migration_cost \u0219i a dezactivat autogroup. Diferen\u021ba pe un hardware slab a reie\u0219it aproape 10 %<\/strong>. Exist\u0103 o discu\u021bie \u00een mailing listul postgres, unde oamenii ofer\u0103 rezultate despre cum astfel de modific\u0103ri au influen\u021bat viteza interog\u0103rii cu 50 %<\/strong>. Aceste pove\u0219ti sunt destul de multe.<\/p>\n<\/p>\n
<\/p>\n
\u0218i \u00een cele din urm\u0103 despre politica de economisire a energiei. E bine c\u0103 acum Linux poate fi folosit pe laptopuri. \u0218i va consuma, chipurile, bine bateria. Dar se dovede\u0219te c\u0103 acest lucru poate fi adev\u0103rat \u0219i pentru servere. <\/p>\n
<\/p>\n
Mai mult, dac\u0103 \u00eenchiria\u021bi servere de la un anumit hoster, atunci \u201ebuni\u201d hosting,<\/a> nu se ocup\u0103 de faptul c\u0103 ave\u021bi o performan\u021b\u0103 mai bun\u0103. Sarcina lor este s\u0103 se asigure c\u0103 hardware-ul lor este utilizat c\u00e2t mai eficient. De aceea, ei pot activa din start modul de economisire a energiei \u00een sistemul de operare.<\/p>\n<\/p>\n
Dac\u0103 utiliza\u021bi pe un server cu o baz\u0103 de date sub o \u00eenc\u0103rcare intensiv\u0103 acest lucru, alegerea dumneavoastr\u0103 este acpi_cpufreq + performance. Chiar \u0219i cu ondemand vor ap\u0103rea deja probleme.<\/strong> <\/p>\n<\/p>\n
Intel_pstate este deja un driver ceva mai diferit. \u0218i acum se prefer\u0103 acest driver, considerat mai recent \u0219i mai eficient.<\/p>\n
<\/p>\n
Prin urmare, guvernatorul trebuie s\u0103 fie doar performance. Ondemand, powersave \u0219i altele \u2013 nu sunt pentru dumneavoastr\u0103. <\/p>\n
<\/p>\n
Rezultatele ob\u021binute prin explain analyze PostgreSQL pot varia cu c\u00e2teva ordine, dac\u0103 activa\u021bi powersave, deoarece practic CPU-ul va fi planificat de baz\u0103 \u00eentr-un mod complet imprevizibil.<\/p>\n
<\/p>\n
Aceste lucruri pot fi activate implicit. Verifica\u021bi cu aten\u021bie \u2013 nu cumva au fost activate implicit. Aceasta ar putea fi realmente o problem\u0103 mare. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i la final, a\u0219 dori s\u0103 le mul\u021bumesc b\u0103ie\u021bilor din echipa noastr\u0103 DBA PostgreSQL-Consulting, mai precis lui Max Boguc \u0219i Alexei Lesovski, care \u00ee\u0219i asum\u0103 zilnic provoc\u0103rile acestui domeniu. \u00cencerc\u0103m s\u0103 oferim clien\u021bilor no\u0219tri cele mai bune solu\u021bii pentru ca totul s\u0103 func\u021bioneze perfect. Aici e ca la instruc\u021biunile de siguran\u021b\u0103 aerian\u0103. Totul este scris \u00een s\u00e2nge. Fiecare dintre aceste probleme a fost descoperit\u0103 \u00een urma unor dificult\u0103\u021bi. Sunt bucuros s\u0103 le \u00eemp\u0103rt\u0103\u0219esc cu voi.<\/p>\n
<\/p>\n
\u00centreb\u0103ri:<\/p>\n
<\/p>\n
Mul\u021bumesc! De exemplu, dac\u0103 o companie dore\u0219te s\u0103 economiseasc\u0103 \u0219i s\u0103 g\u0103zduiasc\u0103 baza de date \u0219i logica aplica\u021biei pe acela\u0219i server, sau dac\u0103 compania urmeaz\u0103 tendin\u021ba modern\u0103 a arhitecturilor de microservicii, \u00een care PostgreSQL ruleaz\u0103 \u00eentr-un container. Care este cheia? Sysctl afecteaz\u0103 global toate nucleele. Nu am auzit s\u0103 fie sysctl virtualizate pentru a func\u021biona separat pe containere. Exist\u0103 doar cgroup \u0219i acolo exist\u0103 control doar pe o parte. Cum se poate convie\u021bui cu asta? Sau, dac\u0103 dori\u021bi performan\u021b\u0103, atunci rula\u021bi PostgreSQL pe un server fizic dedicat \u0219i optimiza\u021bi-l?<\/em><\/p>\n<\/p>\n
Am r\u0103spuns la \u00eentrebarea dvs. \u00een aproximativ trei moduri. Dac\u0103 nu este vorba despre un server fizic, care poate fi optimizat etc., atunci relaxa\u021bi-v\u0103, va func\u021biona bine f\u0103r\u0103 aceste set\u0103ri. Dac\u0103 ajunge\u021bi la o \u00eenc\u0103rcare at\u00e2t de mare \u00eenc\u00e2t s\u0103 fie necesare aceste set\u0103ri, atunci ve\u021bi ajunge mai repede la un server fizic dec\u00e2t la aceste set\u0103ri.<\/p>\n
<\/p>\n
Care este problema? Dac\u0103 este o ma\u0219in\u0103 virtual\u0103, cel mai probabil ve\u021bi avea multe probleme, de exemplu, cu consisten\u021ba laten\u021bei discului, care este adesea inconsistent\u0103 pe majoritatea ma\u0219inilor virtuale. Chiar dac\u0103 l\u0103\u021bimea de band\u0103 a discurilor este bun\u0103, o tranzac\u021bie defectuoas\u0103 \u00een opera\u021biunile de intrare-ie\u0219ire, care nu afecteaz\u0103 semnificativ l\u0103\u021bimea de band\u0103 medie, poate ap\u0103rea \u00een timpul unui checkpoint sau \u00een timpul unei scrieri \u00een WAL, iar baza de date va suferi mult din aceast\u0103 cauz\u0103. Ve\u021bi observa aceste probleme \u00eenainte de a v\u0103 confrunta cu ele. <\/p>\n
<\/p>\n
Dac\u0103 ave\u021bi NGINX pe acela\u0219i server, va ap\u0103rea aceea\u0219i problem\u0103. Se va lupta pentru memoria partajat\u0103. \u0218i nu ve\u021bi ajunge la problemele descrise aici.<\/p>\n
<\/p>\n
Dar, pe de alt\u0103 parte, unele dintre aceste parametri tot vor fi relevan\u021bi pentru tine. De exemplu, po\u021bi seta dirty_ratio cu sysctl, astfel \u00eenc\u00e2t s\u0103 nu fie at\u00e2t de extrem \u2013 oricum, acest lucru va ajuta. \u00cen orice caz, interac\u021biunea ta cu discul va exista. \u0218i va fi pe o schem\u0103 gre\u0219it\u0103. Acestea sunt, de fapt, parametrii default pe care i-am ar\u0103tat. \u0218i \u00een orice caz, este mai bine s\u0103-i schimbi. <\/p>\n
<\/p>\n
Dar cu NUMA pot ap\u0103rea probleme. VmWare, de exemplu, func\u021bioneaz\u0103 bine cu NUMA cu set\u0103rile exact opuse. Aici trebuie s\u0103 alegi \u2013 server fizic sau nu. <\/p>\n
<\/p>\n
Am o \u00eentrebare legat\u0103 de Amazon AWS. Au imagini preconfigurate. Una dintre ele se nume\u0219te Amazon RDS. Exist\u0103 acolo set\u0103ri personalizate pentru sistemul lor de operare?<\/em><\/p>\n<\/p>\n
Exist\u0103 set\u0103ri, dar acestea sunt alte set\u0103ri. Aici configur\u0103m sistemul de operare din perspectiva modului \u00een care baza de date va folosi acest lucru. Acolo sunt parametrii care definesc \u00eencotro mergem acum, a\u0219a c\u0103 este un fel de shaping. Adic\u0103, avem nevoie de at\u00e2tea resurse, le vom consuma acum. Dup\u0103 aceea, Amazon RDS le ata\u0219eaz\u0103, iar performan\u021ba scade. Exist\u0103 pove\u0219ti \u00een care oamenii \u00eencep s\u0103 experimenteze cu acest lucru. Uneori chiar cu succes destul de mare. Dar aceasta nu are leg\u0103tur\u0103 cu set\u0103rile OS. Este un fel de hacking al cloud-ului. Este o alt\u0103 poveste.<\/p>\n
<\/p>\n
De ce paginile mari transparente nu au efect comparativ cu Huge TLB?<\/em><\/p>\n<\/p>\n
Nu au. Acest lucru poate fi explicat \u00een multe feluri. Dar, de fapt, pur \u0219i simplu nu au efect. Care este povestea cu PostgreSQL? La start, acesta aloc\u0103 un mare bloc de memorie partajat\u0103. Fie c\u0103 sunt transparente sau nu \u2013 este complet irelevant. Faptul c\u0103 sunt alocate la start explic\u0103 totul. \u0218i dac\u0103 exist\u0103 foarte mult\u0103 memorie \u0219i trebuie s\u0103 reconstruie\u0219ti segmentul shared_memory, atunci paginile mari transparente vor fi relevante. La PostgreSQL, acesta este pur \u0219i simplu alocat ca un bloc uria\u0219 la start \u0219i nimic special nu se \u00eent\u00e2mpl\u0103 mai departe. Poate fi desigur utilizat, dar exist\u0103 riscul de corup\u021bie a shared_memory, c\u00e2nd va trebui s\u0103 realoce ceva. PostgreSQL nu \u0219tie despre acest lucru.<\/p>\n
Sursa: 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
![\"Optimizarea](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n