Transkript izvještaja Ilje Kosmodemjanskog iz 2015. "Podešavanje Linuxa za poboljšanje performansi PostgreSQL-a"
Disclaimer: Napominjem da je ovaj izvještaj datiran u novembru 2015. godine – prošlo je više od 4 godine i prošlo je dosta vremena. Verzija 9.4 o kojoj se govori u izvještaju 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 pasuse, na kraju ćete dobiti drugačiji izvještaj. Ali ovdje razmatramo fundamentalno podešavanje Linuxa za PostgreSQL, koje je i danas relevantno.
Moje ime je Ilja Kosmodemjanski. Radim u PostgreSQL-Consulting-u. A sada ću malo pričati o tome šta raditi sa Linuxom u odnosu na baze podataka uopšte i posebno na PostgreSQL, jer su principi prilično slični.
O čemu ćemo razgovarati? Ako komunicirate sa PostgreSQL-om, onda u određenoj mjeri morate biti UNIX administrator. Šta to znači? Ako uporedimo Oracle i PostgreSQL, onda u Oracleu morate biti 80% administrator DBA baze podataka i 20% Linux administrator.
Sa PostgreSQL-om je malo komplikovanije. Sa PostgreSQL-om morate mnogo bolje razumjeti kako Linux funkcionira. A ujedno trči malo za lokomotivom, jer je u zadnje vrijeme sve dosta lijepo ažurirano. I izdaju se novi kerneli, pojavljuju se nove funkcionalnosti, poboljšavaju se performanse itd.
Zašto govorimo o Linuxu? Nikako zato što smo na Linux konferenciji Peter, već zato što je u savremenim uslovima jedan od najopravdanijih operativnih sistema za korišćenje baza podataka uopšte, a posebno PostgreSQL-a, Linux. Jer FreeBSD se, nažalost, razvija u nekom vrlo čudnom smjeru. I biće problema i sa performansama i sa mnogim drugim stvarima. Performanse PostgreSQL-a na Windows-u su generalno poseban ozbiljan problem, zasnovan na činjenici da Windows nema istu zajedničku memoriju kao UNIX, dok je PostgreSQL sav vezan za ovo, jer je višeprocesni sistem.
I mislim da su svi manje zainteresirani za egzotiku kao što je Solaris, pa idemo.
Moderna Linux distribucija ima preko 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 sistema datoteka o tome kako ih montirati. Ako imate pitanja o tome kako ga pokrenuti: šta omogućiti u BIOS-u, kako konfigurirati hardver itd.
Ovo je jako velika količina o kojoj se može raspravljati nekoliko dana, a ne u jednom kratkom izvještaju, ali sada ću se fokusirati na važne stvari, kako izbjeći one grabe koje će vam garantirano spriječiti da dobro koristite svoju bazu podataka na Linuxu ako nemojte ih ispravljati. A u isto vrijeme, važna stvar je da mnogi zadani parametri nisu uključeni u postavke koje su ispravne za bazu podataka. Odnosno, po defaultu će raditi loše ili uopće neće raditi.
Koji tradicionalni ciljevi podešavanja postoje u Linuxu? Mislim da pošto se svi bavite administracijom Linuxa, nema posebne potrebe objašnjavati šta su ciljevi.
Možete podesiti:
- CPU.
- Memorija.
- Skladištenje.
- Ostalo. Razgovaraćemo o ovome 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 baš najprijatniji 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 su se naše performanse značajno poboljšale.
Da, postoje takvi uređaji, ali baza podataka je složena stvar. On je u interakciji sa svim resursima koje server ima i preferira interakciju u potpunosti. Ako pogledate trenutne Oracleove preporuke o tome kako koristiti host OS, to će biti kao u šali o tom mongolskom kosmonautu - nahranite psa i ništa ne dirajte. Damo bazi podataka sve resurse, sama baza podataka će sve srediti.
U principu, u određenoj mjeri situacija je potpuno ista sa PostgreSQL-om. Razlika je u tome što baza podataka još nije u stanju uzeti sve resurse za sebe, tj. negdje na nivou Linuxa morate sve sami srediti.
Osnovna ideja nije odabrati jedan cilj i početi ga podešavati, na primjer, memoriju, CPU ili nešto slično, već analizirati opterećenje i pokušati poboljšati propusnost što je više moguće kako bi opterećenje koje su dobri programeri kreirali za nas, uključujući naše korisnike.
Evo slike koja objašnjava šta je to. Postoji Linux OS bafer i postoji zajednička memorija i postoje PostgreSQL zajednički baferi. PostgreSQL, za razliku od Oraclea, radi direktno samo preko bafera kernela, odnosno, da bi stranica sa diska ušla u svoju zajedničku memoriju, mora proći kroz bafer kernela i nazad, potpuno ista situacija.
Diskovi žive pod ovim sistemom. Ovo sam nacrtao kao diskove. U stvari, može postojati RAID kontroler itd.
I ovaj ulaz-izlaz na ovaj ili onaj način se dešava kroz ovu materiju.
PostgreSQL je klasična baza podataka. Unutra je stranica. A sav ulaz i izlaz se dešava pomoću stranica. Podižemo blokove u memoriju sa stranicama. A ako se ništa nije dogodilo, samo ih čitamo, onda postepeno nestaju iz ove keš memorije, iz zajedničkih bafera i završavaju nazad 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 memorijom. Odnosno, kada smo ga zaprljali, napravili smo unos u WAL. I u nekom divnom trenutku, pojavio se fenomen koji se zove kontrolni punkt. I u ovom dnevniku je zabeležen podatak da je stigao. A to znači da su sve prljave stranice koje su bile ovdje u tom trenutku u tim zajedničkim baferima sinkronizirane sa diskom za pohranu koristeći fsync kroz bafer kernela.
Zašto se to radi? Ako smo izgubili napon, onda nismo došli u situaciju da su svi podaci izgubljeni. Trajno pamćenje, o kojem su nam svi pričali, do sada je u teoriji baza podataka - ovo je svijetla budućnost kojoj, naravno, težimo i sviđa nam se, ali za sada žive u minus 20 godina. I, naravno, sve ovo treba pratiti.
A zadatak maksimiziranja propusnosti je fino podešavanje u svim ovim fazama tako da se sve brzo kreće naprijed-nazad. Zajednička memorija je u osnovi keš stranica. U PostgreSQL-u smo poslali upit za odabir ili nešto slično, on je preuzeo ove podatke sa diska. Završili su u zajedničkim baferima. Shodno tome, da bi ovo bolje funkcioniralo, mora postojati puno memorije.
Da bi sve ovo funkcionisalo dobro i brzo, potrebno je da pravilno konfigurišete operativni sistem u svim fazama. I izaberite balansirani hardver, jer ako imate neravnotežu na nekom mjestu, onda možete napraviti puno memorije, ali neće biti servisirana dovoljnom brzinom.
I hajde da prođemo kroz svaku od ovih tačaka.
Da bi ove stranice brže putovale naprijed-nazad, morate postići sljedeće:
- Prvo, morate efikasnije raditi s memorijom.
- Drugo, ovaj prelaz kada stranice iz memorije idu na disk trebao bi biti efikasniji.
- I treće, moraju postojati dobri diskovi.
Ako imate 512 GB RAM-a na serveru i sve to završi na SATA hard disku bez ikakve keš memorije, onda se cijeli server baze podataka pretvara u ne samo bundevu, već bundevu sa SATA interfejsom. Naići ćete direktno na to. I ništa te neće spasiti.
Što se tiče prve tačke sa 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. U zavisnosti od obima posla, različite stvari se mogu optimizovati. A u svom novom trenutnom obliku, nije baš dobar za aplikacije kao što su baze podataka koje intenzivno koriste dijeljene bafere keša stranica.
Ukratko. Kako možete reći da nešto nije u redu sa NUMA-om? Imate neku vrstu neprijatnog kucanja, odjednom je neki CPU preopterećen. U isto vrijeme analizirate upite u PostgreSQL-u i vidite da tamo nema ničeg sličnog. Ovi upiti ne bi trebali biti toliko CPU intenzivni. Ovo možete uhvatiti dugo vremena. Lakše je koristiti ispravnu preporuku od samog početka o tome kako konfigurirati NUMA za PostgreSQL.
Šta se zapravo dešava? NUMA je skraćenica od neujednačenog pristupa memoriji. Koja je svrha? Imate CPU, pored njega je njegova lokalna memorija. I ove memorijske međukonekcije mogu povući memoriju iz drugih CPU-a.
Ako trčiš numactl --hardware, tada ćete dobiti tako veliki list. Između ostalog, postojaće polje udaljenosti. Biće brojeva - 10-20, tako nešto. Ovi brojevi nisu ništa drugo do broj skokova za preuzimanje ove udaljene memorije i korištenje je lokalno. U principu, dobra ideja. Ovo dobro ubrzava performanse u nizu radnih opterećenja.
Sada zamislite da imate jedan CPU koji prvo pokušava da koristi svoju lokalnu memoriju, a zatim pokušava da podigne drugu memoriju preko interkonekcije za nešto. I ovaj CPU dobija cijelu vašu keš memoriju PostgreSQL stranice - to je to, nekoliko gigabajta. Uvijek dobijete najgori slučaj, jer na CPU-u 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 servisira ovaj čvor je stalno 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 Linux operativni sistem uopšte ne zna šta se tamo dešava. Tako da pristupa memoriji onako kako to čini.
Žašto je to? Čini se da bi trebalo biti obrnuto. To se događa iz jednog jednostavnog razloga: potrebno nam je puno memorije za keš stranice - desetine, stotine gigabajta.
A ako smo sve ovo alocirali i tamo keširali naše podatke, tada će dobit od korištenja keša biti znatno veća od dobitka od tako lukavog pristupa memoriji. I time ćemo imati neuporedivu korist u odnosu na činjenicu da ćemo efikasnije pristupati memoriji koristeći NUMA.
Dakle, ovdje trenutno postoje dva pristupa, sve dok ne dođe svijetla budućnost, a sama baza podataka nije u stanju da shvati na kojim CPU-ima radi i odakle nešto treba izvući.
Stoga je ispravan pristup potpuno onemogućiti NUMA, na primjer, prilikom ponovnog pokretanja. U većini slučajeva dobici su takve veličine da se uopće ne postavlja pitanje šta je bolje.
Postoji još jedna opcija. Koristimo ga češće od prvog, jer kada klijent dođe kod nas za podršku, za njega je ponovno pokretanje servera velika stvar. On tamo ima posao. I oni imaju probleme 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, kao što iskustvo pokazuje, dobro je da deaktiviramo NUMA na nadređenom PostgreSQL procesu, ali uopće nije neophodno da će funkcionirati. Moramo provjeriti i vidjeti da li se stvarno isključila.
Postoji dobar post Roberta Haasa. Ovo je jedan od PostgreSQL izrezivača. Jedan od ključnih programera svih niskog nivoa iznutrica. A ako pratite linkove iz ovog posta, oni opisuju nekoliko živopisnih priča o tome kako je NUMA ljudima otežavala život. Gledajte, proučite kontrolnu listu administratora sistema šta treba da se konfiguriše na serveru da 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 master-slave modu radi tolerancije greške. Ne zaboravite napraviti ove postavke na slave-u jer ćete jednog dana imati nezgodu i prebacit ćete se na slave i on će postati master.
U hitnoj situaciji, kada je sve jako loše, vaš telefon stalno zvoni, a vaš šef trči sa velikim štapom, nećete imati vremena razmišljati o provjeri. A rezultati mogu biti prilično katastrofalni.
Sljedeća stvar su ogromne stranice. Ogromne stranice je teško testirati odvojeno, i nema smisla to činiti, iako postoje mjerila koja to mogu učiniti. Lako ih je Google.
Koja je svrha? Imate ne baš skup server s puno RAM-a, na primjer, više od 30 GB. Ne koristite velike stranice. To znači da definitivno imate dodatne troškove u smislu korištenja memorije. A ova režija je daleko od najprijatnijeg.
Žašto je to? Pa šta se dešava? Operativni sistem dodjeljuje memoriju u malim dijelovima. To je tako zgodno, tako se desilo istorijski. A ako idemo u detalje, OS mora prevesti virtuelne adrese u fizičke. A ovaj proces nije najjednostavniji, tako da OS kešira rezultat ove operacije u Translation Lookaside Buffer (TLB).
A pošto je TLB keš memorija, svi problemi svojstveni kešu nastaju u ovoj situaciji. Prvo, ako imate puno RAM-a i sve je dodijeljeno u malim komadima, tada ovaj bafer postaje vrlo velik. A ako je keš memorija velika, pretraživanje kroz nju je sporije. Overhead je zdrav i sam zauzima prostor, tj. RAM se troši nečim neispravnim. Ovaj put.
Drugo - što keš više raste u takvoj situaciji, veća je vjerovatnoća da ćete imati promašaje keša. A efikasnost ove keš memorije brzo opada kako se povećava njegova veličina. Stoga su operativni sistemi došli do jednostavnog pristupa. U Linuxu se koristi dugo vremena. Pojavio se u FreeBSD-u ne tako davno. Ali govorimo o Linuxu. Ovo su ogromne stranice.
I ovdje treba napomenuti da su ogromne stranice, kao ideju, u početku gurale zajednice koje su uključivale Oracle i IBM, odnosno proizvođači baza podataka su snažno mislili da bi to bilo korisno i za baze podataka.
I kako se ovo može sprijateljiti sa PostgreSQL-om? Prvo, velike stranice moraju biti omogućene u Linux kernelu.
Drugo, oni moraju biti eksplicitno specificirani parametrom sysctl - koliko ih ima. Ovdje su brojevi sa nekog starog servera. Možete izračunati koliko dijeljenih bafera imate tako da tu mogu stati ogromne stranice.
A ako je cijeli vaš server posvećen PostgreSQL-u, onda je dobra polazna tačka da dodijelite ili 25% RAM-a zajedničkim baferima ili 75% ako ste sigurni da će vaša baza podataka definitivno stati u ovih 75%. Početna tačka jedan. I uzmite u obzir, ako imate 256 GB RAM-a, onda ćete, shodno tome, imati 64 GB velikih bafera. Približno izračunajte s malo margine - na što treba postaviti ovu cifru.
Prije verzije 9.2 (ako se ne varam, od verzije 8.2) bilo je moguće povezati PostgreSQL sa ogromnim stranicama pomoću biblioteke treće strane. I to uvijek treba raditi. Prvo, potreban vam je kernel da biste mogli pravilno dodijeliti velike stranice. I, drugo, da ih aplikacija koja radi s njima može koristiti. Neće se koristiti samo na taj način. Pošto je PostgreSQL dodijelio memoriju u stilu sistema 5, to bi se moglo uraditi pomoću libhugetlbfs - ovo je puno ime biblioteke.
U verziji 9.3, poboljšane su performanse PostgreSQL-a kada se radi sa memorijom, a metod dodjeljivanja memorije sistema 5 je napušten. Svi su bili prezadovoljni, jer inače pokušate da pokrenete dve PostgreSQL instance na jednoj mašini, a on kaže da nemam dovoljno zajedničke memorije. I on kaže da sysctl treba ispraviti. I postoji takav sysctl da još uvijek trebate restartovati itd. Generalno, svi su bili sretni. Ali dodjela mmap memorije prekinula je korištenje ogromnih stranica. Većina naših klijenata koristi velike zajedničke bafere. I toplo smo preporučili da se ne prelazi na 9.3, jer su se tamo troškovi počeli računati u dobrim procentima.
Ali zajednica je obratila pažnju na ovaj problem i u 9.4 su vrlo dobro preradili ovaj događaj. A u 9.4 se pojavio parametar u postgresql.conf u kojem možete omogućiti pokušaj, uključen ili isključen.
Probajte je najsigurnija opcija. Kada se PostgreSQL pokrene, kada dodijeli zajedničku memoriju, on pokušava da zgrabi ovu memoriju sa ogromnih stranica. A ako ne uspije, onda se vraća na normalan odabir. A ako imate FreeBSD ili Solaris, onda možete pokušati, uvijek je sigurno.
Ako je uključeno, onda se jednostavno ne pokreće ako ne može birati sa ogromnih stranica. Ovdje je već riječ o tome ko je i šta je ljepše. Ali ako ste pokušali, onda provjerite da li zaista imate istaknuto ono što vam treba, jer ima puno prostora za greške. Trenutno ova funkcionalnost radi samo na Linuxu.
Još jedna mala napomena prije nego što krenemo dalje. Transparentne ogromne stranice još uvijek nisu o PostgreSQL-u. Ne može ih normalno koristiti. A sa Transparentnim ogromnim stranicama za takvo opterećenje, kada je potreban veliki dio 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 svakodnevnim aplikacijama, kada imate 32, 64, 128, 256 GB memorije na svom stroju, onda su uobičajene ogromne stranice Ok, a mi jednostavno onemogućimo Transparent.
I poslednja stvar u vezi sa pamćenjem nije direktno povezana sa voćem, može vam zaista uništiti život. Na svu propusnost uvelike će uticati činjenica da se server stalno mijenja.
I to će biti vrlo neugodno na više načina. A glavni problem je što se moderni kerneli ponašaju malo drugačije od starijih Linux kernela. A ova stvar je prilično neugodna za gaziti, jer kada govorimo o nekakvom radu sa swap-om, to se završava neblagovremenim dolaskom OOM-ubice. A OOM-killer, koji nije stigao na vrijeme i izbacio PostgreSQL, je neprijatan. Za ovo će svi znati, odnosno do posljednjeg korisnika.
Šta se dešava? Tamo imate veliku količinu RAM-a, sve radi dobro. Ali iz nekog razloga server visi u swap-u i zbog toga se usporava. Čini se da ima puno sjećanja, ali to se događa.
Ranije smo savjetovali da vm.swappiness postavite na nulu, tj. onemogućite swap. Ranije se činilo da je 32 GB RAM-a i odgovarajućih zajedničkih bafera ogroman iznos. Glavna svrha zamjene je da imamo mjesto za bacanje kore ako otpadnemo. I više nije bilo posebno ispunjeno. I šta ćeš onda sa ovom korom? Ovo je zadatak za koji nije baš jasno zašto je potreban swap, posebno takve veličine.
Ali u modernijim, tj. trećim verzijama kernela, ponašanje se promijenilo. A ako swap postavite na nulu, odnosno isključite ga, onda će vam prije ili kasnije, čak i ako ostane malo RAM-a, doći OOM killer da ubije najintenzivnije potrošače. Jer će smatrati da nam je sa takvim opterećenjem ostalo još malo pa ćemo iskočiti, tj. ne da zakucamo sistemski proces, nego da zakucamo nešto manje bitno. Ovaj manje važan će biti intenzivan potrošač zajedničke memorije, odnosno upravnik pošte. I nakon toga će biti dobro ako se baza ne mora obnavljati.
Dakle, sada je zadana postavka, koliko se sjećam, većina distribucija je negdje oko 6, odnosno u kojem trenutku treba početi koristiti swap ovisno o tome koliko je memorije ostalo. Sada preporučujemo postavljanje vm.swappiness = 1, jer ga to praktično isključuje, ali ne daje iste efekte kao kod OOM-killera koji je neočekivano stigao i ubio cijelu stvar.
Šta je sledeće? Kada govorimo o performansama baza podataka i postepeno prelazimo na diskove, svi počinju da se hvataju 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 sa performansama diska.
Glavni problem performansi PostgreSQL-a povezan sa skokovima kontrolnih tačaka se ne javlja jer je disk spor. To je najvjerovatnije zbog činjenice da memorijski i disk propusni opseg nisu izbalansirani. Međutim, oni možda neće biti uravnoteženi na različitim mjestima. PostgreSQL nije konfigurisan, OS nije konfigurisan, hardver nije konfigurisan i hardver je neispravan. I ovaj problem se ne događa samo ako se sve odvija kako treba, odnosno ili nema opterećenja, ili su postavke i hardver dobro odabrani.
Šta je to i kako izgleda? Obično su ljudi koji rade sa PostgreSQL-om ušli u ovu stvar više puta. Objasniću. Kao što sam rekao, PostgreSQL povremeno pravi kontrolne tačke da bi prljave stranice u zajedničkoj memoriji izbacili na disk. Ako imamo veliku količinu dijeljene memorije, onda kontrolna tačka počinje da ima intenzivan uticaj na disk, jer izbacuje ove stranice pomoću fsync-a. Dolazi u bafer kernela i zapisuje se na diskove pomoću fsync. A ako je obim ovog posla veliki, onda se može primijetiti neugodan efekat, odnosno vrlo velika iskorištenost diskova.
Evo imam dvije slike. Sad ću objasniti šta je to. Ovo su dva vremenski korelirana grafikona. Prvi grafikon je korištenje diska. Ovdje dostiže skoro 90% u ovom trenutku. Ako imate grešku u bazi podataka sa fizičkim diskovima, sa iskorišćenošću RAID kontrolera od 90%, onda je ovo loša vest. To znači da još malo i doći će do 100 i I/O će se zaustaviti.
Ako imate niz diskova, onda je to malo drugačija priča. Zavisi kako je konfigurisan, kakav je niz, itd.
Paralelno, ovdje je konfigurisan graf iz internog postgres pogleda, koji govori kako se kontrolna tačka javlja. A zelena boja ovdje pokazuje koliko je bafera, ovih prljavih stranica, u tom trenutku stiglo na ovu kontrolnu tačku radi sinhronizacije. A ovo je glavna stvar koju ovdje trebate znati. Vidimo da ovdje imamo puno stranica i u nekom trenutku smo udarili u ploču, odnosno pisali smo i pisali, ovdje je sistem diska očito veoma zauzet. A naša kontrolna tačka ima veoma jak uticaj na disk. U idealnom slučaju, situacija bi trebala izgledati ovako, tj. ovdje smo imali manje snimanja. I možemo to popraviti sa postavkama da i dalje bude ovako. Odnosno, reciklaža je mala, ali negdje ovdje nešto pišemo.
Šta je potrebno učiniti da se ovaj problem prevaziđe? Ako ste zaustavili IO pod bazom podataka, to znači da će svi korisnici koji su došli da ispune svoje zahtjeve čekati.
Ako gledate sa stajališta Linuxa, ako ste uzeli dobar hardver, ispravno ga konfigurirali, normalno konfigurirali PostgreSQL tako da čini ove kontrolne točke rjeđe, raširi ih tijekom vremena među sobom, onda ulazite u zadane Debian parametre. Za većinu Linux distribucija, ovo je slika: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Šta to znači? Jedan demon za ispiranje pojavio se iz kernela 2.6. Pdglush, ovisno ko koji koristi, koji se bavi pozadinskim odbacivanjem prljavih stranica iz bafera kernela i odbacivanjem kada je potrebno odbaciti prljave stranice bez obzira na sve, kada odbacivanje backgrouinda ne pomaže.
Kada dolazi pozadina? Kada je 10% ukupnog RAM-a dostupnog na serveru zauzeto prljavim stranicama u baferu kernela, u pozadini se poziva posebna funkcija otpisa. Zašto je to pozadina? Kao parametar uzima u obzir koliko stranica treba otpisati. I, recimo, otpisuje N stranica. I na neko vrijeme ova stvar zaspi. A onda opet dolazi i kopira još nekoliko stranica.
Ovo je krajnje jednostavna priča. Ovdje je problem kao kod bazena, kada se izlije u jednu cijev, prelije u drugu. Naša kontrolna tačka je stigla i ako je poslala nekoliko prljavih stranica na odbacivanje, onda će postepeno cijela stvar biti uredno riješena iz kernel buffera pgflush.
Ako te prljave stranice nastave da se gomilaju, akumuliraju se i do 20%, nakon čega je prioritet OS-a da se sve otpiše na disk, jer će nestati struja i sve će biti loše po nas. Izgubit ćemo te podatke, na primjer.
U čemu je trik? Trik je u tome što su ovi parametri u savremenom svetu 20 i 10% ukupne RAM memorije koja se nalazi na mašini, oni su apsolutno monstruozni u smislu propusnosti bilo kog disk sistema koji imate.
Zamislite da imate 128 GB RAM-a. 12,8 GB stiže na vaš disk sistem. I bez obzira koji keš imate tamo, bez obzira koji niz imate, oni neće trajati toliko dugo.
Stoga preporučujemo da odmah prilagodite ove brojeve na osnovu mogućnosti vašeg RAID kontrolera. Ovdje sam odmah dao preporuku za kontroler koji ima 512 MB keš memorije.
Sve se smatra veoma jednostavnim. Možete staviti vm.dirty_background u bajtove. I ove postavke poništavaju prethodna dva. Ili je omjer po defaultu, ili su oni sa bajtovima aktivirani, onda će oni sa bajtovima raditi. Ali pošto sam DBA konsultant i radim s različitim klijentima, pokušavam izvući slamke i stoga, ako u bajtovima, onda u bajtovima. Niko nije garantovao da dobar admin neće dodati više memorije serveru, ponovo ga pokrenuti, a cifra će ostati ista. Samo izračunajte ove brojke da sve stane uz garanciju.
Šta se dešava ako se ne uklopiš? Napisao sam da se svako crvenilo efektivno zaustavlja, ali to je zapravo figura govora. Operativni sistem ima veliki problem - ima puno prljavih stranica, tako da je IO koji vaši klijenti generišu efektivno zaustavljen, tj. aplikacija je došla da pošalje sql upit bazi podataka, čeka. Svaki ulaz/izlaz u njega ima najniži prioritet, jer je baza podataka zauzeta kontrolnom tač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 se ne završi, nećete ništa učiniti.
Ovdje postoje još dvije važne tačke koje su izvan okvira ovog izvještaja. Ove postavke treba da odgovaraju postavkama u postgresql.conf, tj. postavkama kontrolnih tačaka. I vaš disk sistem mora biti adekvatno konfigurisan. Ako imate keš memoriju na RAID-u, onda mora imati bateriju. Ljudi kupuju RAID sa dobrom keš memorijom bez baterije. Ako imate SSD-ove u RAID-u, onda oni moraju biti serverski, tamo moraju biti kondenzatori. Evo detaljne kontrolne liste. Ova veza sadrži moj izvještaj o tome kako konfigurirati disk performansi u PostgreSQL-u. Tamo su sve te kontrolne liste.
Šta još može otežati život? Ovo su dva parametra. Relativno su novi. Podrazumevano, oni se mogu uključiti u različite aplikacije. I mogu jednako otežati život ako su pogrešno uključeni.
Postoje dvije 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 ti uništavaju život? Šta 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 je potpuno nejasna. Sa stanovišta operativnog sistema, kada prebacite prozore između openoffice-a i terminala, ovo može biti dobro, ali za bazu podataka ovo je jako loše. Stoga je razumna politika postaviti migration_cost na neku veliku vrijednost, najmanje nekoliko hiljada nanosekundi.
Šta će to značiti za planer? Smatrat će se da je za to vrijeme proces još vruć. To jest, ako imate dugotrajnu transakciju koja je nešto radila duže vrijeme, planer će to razumjeti. On će pretpostaviti da dok ovaj timeout ne prođe, nema potrebe da se nigdje migrira ovaj proces. Ako u isto vrijeme proces nešto radi, onda neće biti nikamo migriran, tiho će raditi na CPU-u koji mu je dodijeljen. I rezultat je odličan.
Druga tačka je autogroup. Postoji dobra ideja za specifična radna opterećenja koja nisu povezana sa modernim bazama podataka - to je grupisanje procesa po virtuelnom terminalu sa kojeg se pokreću. Ovo je zgodno za neke zadatke. U praksi, PostgreSQL je višeprocesni sistem sa preforkom koji se pokreće sa jednog terminala. Imate program za pisanje zaključavanja, kontrolnu tačku i svi vaši zahtjevi klijenta će biti grupisani u jedan planer, po CPU-u. I tamo će složno čekati da se oslobodi, kako bi se jedni drugima ometali i duže ga zaokupljali. Ovo je priča koja je potpuno nepotrebna u slučaju ovakvog opterećenja i zato je treba isključiti.
Moj kolega Alexey Lesovsky radio je testove sa jednostavnim pgbench-om, gdje je povećao migration_cost za red veličine i isključio autogroup. Razlika na lošem hardveru bila je skoro 10%. Postoji diskusija na postgres mailing listi gdje ljudi daju rezultate sličnih promjena brzine upita utjecao na 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 laptopu. I navodno će dobro potrošiti bateriju. Ali odjednom se ispostavi da se to može dogoditi i na serveru.
Štaviše, ako iznajmljujete servere od nekog hostera, onda „dobrim“ hosterima nije stalo da imate bolje performanse. Njihov zadatak je da obezbede da se njihovo gvožđe iskoristi što efikasnije. Stoga, prema zadanim postavkama, oni mogu omogućiti režim uštede energije laptopa na operativnom sistemu.
Ako koristite ove stvari na serveru sa bazom podataka pod velikim opterećenjem, onda je vaš izbor acpi_cpufreq + permormance. Čak i sa zahtjevom će biti problema.
Intel_pstate je malo drugačiji drajver. I sada se prednost daje ovom, jer je kasnije i bolje radi.
I, shodno tome, guverner je samo učinak. Ondemand, powersave i sve ostalo nisu o vama.
Rezultati objašnjenja analize PostgreSQL-a mogu se razlikovati za nekoliko redova veličine ako omogućite uštedu energije, jer će praktično CPU u vašoj bazi podataka raditi na potpuno nepredvidiv način.
Ove stavke mogu biti uključene po defaultu. Pažljivo pogledajte da li su ga uključili prema zadanim postavkama. Ovo može biti zaista veliki problem.
I na kraju, želio sam da se zahvalim momcima iz našeg PosgreSQL-Consulting DBA tima, odnosno Max Boguk i Alexey Lesovsky, koji svakim danom napreduju u ovoj stvari. I trudimo se da učinimo najbolje što možemo za naše klijente kako bi im sve uspjelo. To je kao s uputama za sigurnost u zrakoplovstvu. Sve je ovde napisano krvlju. Svaki od ovih orašastih plodova nalazi se u procesu neke vrste problema. Drago mi je da ih podijelim s vama.
Pitanja:
Hvala ti! Ako, na primjer, kompanija želi uštedjeti novac i smjestiti bazu podataka i logiku aplikacije na jedan server, ili ako kompanija slijedi moderan trend mikroservisnih arhitektura, u kojima PostgreSQL radi u kontejneru. U čemu je trik? Sysctl će utjecati na cijeli kernel globalno. Nisam čuo da su sysctl-ovi nekako virtuelizirani tako da rade odvojeno na kontejneru. Postoji samo cgroup i tamo postoji samo dio kontrole. Kako možeš da živiš sa ovim? Ili ako želite performanse, onda pokrenite PostgreSQL na zasebnom hardverskom serveru i podesite ga?
Odgovorili smo na vaše pitanje na otprilike tri načina. Ako ne govorimo o hardverskom serveru koji se može podesiti itd., onda se opustite, sve će raditi dobro i bez ovih postavki. Ako imate takvo opterećenje da trebate napraviti ove postavke, onda ćete prije doći do željeznog servera nego do ovih postavki.
Šta je problem? Ako je ovo virtualna mašina, onda ćete najvjerovatnije 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 neuspješna I/O transakcija koja ne utječe mnogo na prosječnu propusnost koja se dogodila u vrijeme kontrolne tačke ili u vrijeme pisanja u WAL, onda će baza podataka uvelike patiti od toga. I to ćete primijetiti prije nego što naiđete na ove probleme.
Ako imate NGINX na istom serveru, također ćete imati isti problem. Boriće se za zajedničku uspomenu. I nećete doći do ovdje opisanih problema.
Ali s druge strane, neki od ovih parametara će i dalje biti relevantni za vas. Na primjer, postavite dirty_ratio sa sysctl-om da ne bude tako ludo - u svakom slučaju, ovo će pomoći. Na ovaj ili onaj način, imat ćete interakciju s diskom. I to će biti po pogrešnom obrascu. Ovo je općenito zadana postavka za parametre koje sam pokazao. I u svakom slučaju ih je bolje promijeniti.
Ali može biti problema sa NUMA-om. VmWare, na primjer, dobro radi sa NUMA sa potpuno suprotnim postavkama. I ovdje morate odabrati - željezni server ili server bez željeza.
Imam pitanje vezano za Amazon AWS. Imaju unapred konfigurisane slike. Jedan od njih se zove Amazon RDS. Postoje li prilagođene postavke za njihov operativni sistem?
Postoje podešavanja, ali to su različite postavke. Ovdje konfiguriramo operativni sistem u smislu kako će baza podataka koristiti ovu stvar. I postoje parametri koji određuju kuda sada treba da idemo, kao što je oblikovanje. Odnosno, potrebno nam je toliko resursa, sada ćemo ih pojesti. Nakon toga, Amazon RDS pooštrava ove resurse, a performanse tu opadaju. Postoje pojedinačne priče o tome kako ljudi počinju da se petljaju po ovom pitanju. Ponekad čak i prilično uspješno. Ali ovo nema nikakve veze sa postavkama OS-a. To je kao hakovanje oblaka. To je druga priča.
Zašto Transparentne ogromne stranice nemaju efekta u poređenju sa Ogromnim TLB-om?
Ne daj. Ovo se može objasniti na mnogo načina. Ali u stvari to jednostavno ne daju. Kakva je istorija PostgreSQL-a? Prilikom pokretanja, dodjeljuje veliki dio zajedničke memorije. Potpuno je nebitno da li su transparentne ili ne. Činjenica da se ističu na početku sve objašnjava. A ako ima puno memorije i trebate ponovo izgraditi segment shared_memory, tada će Transparentne ogromne stranice biti relevantne. U PostgreSQL-u se jednostavno dodjeljuje u ogromnom komadu na početku i to je to, a onda se tu ne događa ništa posebno. Možete ga, naravno, koristiti, ali postoji šansa da dobijete oštećenje shared_memory kada nešto ponovo dodijeli. PostgreSQL ne zna za ovo.
izvor: www.habr.com