Podešavanje Linuxa za poboljšanje performansi PostgreSQL-a. Ilja Kosmodemjanski

Transkript izvješća Ilye Kosmodemyanskyja iz 2015. "Podešavanje Linuxa za poboljšanje PostgreSQL performansi"

Odricanje od odgovornosti: Napominjem da je ovo izvješće datirano u studenom 2015. - prošlo je više od 4 godine i puno je vremena prošlo. Verzija 9.4 o kojoj se govori u izvješću više nije podržana. U protekle 4 godine objavljeno je 5 novih izdanja PostgreSQL-a i 15 verzija Linux kernela. Ako prepišete ove odlomke, dobit ćete drugačiji izvještaj. Ali ovdje razmatramo temeljno podešavanje Linuxa za PostgreSQL, koje je i danas relevantno.

Moje ime je Ilya Kosmodemyansky. Radim u PostgreSQL-Consultingu. A sada ću malo govoriti o tome što učiniti s Linuxom u odnosu na baze podataka općenito, a posebno PostgreSQL, jer su principi prilično slični.

O čemu ćemo razgovarati? Ako komunicirate s PostgreSQL-om, tada u određenoj mjeri morate biti UNIX administrator. Što to znači? Ako usporedimo Oracle i PostgreSQL, onda u Oracleu trebate biti 80% DBA administrator baze podataka i 20% Linux admin.

S PostgreSQL je malo kompliciranije. Uz PostgreSQL morate puno bolje razumjeti kako Linux radi. A ujedno i trči malo za lokomotivom jer se u zadnje vrijeme sve lijepo aktualiziralo. Izdaju se nove jezgre, pojavljuju se nove funkcionalnosti, poboljšavaju se performanse itd.

Zašto govorimo o Linuxu? Nimalo zato što smo na Linux konferenciji Peter, nego zato što je u suvremenim uvjetima jedan od najopravdanijih operativnih sustava za korištenje baza podataka općenito, a posebno PostgreSQL-a upravo Linux. Jer FreeBSD se, nažalost, razvija u nekom vrlo čudnom smjeru. A bit će problema i s izvedbom i s mnogim drugim stvarima. Izvedba PostgreSQL-a na Windowsima općenito je zaseban ozbiljan problem, temeljen na činjenici da Windows nema istu zajedničku memoriju kao UNIX, dok je PostgreSQL sav vezan uz to, jer je višeprocesni sustav.

A mislim da sve manje zanima egzotika poput Solarisa pa ajmo.

Moderna distribucija Linuxa ima više od 1 syctl opcija, ovisno o tome kako gradite kernel. U isto vrijeme, ako pogledamo različite matice, možemo nešto prilagoditi na mnogo načina. Postoje parametri datotečnog sustava o tome kako ih montirati. Ako imate pitanja o tome kako ga pokrenuti: što omogućiti u BIOS-u, kako konfigurirati hardver itd.

Ovo je vrlo velik volumen o kojem se može raspravljati nekoliko dana, a ne u jednom kratkom izvješću, ali sada ću se usredotočiti na važne stvari, kako izbjeći te grablje koje će vas zajamčeno spriječiti da dobro koristite svoju bazu podataka na Linuxu ako nemojte ih ispravljati . U isto vrijeme, važna točka je da mnogi zadani parametri nisu uključeni u postavke koje su točne za bazu podataka. Odnosno, prema zadanim postavkama radit će loše ili uopće neće raditi.

Koji tradicionalni ciljevi podešavanja postoje u Linuxu? Mislim da, budući da se svi bavite administracijom Linuxa, nema posebne potrebe objašnjavati što su ciljevi.

Možete podesiti:

• CPU.
• Memorija.
• Skladištenje.
• ostalo. O ovome ćemo na kraju za užinu. Čak, na primjer, parametri kao što je politika uštede energije mogu utjecati na performanse na vrlo nepredvidiv i ne najugodniji način.

Koje su specifičnosti PostgreSQL-a i baze podataka općenito? Problem je u tome što ne možete podesiti nijednu pojedinačnu maticu i vidjeti da se naša izvedba značajno poboljšala.

Da, postoje takvi gadgeti, ali baza podataka je složena stvar. Interakcija je sa svim resursima koje poslužitelj ima i preferira interakciju u potpunosti. Ako pogledate trenutne preporuke Oraclea o tome kako koristiti host OS, to će biti kao u šali o onom mongolskom kozmonautu - nahranite psa i ne dirajte ništa. Dajmo bazi podataka sve resurse, baza će sama sve srediti.

U principu, donekle je ista situacija s PostgreSQL-om. Razlika je u tome što baza podataka još ne može uzeti sve resurse za sebe, tj. negdje na razini Linuxa to morate sami srediti.

Glavna ideja nije odabrati jedan cilj i početi ga podešavati, na primjer, memoriju, CPU ili nešto slično, već analizirati radno opterećenje i pokušati poboljšati propusnost što je više moguće kako bi opterećenje koje su stvorili dobri programeri za nas, uključujući naše korisnike.

Evo slike da objasnim o čemu se radi. Postoji Linux OS međuspremnik i postoji zajednička memorija i postoje PostgreSQL zajednički međuspremnici. PostgreSQL, za razliku od Oraclea, radi direktno samo kroz međuspremnik jezgre, tj. da bi stranica s diska dospjela u svoju zajedničku memoriju, mora proći kroz međuspremnik jezgre i natrag, potpuno ista situacija.

Diskovi žive pod ovim sustavom. Ovo sam nacrtao kao diskove. Zapravo, možda postoji RAID kontroler, itd.

I ovaj input-output se na ovaj ili onaj način događa kroz ovu materiju.

PostgreSQL je klasična baza podataka. Unutra je stranica. Sav unos i izlaz odvija se pomoću stranica. Stranicama podižemo blokove u memoriju. A ako se ništa ne dogodi, mi ih samo čitamo, zatim postupno nestaju iz ove predmemorije, iz zajedničkih međuspremnika i završavaju natrag na disku.

Ako negdje nešto zamijenimo, onda je cijela stranica označena kao prljava. Ovdje sam ih označio plavom bojom. A to znači da ova stranica mora biti sinkronizirana s blok pohranom. Odnosno, kada smo ga napravili prljavim, napravili smo unos u WAL. I u nekom divnom trenutku u vremenu pojavio se fenomen koji se zove kontrolna točka. I u ovom dnevniku je zabilježena informacija da je stigao. A to znači da su sve prljave stranice koje su u tom trenutku bile ovdje u ovim zajedničkim međuspremnicima sinkronizirane s diskom za pohranu koristeći fsync kroz međuspremnik jezgre.

Zašto se to radi? Ako smo izgubili napon, onda nismo dobili situaciju da su svi podaci izgubljeni. Perzistentna memorija, o kojoj su nam svi govorili, zasad je u teoriji baza podataka - to je svijetla budućnost, kojoj mi, naravno, težimo i sviđa nam se, ali za sada žive u minus 20 godina. I, naravno, sve to treba pratiti.

A zadatak maksimiziranja propusnosti je fino podešavanje svih tih faza tako da se sve brzo kreće naprijed-natrag. Zajednička memorija je u osnovi predmemorija stranice. U PostgreSQL-u smo poslali upit za odabir ili tako nešto, on je dohvatio te podatke s diska. Završili su u zajedničkim međuspremnicima. Sukladno tome, da bi ovo bolje funkcioniralo, mora biti puno memorije.

Da bi sve ovo radilo dobro i brzo, morate ispravno konfigurirati operativni sustav u svim fazama. I birajte balansirani hardver, jer ako imate disbalans na nekom mjestu, onda možete napraviti puno memorije, ali neće biti servisirana dovoljnom brzinom.

I prođimo kroz svaku od ovih točaka.

Kako bi te stranice brže putovale naprijed i natrag, morate postići sljedeće:

• Prvo, morate učinkovitije raditi s memorijom.
• Drugo, ovaj prijelaz kada stranice iz memorije idu na disk trebao bi biti učinkovitiji.
• I treće, moraju postojati dobri diskovi.

Ako imate 512 GB RAM-a na poslužitelju i sve to završi na SATA tvrdom disku bez predmemorije, tada se cijeli poslužitelj baze podataka pretvara ne samo u bundevu, već u bundevu sa SATA sučeljem. Naletjet ćete izravno na to. I ništa vas neće spasiti.

Što se tiče prve točke s pamćenjem, postoje tri stvari koje mogu jako otežati život.

Prvi od njih je NUMA. NUMA je stvar koja je napravljena da poboljša performanse. Ovisno o radnom opterećenju, različite stvari se mogu optimizirati. A u svom novom sadašnjem obliku, nije baš dobar za aplikacije kao što su baze podataka koje intenzivno koriste dijeljene međuspremnike predmemorije stranica.

U suštini. Kako možete znati da nešto nije u redu s NUMA? Imate neku vrstu neugodnog kucanja, odjednom je neki CPU preopterećen. U isto vrijeme analizirate upite u PostgreSQL-u i vidite da tamo nema ništa slično. Ovi upiti ne bi trebali biti toliko intenzivni za CPU. Ovo možete uhvatiti dugo. Lakše je koristiti ispravnu preporuku od samog početka o tome kako konfigurirati NUMA za PostgreSQL.

Što se zapravo događa? NUMA je kratica za nejednaki pristup memoriji. Koja je svrha? Imate CPU, pored njega je njegova lokalna memorija. I ove memorijske interkonekcije mogu povući memoriju iz drugih CPU-a.

Ako trčite numactl --hardware, onda ćete dobiti tako veliki list. Između ostalog, tu će biti i polje udaljenosti. Bit će brojeva - 10-20, tako nešto. Ovi brojevi nisu ništa drugo doli broj skokova za preuzimanje ove udaljene memorije i njezino lokalno korištenje. U principu, dobra ideja. To znatno ubrzava rad pod nizom radnih opterećenja.

Zamislite sada da imate jedan CPU koji prvo pokušava koristiti svoju lokalnu memoriju, a zatim pokušava izvući drugu memoriju putem interkonekcije za nešto. I ovaj CPU dobiva vašu cijelu predmemoriju PostgreSQL stranice - to je to, nekoliko gigabajta. Uvijek dobijete najgori slučaj, jer na CPU obično ima malo memorije u samom modulu. I sva memorija koja se servisira prolazi kroz ove interkonekcije. Ispada sporo i tužno. A vaš procesor koji opslužuje ovaj čvor stalno je preopterećen. I vrijeme pristupa ovoj memoriji je loše, sporo. Ovo je situacija koju ne želite ako ovo koristite za bazu podataka.

Stoga je ispravnija opcija za bazu podataka da operativni sustav Linux ne zna što se tamo uopće događa. Tako da pristupa memoriji onako kako to čini.

Zašto je to? Čini se da bi trebalo biti obrnuto. To se događa iz jednog jednostavnog razloga: potrebno nam je mnogo memorije za predmemoriju stranica - deseci, stotine gigabajta.

A ako smo sve to dodijelili i tamo spremili naše podatke u predmemoriju, tada će dobitak od korištenja predmemorije biti znatno veći od dobitka od tako lukavog pristupa memoriji. I time ćemo imati neusporedivu korist u usporedbi s činjenicom da ćemo memoriji pristupati učinkovitije koristeći NUMA.

Dakle, ovdje trenutno postoje dva pristupa, dok nije stigla svijetla budućnost, a sama baza podataka nije u stanju dokučiti na kojim CPU-ima radi i odakle treba nešto izvući.

Stoga je ispravan pristup potpuno onemogućiti NUMA, na primjer, prilikom ponovnog pokretanja. U većini slučajeva, dobici su takvih redova veličina da se pitanje što je bolje uopće ne postavlja.

Postoji još jedna opcija. Koristimo ga češće od prvog, jer kada klijent dođe kod nas po podršku, ponovno pokretanje servera za njega je velika stvar. Tamo ima posao. I oni imaju problema zbog NUMA. Stoga ga pokušavamo onemogućiti na manje invazivne načine od ponovnog pokretanja, ali pazite da provjerite je li onemogućen. Jer, kako iskustvo pokazuje, dobro je da onemogućimo NUMA na nadređenom PostgreSQL procesu, ali uopće nije nužno da će raditi. Moramo provjeriti i vidjeti je li se stvarno isključila.

Postoji dobar post Roberta Haasa. Ovo je jedan od PostgreSQL komitatora. Jedan od ključnih programera svih sitnica niske razine. A ako pratite poveznice iz ovog posta, one opisuju nekoliko živopisnih priča o tome kako je NUMA zagorčavala život ljudima. Pogledajte, proučite kontrolni popis administratora sustava o tome što treba konfigurirati na poslužitelju kako bi naša baza podataka dobro radila. Ove postavke treba zapisati i provjeriti, jer inače neće biti baš dobro.

Imajte na umu da se ovo odnosi na sve postavke o kojima ću govoriti. Ali obično se baze podataka prikupljaju u načinu master-slave radi tolerancije na greške. Ne zaboravite napraviti ove postavke na slave jer ćete jednog dana doživjeti nezgodu i prebacit ćete se na slave i on će postati master.

U hitnoj situaciji, kada je sve jako loše, telefon vam neprestano zvoni, a vaš šef dotrči s velikom batinom, nećete imati vremena razmišljati o provjeri. A rezultati mogu biti poprilično katastrofalni.

Sljedeća točka su ogromne stranice. Ogromne stranice je teško zasebno testirati i nema smisla to raditi, iako postoje mjerila koja to mogu. Lako ih je guglati.

Koja je svrha? Imate ne baš skup poslužitelj s puno RAM-a, na primjer, više od 30 GB. Ne koristite ogromne stranice. To znači da definitivno imate dodatnih troškova u smislu upotrebe memorije. A ova režija daleko je od najugodnijeg.

Zašto je to? I što ima? Operativni sustav dodjeljuje memoriju u malim dijelovima. Tako je zgodno, tako se to dogodilo povijesno. A ako idemo u detalje, OS mora prevesti virtualne adrese u fizičke. A ovaj proces nije najjednostavniji, pa OS pohranjuje rezultat ove operacije u Translation Lookaside Buffer (TLB).

A budući da je TLB predmemorija, svi problemi svojstveni predmemoriji nastaju u ovoj situaciji. Prvo, ako imate puno RAM-a i sav je alociran u malim dijelovima, tada ovaj međuspremnik postaje vrlo velik. A ako je predmemorija velika, pretraživanje po njoj je sporije. Overhead je zdrav i sam zauzima prostor, tj. RAM troši nešto neispravno. Ovaj put.

Drugo - što više predmemorija raste u takvoj situaciji, veća je vjerojatnost da ćete imati promašaje predmemorije. Učinkovitost ove predmemorije brzo opada kako se njezina veličina povećava. Stoga su operativni sustavi smislili jednostavan pristup. Dugo se koristi u Linuxu. Pojavio se u FreeBSD-u ne tako davno. Ali mi govorimo o Linuxu. To su ogromne stranice.

I ovdje treba napomenuti da su ogromne stranice, kao ideju, inicijalno gurale zajednice koje su uključivale Oracle i IBM, odnosno proizvođači baza podataka itekako su mislili da bi to bilo korisno i za baze podataka.

I kako se ovo može sprijateljiti s PostgreSQL-om? Prvo, ogromne stranice moraju biti omogućene u Linux kernelu.

Drugo, moraju biti eksplicitno specificirani parametrom sysctl - koliko ih ima. Brojevi ovdje su s nekog starog poslužitelja. Možete izračunati koliko zajedničkih međuspremnika imate tako da tamo stanu ogromne stranice.

A ako je cijeli vaš poslužitelj posvećen PostgreSQL-u, onda je dobro polazište dodijeliti 25% RAM-a zajedničkim međuspremnicima ili 75% ako ste sigurni da će vaša baza podataka sigurno stati u ovih 75%. Polazna točka jedan. I razmislite, ako imate 256 GB RAM-a, tada ćete, prema tome, imati 64 GB velikih međuspremnika. Izračunajte otprilike s određenom marginom - na što treba postaviti ovu brojku.

Prije verzije 9.2 (ako se ne varam, od verzije 8.2), bilo je moguće povezati PostgreSQL s ogromnim stranicama pomoću biblioteke treće strane. I to uvijek treba činiti. Prvo, trebate kernel kako biste mogli pravilno dodijeliti ogromne stranice. I, drugo, kako bi ih aplikacija koja radi s njima mogla koristiti. Neće se koristiti samo tako. Budući da je PostgreSQL dodijelio memoriju u stilu sustava 5, to se može učiniti pomoću libhugetlbfs - ovo je puni naziv knjižnice.

U 9.3, performanse PostgreSQL-a su poboljšane pri radu s memorijom, a metoda dodjele memorije sustava 5 je napuštena. Svi su bili jako sretni, jer inače pokušate pokrenuti dvije PostgreSQL instance na jednom stroju, a on kaže da nemam dovoljno zajedničke memorije. I kaže da sysctl treba ispraviti. I postoji takav sysctl koji još uvijek trebate ponovno pokrenuti, itd. Općenito, svi su bili sretni. No dodjela memorije mmap onemogućila je korištenje ogromnih stranica. Većina naših klijenata koristi velike zajedničke međuspremnike. I toplo preporučujemo da ne prelazite na 9.3, jer su se režijski troškovi tamo počeli izračunavati u dobrim postocima.

Ali zajednica je obratila pozornost na ovaj problem iu 9.4 su vrlo dobro preradili ovaj događaj. A u 9.4 pojavio se parametar u postgresql.conf u kojem možete uključiti ili isključiti pokušaj.

Pokušajte je najsigurnija opcija. Kada se PostgreSQL pokrene, kada dodjeljuje zajedničku memoriju, pokušava zgrabiti ovu memoriju s ogromnih stranica. A ako ne radi, vraća se na uobičajeni odabir. A ako imate FreeBSD ili Solaris, onda možete pokušati, uvijek je sigurno.

Ako je uključeno, jednostavno se ne pokreće ako ne može odabrati s ogromnih stranica. Ovdje se već radi o tome tko je i što je ljepši. No, ako morate pokušati, onda provjerite imate li doista istaknuto ono što vam treba, jer ima puno prostora za pogreške. Trenutno ova funkcija radi samo na Linuxu.

Još jedna mala napomena prije nego što nastavimo. Prozirne ogromne stranice još nisu o PostgreSQL-u. Ne može ih normalno koristiti. A uz Transparent ogromne stranice za takvo radno opterećenje, kada je potreban veliki komad zajedničke memorije, prednosti dolaze samo s vrlo velikim količinama. Ako imate terabajte memorije, to može doći u obzir. Ako govorimo o svakodnevnijim aplikacijama, kada imate 32, 64, 128, 256 GB memorije na računalu, onda su uobičajene ogromne stranice OK, a Transparent jednostavno onemogućujemo.

I zadnja stvar u vezi s pamćenjem nije izravno povezana s voćem, ono vam stvarno može uništiti život. Na svu propusnost uvelike će utjecati činjenica da se poslužitelj stalno mijenja.

A to će biti vrlo neugodno na više načina. A glavni problem je što se moderne jezgre ponašaju malo drugačije od starijih jezgri Linuxa. A ova stvar je prilično neugodna za gaziti, jer kada govorimo o nekakvom poslu sa swapom, on završava preranim dolaskom OOM-killera. A OOM-ubojica, koji nije stigao na vrijeme i ispustio PostgreSQL, je neugodan. Za ovo će znati svi, odnosno do zadnjeg korisnika.

Što se događa? Tu imate veliku količinu RAM-a, sve radi dobro. Ali iz nekog razloga poslužitelj visi u swapu i zbog toga usporava. Čini se da ima puno memorije, ali to se događa.

Ranije smo savjetovali postavljanje vm.swappiness na nulu, tj. onemogućavanje swapa. Ranije se činilo da je 32 GB RAM-a i odgovarajućih dijeljenih međuspremnika ogromna količina. Glavna svrha zamjene je da imamo gdje baciti koru ako padnemo. I nije se više osobito ispunjavalo. I što ćeš onda s ovom korom? Ovo je zadatak kod kojeg nije baš jasno zašto je potrebna zamjena, pogotovo takve veličine.

Ali u modernijim, tj. trećim verzijama kernela, ponašanje se promijenilo. A ako swap postavite na nulu, tj. isključite ga, onda će vam prije ili kasnije, čak i ako ostane nešto RAM-a, doći OOM killer da ubije najintenzivnije potrošače. Jer on će smatrati da nam s takvim opterećenjem još malo ostaje i iskočit ćemo, dakle, ne da zakucamo sistemski proces, nego da zakucamo nešto manje bitno. Ovaj manje važan bit će intenzivni konzument zajedničke memorije, naime upravitelj pošte. A nakon toga će biti dobro ako se baza ne mora obnavljati.

Prema tome, sada je default, koliko se sjećam, većina distribucija negdje oko 6, tj. u kojem trenutku treba početi koristiti swap ovisno o tome koliko je memorije ostalo. Sada preporučujemo da postavite vm.swappiness = 1, jer ga to praktički isključuje, ali ne daje iste efekte kao kod OOM-killera koji je neočekivano stigao i ubio cijelu stvar.

Što je sljedeće? Kada govorimo o performansama baza podataka i postupnom prelasku na diskove, svi se počnu hvatati za glavu. Jer istina da je disk spor, a memorija brza svima je poznata od djetinjstva. I svi znaju da će baza podataka imati problema s performansama diska.

Glavni problem performansi PostgreSQL-a povezan sa skokovima kontrolnih točaka ne pojavljuje se jer je disk spor. To je najvjerojatnije zbog činjenice da memorija i propusnost diska nisu uravnoteženi. Međutim, oni možda neće biti uravnoteženi na različitim mjestima. PostgreSQL nije konfiguriran, OS nije konfiguriran, hardver nije konfiguriran i hardver nije ispravan. A ovaj problem se ne događa samo ako se sve odvija kako treba, tj. ili nema opterećenja ili su postavke i hardver dobro odabrani.

Što je to i kako izgleda? Obično su ljudi koji rade s PostgreSQL-om ulazili u ovu temu više puta. objasnit ću ti. Kao što sam rekao, PostgreSQL povremeno postavlja kontrolne točke za izbacivanje prljavih stranica iz zajedničke memorije na disk. Ako imamo veliku količinu zajedničke memorije, tada kontrolna točka počinje intenzivno utjecati na disk, jer izbacuje te stranice pomoću fsync-a. Stiže u međuspremnik jezgre i zapisuje se na diskove koristeći fsync. A ako je obujam ovog posla velik, onda možemo primijetiti neugodan učinak, naime vrlo veliku iskorištenost diskova.

Evo imam dvije slike. Sada ću objasniti što je to. Ovo su dva vremenski korelirana grafikona. Prvi grafikon je iskorištenost diska. Ovdje doseže gotovo 90% u ovom trenutku. Ako imate kvar baze podataka s fizičkim diskovima, s iskorištenjem RAID kontrolera na 90%, onda su to loše vijesti. To znači da će još malo doći do 100 i I/O će prestati.

Ako imate diskovno polje, onda je malo drugačija priča. Ovisi o tome kako je konfiguriran, kakav je niz itd.

I paralelno, ovdje je konfiguriran graf iz internog postgres pogleda, koji govori kako dolazi do kontrolne točke. A zelena boja ovdje pokazuje koliko je međuspremnika, ovih prljavih stranica, u tom trenutku stiglo na ovu kontrolnu točku za sinkronizaciju. A ovo je glavna stvar koju ovdje morate znati. Vidimo da ovdje imamo puno stranica i u nekom trenutku smo udarili u ploču, odnosno pisali smo i pisali, ovdje je diskovni sustav očito jako zauzet. A naša kontrolna točka ima vrlo snažan utjecaj na disk. U idealnom slučaju, situacija bi trebala izgledati više ovako, tj. da smo ovdje imali manje snimanja. A možemo to popraviti postavkama da i dalje bude ovako. Odnosno, reciklaža je mala, ali tu negdje nešto pišemo.

Što je potrebno učiniti da se prevlada ovaj problem? Ako ste zaustavili IO pod bazom podataka, to znači da će svi korisnici koji su došli ispuniti svoje zahtjeve čekati.

Ako gledate sa stajališta Linuxa, ako ste uzeli dobar hardver, pravilno ga konfigurirali, normalno konfigurirali PostgreSQL tako da rjeđe pravi te kontrolne točke, raspoređuje ih kroz vrijeme jedne na druge, tada ulazite u zadane Debianove parametre. Za većinu distribucija Linuxa ovo je slika: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Što to znači? Jedan demon ispiranja pojavio se iz kernela 2.6. Pdglush, ovisno o tome tko koristi koji, koji se bavi pozadinskim odbacivanjem prljavih stranica iz međuspremnika kernela i odbacivanjem kada je potrebno odbaciti prljave stranice bez obzira na sve, kada pozadinsko odbacivanje ne pomaže.

Kada dolazi pozadina? Kada je 10% ukupnog RAM-a dostupnog na poslužitelju zauzeto prljavim stranicama u međuspremniku jezgre, poziva se posebna funkcija otpisa u pozadini. Zašto je pozadina? Kao parametar, uzima u obzir koliko stranica otpisati. I, recimo, otpisuje N stranica. I na neko vrijeme ova stvar zaspi. A onda opet dolazi i kopira još neke stranice.

Ovo je krajnje jednostavna priča. Ovdje je problem kao kod bazena, kada se ulije u jednu cijev, ulijeva se u drugu. Naša kontrolna točka je stigla i ako je poslala nekoliko prljavih stranica na odbacivanje, onda će postupno cijela stvar biti uredno riješena iz međuspremnika kernela pgflush.

Ako se te prljave stranice i dalje gomilaju, nakupi se i do 20% nakon čega je prioritet OS-a otpisati cijelu stvar na disk jer će pasti struja i sve će nam biti loše. Na primjer, izgubit ćemo te podatke.

U čemu je trik? Trik je u tome što ti parametri u modernom svijetu iznose 20 i 10% ukupnog RAM-a koji je na stroju, oni su apsolutno monstruozni u smislu propusnosti bilo kojeg diskovnog sustava koji imate.

Zamislite da imate 128 GB RAM-a. U vaš diskovni sustav stiže 12,8 GB. I bez obzira koju predmemoriju imate, bez obzira na niz koji imate, neće trajati toliko dugo.

Stoga preporučujemo da odmah prilagodite ove brojeve na temelju mogućnosti vašeg RAID kontrolera. Ovdje sam odmah dao preporuku za kontroler koji ima 512 MB predmemorije.

Sve se smatra vrlo jednostavnim. Možete staviti vm.dirty_background u bajtovima. I ove postavke poništavaju prethodne dvije. Ili je omjer zadani ili su oni s bajtovima aktivirani, tada će oni s bajtovima raditi. Ali budući da sam DBA konzultant i radim s različitim klijentima, pokušavam izvlačiti slamke i stoga, ako u bajtovima, onda u bajtovima. Nitko nije dao garanciju da dobar admin neće dodati memoriju na server, ponovno ga pokrenuti, a cifra će ostati ista. Samo izračunajte ove brojke tako da sve stane unutra s jamstvom.

Što se događa ako se ne uklopiš? Napisao sam da je svako ispiranje učinkovito zaustavljeno, ali to je zapravo figura govora. Operativni sustav ima veliki problem - ima mnogo prljavih stranica, pa je IO koji generiraju vaši klijenti efektivno zaustavljen, tj. aplikacija je došla poslati sql upit bazi podataka, čeka. Svaki ulaz/izlaz u nju je najnižeg prioriteta, jer je baza podataka zauzeta kontrolnom točkom. A kada će završiti, potpuno je nejasno. A kada ste postigli ispiranje bez pozadine, to znači da je sav vaš IO zauzet njime. I dok ne završi, nećete učiniti ništa.

Ovdje postoje još dvije važne točke koje su izvan dosega ovog izvješća. Ove postavke trebaju odgovarati postavkama u postgresql.conf, tj. postavkama kontrolnih točaka. I vaš diskovni sustav mora biti adekvatno konfiguriran. Ako imate cache na RAID-u, onda mora imati bateriju. Ljudi kupuju RAID s dobrim cacheom bez baterije. Ako imate SSD u RAID-u, onda moraju biti serverski, tamo moraju biti kondenzatori. Ovdje je detaljan popis za provjeru. Ova poveznica sadrži moje izvješće o tome kako konfigurirati disk performansi u PostgreSQL-u. Postoje svi ti popisi za provjeru.

Što još može jako otežati život? To su dva parametra. Relativno su novi. Prema zadanim postavkama mogu se uključiti u različite aplikacije. A mogu zagorčati život i ako su uključeni na pogrešan način.

Dvije su relativno nove stvari. Već su se pojavili u trećim jezgrama. Ovo je sched_migration_cost u nanosekundama i sched_autogroup_enabled, što je jedan prema zadanim postavkama.

I kako vam uništavaju život? Što je sched_migration_cost? Na Linuxu planer može migrirati proces s jednog CPU-a na drugi. A za PostgreSQL, koji izvršava upite, migracija na drugi CPU potpuno je nejasna. Sa stajališta operativnog sustava, kada mijenjate prozore između openofficea i terminala, ovo može biti dobro, ali za bazu podataka to je jako loše. Stoga je razumna politika postaviti migration_cost na neku veliku vrijednost, barem nekoliko tisuća nanosekundi.

Što će to značiti za planera? Smatrat će se da je za to vrijeme proces još vruć. To jest, ako imate dugotrajnu transakciju koja je nešto radila dugo vremena, planer će to razumjeti. Pretpostavit će da dok ne prođe ovo vremensko ograničenje, nema potrebe za migriranjem ovog procesa bilo gdje. Ako proces u isto vrijeme učini nešto, onda se neće nikamo preseliti, tiho će raditi na CPU-u koji mu je dodijeljen. I rezultat je odličan.

Druga točka je autogroup. Postoji dobra ideja za određena radna opterećenja koja nisu povezana s modernim bazama podataka - to je grupiranje procesa prema virtualnom terminalu s kojeg se pokreću. Ovo je zgodno za neke zadatke. U praksi, PostgreSQL je višeprocesni sustav s preforkom koji se pokreće s jednog terminala. Imate zapisivač zaključavanja, kontrolnu točku i svi zahtjevi vaših klijenata bit će grupirani u jedan planer, po CPU-u. I tamo će složno čekati da bude slobodan, kako bi jedni drugima smetali i duže ga zaokupljali. To je priča koja je u slučaju ovakvog opterećenja potpuno nepotrebna i zato ju je potrebno isključiti.

Moj kolega Alexey Lesovsky napravio je testove s jednostavnim pgbenchom, gdje je povećao migration_cost za red veličine i isključio autogroup. Razlika na lošem hardveru bila je skoro 10%. Postoji rasprava na postgres mailing listi gdje ljudi daju rezultate sličnih promjena u brzini upita utjecao 50%. Ima dosta takvih priča.

I na kraju, o politici uštede energije. Dobra stvar je što se Linux sada može koristiti na prijenosnom računalu. I navodno će dobro potrošiti bateriju. Ali odjednom se ispostavilo da se to može dogoditi i na poslužitelju.

Štoviše, ako iznajmite servere od nekog hostera, onda “dobre” hostere nije briga što imate bolje performanse. Njihova je zadaća osigurati da se njihovo željezo iskoristi što učinkovitije. Stoga prema zadanim postavkama mogu omogućiti način rada za uštedu energije prijenosnog računala na operativnom sustavu.

Ako koristite ove stvari na poslužitelju s bazom podataka pod velikim opterećenjem, onda je vaš izbor acpi_cpufreq + permormance. Čak i s ondemand bit će problema.

Intel_pstate je nešto drugačiji upravljački program. I sada se prednost daje ovome, jer je kasniji i bolje radi.

I, sukladno tome, guverner je samo izvedba. Ondemand, powersave i sve ostalo se ne tiču ​​vas.

Rezultati objašnjene analize PostgreSQL mogu se razlikovati za nekoliko redova veličine ako omogućite uštedu energije, jer će praktički CPU u vašoj bazi podataka raditi na potpuno nepredvidiv način.

Ove stavke mogu biti uključene prema zadanim postavkama. Pažljivo pogledajte jesu li ga uključili prema zadanim postavkama. Ovo može biti stvarno veliki problem.

I na kraju, želio sam zahvaliti momcima iz našeg PosgreSQL-Consulting DBA tima, naime Maxu Boguku i Alexeyu Lesovskom, koji svakim danom napreduju u ovom pitanju. I trudimo se učiniti najbolje što možemo za naše klijente kako bi sve funkcioniralo za njih. To je kao s uputama za sigurnost u zrakoplovstvu. Ovdje je sve krvlju napisano. Svaki od ovih oraha nalazi se u procesu neke vrste problema. Rado ih dijelim s vama.

Pitanja:

Hvala vam! Ako, na primjer, tvrtka želi uštedjeti novac i smjestiti bazu podataka i logiku aplikacije na jedan poslužitelj ili ako tvrtka slijedi moderan trend mikroservisnih arhitektura, u kojima PostgreSQL radi u spremniku. U čemu je trik? Sysctl će utjecati na cijeli kernel globalno. Nisam čuo da je sysctl na neki način virtualiziran tako da radi odvojeno na spremniku. Postoji samo cgroup i tu je samo dio kontrole. Kako možeš živjeti s ovim? Ili ako želite performanse, onda pokrenite PostgreSQL na zasebnom hardverskom poslužitelju i podesite ga?

Odgovorili smo na vaše pitanje na otprilike tri načina. Ako ne govorimo o hardverskom poslužitelju koji se može podešavati itd., opustite se, sve će dobro raditi i bez ovih postavki. Ako imate takvo opterećenje da trebate napraviti ove postavke, tada ćete prije doći na željezni poslužitelj nego na ove postavke.

U čemu je problem? Ako je ovo virtualni stroj, tada ćete najvjerojatnije imati mnogo problema, na primjer, s činjenicom da je na većini virtualnih strojeva latencija diska prilično nedosljedna. Čak i ako je propusnost diska dobra, onda jedna neuspjela I/O transakcija koja ne utječe uvelike na prosječnu propusnost koja se dogodila u vrijeme kontrolne točke ili u vrijeme pisanja na WAL, tada će baza podataka uvelike patiti od toga. I to ćete primijetiti prije nego što naiđete na te probleme.

Ako imate NGINX na istom poslužitelju, također ćete imati isti problem. Borit će se za zajedničko sjećanje. I nećete doći do problema koji su ovdje opisani.

Ali s druge strane, neki od ovih parametara će vam i dalje biti relevantni. Na primjer, postavite dirty_ratio sa sysctl da ne bude toliko ludo - u svakom slučaju, ovo će pomoći. Na ovaj ili onaj način, imat ćete interakciju s diskom. I bit će po krivom obrascu. Ovo je općenito zadana vrijednost za parametre koje sam prikazao. I u svakom slučaju bolje ih je promijeniti.

Ali može biti problema s NUMA. VmWare, na primjer, dobro radi s NUMA s upravo suprotnim postavkama. I ovdje morate odabrati - željezni poslužitelj ili ne-željezni.

Imam pitanje vezano za Amazon AWS. Imaju unaprijed konfigurirane slike. Jedan od njih zove se Amazon RDS. Postoje li prilagođene postavke za njihov operativni sustav?

Tu postoje postavke, ali to su različite postavke. Ovdje konfiguriramo operativni sustav u smislu kako će baza podataka koristiti tu stvar. A postoje parametri koji određuju kuda sada trebamo ići, poput oblikovanja. Odnosno, trebamo toliko resursa da ćemo ih sada pojesti. Nakon toga, Amazon RDS sužava ove resurse, a performanse tu padaju. Postoje pojedinačne priče kako se ljudi počinju petljati s ovom stvari. Ponekad čak i prilično uspješno. Ali to nema nikakve veze s postavkama OS-a. To je kao hakiranje oblaka. To je druga priča.

Zašto Transparent huge pages nema učinka u usporedbi s Huge TLB-om?

Nemoj dati. To se može objasniti na mnogo načina. Ali zapravo oni to jednostavno ne daju. Koja je povijest PostgreSQL-a? Prilikom pokretanja dodjeljuje veliki dio zajedničke memorije. Jesu li transparentni ili ne potpuno je nebitno. To što se ističu u startu sve objašnjava. A ako ima puno memorije i trebate ponovno izgraditi segment shared_memory, tada će Transparentne ogromne stranice biti relevantne. U PostgreSQL-u se jednostavno dodjeljuje u veliki dio na početku i to je to, a onda se tu ne događa ništa posebno. Možete ga, naravno, koristiti, ali postoji mogućnost da dobijete korupciju shared_memory kada nešto ponovno dodjeljuje. PostgreSQL ne zna za ovo.

Izvor: www.habr.com