Linux podešavanje za poboljšanje performansi PostgreSQL-a. Ilja Kosmodemjanski

Prezentacija iz 2015. godine Ilje Kosmodemjanskog "Linux podešavanje za poboljšanje performansi PostgreSQL-a"

Odricanje: Napominjem da je ova prezentacija datirana novembrom 2015. godine — prošlo je više od 4 godine i mnogo se toga promenilo. Verzija 9.4 koja se razmatra u prezentaciji više nije podržana. Tokom protekle 4 godine objavljeno je 5 novih verzija PostgreSQL-a i 15 verzija Linux jezgra. Ako bismo prepisali ova mesta, to bi u konačnici postala druga prezentacija. No, ovde je razmatrano osnovno podešavanje Linux-a za PostgreSQL koje je i dalje aktuelno.

Zovem se Ilja Kosmodemjanski. Radim u kompaniji PostgreSQL-Consulting. Sada ću malo pričati o tome šta raditi sa Linux-om u vezi sa bazama podataka uopšte i sa PostgreSQL-om posebno, jer su principi prilično slični.

O čemu ćemo govoriti? Ako komunicirate sa PostgreSQL-om, do određene mere morate biti UNIX administrator. Šta to znači? Ako uporedimo Oracle i PostgreSQL, u Oracle-u morate biti 80 % DBA administrator baze podataka i 20 % administrator Linux-a.

Sa PostgreSQL-om je malo složenije. Sa PostgreSQL-om treba mnogo bolje razumeti kako Linux funkcioniše. I pritom treba malo juriti za vozom, jer se u poslednje vreme sve prilično brzo ažurira. Na izlaz novog jezgra, novi funkcionalnosti se pojavljuju, performanse se poboljšavaju itd.

Zašto govorimo o Linux-u? Ne zato što smo na Linux konferenciji u Peterburgu, već zato što je u savremenim uslovima jedan od najprikladnijih operativnih sistema za rad sa bazama podataka uopšte, a posebno sa PostgreSQL-om – to je Linux. Nažalost, FreeBSD se razvija u prilično čudnom pravcu. I imat ćemo problema i sa performansama i sa mnogim drugim stvarima. Performanse PostgreSQL-a na Windows-u – to je uopšte posebna tema koja se suočava s tim što Windows nema zajedničku memoriju kao UNIX, a kod PostgreSQL-a se sve oslanja na to, jer je to višepostupkovni sistem.

I egzotika poput Solaris-a, mislim da zanima manje ljudi, zato idemo dalje.

Savremeni Linux distribucijski sistem ima više od 1,000 syctl parametara, zavisno od načina na koji je jezgro sastavljeno. Pritom, ako pogledamo još različite stvari, možemo na mnogo načina dodatno prilagoditi. Postoje parametri datotečnih sistema, kako ih montirati. Ako imate pitanja, kako pokrenuti: šta uključiti u BIOS-u, kako postaviti opremu itd.

Ovo je vrlo velik volumen koji se može objašnjavati nekoliko dana, a ne u jednom kratkom izlaganju, ali ću se sada usredotočiti na važne stvari, kako izbjeći one zamke koje će vam sigurno onemogućiti dobru eksploataciju baze podataka na Linuxu, ako ih ne ispravite. Istovremeno, važna stvar je da su mnogi parametri po defaultu uključeni u postavke koje nisu ispravne za bazu podataka. Drugim riječima, prema zadanim postavkama će raditi loše ili uopće neće raditi.

Koji su tradicionalni ciljevi optimizacije u Linuxu? Mislim da, s obzirom na to da se svi bavite administracijom Linuxa, ne treba posebno objašnjavati što su ciljevi.

Možete optimizirati:

• CPU.
• Memoriju.
• Skladište.
• Ostalo. O tome ćemo razgovarati na kraju kao poslastica. Čak i, na primjer, takvi parametri kao što su politike uštede energije mogu na vrlo nepredvidljiv i neugodan način utjecati na performanse.

Kakva je specifičnost PostgreSQL-a i općenito baza podataka? Problem je u tome što ne možete optimizirati neku pojedinačnu stvar i očekivati da će se performanse značajno poboljšati.

Da, takvih stvari ima, ali baza podataka je složena. Ona komunicira sa svim resursima koje server ima i preferira punu interakciju. Ako pogledate moderne preporuke Oracle-a o tome kako koristiti host OS, to će biti poput viceva o onom mongolskom astronautu – nahranite psa i ne dirajte ništa. Pružit ćemo bazi sve resurse, baza podataka će se sama snaći.

U načelu, do neke mjere s PostgreSQL-om situacija je identična. Razlika je u tome što baza ne može sama preuzeti sve resurse, tj. negdje je potrebno sve to samostalno razraditi na razini Linuxa.

Osnovna ideja je ne odabrati neki pojedinačni cilj i početi ga optimizirati, primjerice, memoriju, CPU ili nešto slično, već analizirati radno opterećenje i pokušati maksimalno poboljšati propusnost, kako bi kroz našu bazu podataka što učinkovitije prolazilo opterećenje koje su nam stvorili dobri programeri, uključujući i naše korisnike.

Ovo je slika koja objašnjava što točno jest. Tu je Linux OS bafer, tu je dijeljena memorija i dijeljeni baferi PostgreSQL-a. PostgreSQL, za razliku od Oracla, radi isključivo preko bafera jezgre, tj. da bi stranica s diska ušla u njegovu dijeljenu memoriju, mora proći kroz kernel bafer i natrag, situacija je ista.

Pod ovim sustavom nalaze se diskovi. To sam nacrtao kao diskove. U stvarnosti tu može biti RAID kontroler itd.

Taj ulaz-izlaz se s jedne ili druge strane događa kroz to.

PostgreSQL je klasična baza podataka. Unutra su stranice. Sav ulaz-izlaz odvija se pomoću stranica. Mi učitavamo blokove u memoriju pomoću stranica. Ako se ništa nije dogodilo, samo smo ih pročitali, tada postupno tonu iz tog keša, iz dijeljenih bafera, i vraćaju se natrag na disk.

Ako smo negdje nešto zamijenili, cijela stranica se označava kao prljava. Obojio sam ih ovdje plavom bojom. To znači da se ta stranica mora sinkronizirati s blokovnim spremištem. Dakle, kada smo je učinili prljavom, napravili smo zapis u WAL-u. I u nekom trenutku došlo je do fenomena nazvanog checkpoint. U taj log upisana je informacija da je došao. To znači da su sve prljave stranice koje su u tom trenutku bile u tim dijeljenim baferima sinkronizirane s diskom pomoću fsync-a kroz kernel bafer.

Zašto se to radi? Ako nam nestane struje, ne želimo situaciju u kojoj su svi podaci nestali. Perzistentna memorija, o kojoj su nam svi pričali, trenutno je teorija baza podataka — to je svijetla budućnost kojoj težimo i sviđa nam se, ali trenutno je to još uvijek 20 godina unazad. I, naravno, potrebno je sve to pratiti.

Cilj maksimiziranja propusnosti jest optimizirati na svim tim fazama kako bi sve to brzo putovalo naprijed-natrag. Dijeljena memorija je uglavnom stranicni keš. U PostgreSQL-u smo poslali select upit, on je izvukao te podatke s diska. Ti podaci su ušli u dijeljene baferi. Stoga, kako bi to bolje radilo, potrebno je imati puno memorije.

Kako bi sve to radilo dobro i brzo, morate ispravno konfigurirati operacijski sustav na svim razinama. Također, potrebno je odabrati uravnotežen hardver, jer ako bude neravnoteže negdje, možete imati puno memorije, ali će se njome služiti nedovoljnom brzinom.

Proći ćemo kroz svaki od ovih točaka.

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

• Prvo, trebate učinkovitije raditi s memorijom.
• Drugim riječima, ovaj prijelaz, kada stranice iz memorije prelaze na disk, treba biti učinkovitiji.
• I, treće, trebaju biti dobri diskovi.

Ako imate 512 GB radne memorije u serveru i sve to na kraju dolazi na SATA tvrdi disk bez ikakvog keša, tada cijeli vaš poslužitelj baze podataka postaje ne samo bundeva, već bundeva s SATA sučeljem. Direktno ćete se suočiti s tim problemom. Ništa vas neće spasiti.

Što se tiče prvog aspekta s memorijom, postoje tri stvari koje mogu značajno otežati život.

Prva od njih je NUMA. NUMA je stvorena da poboljša performanse. Ovisno o opterećenju, možete optimizirati različite stvari. U njenom novom obliku, nije baš najbolja za aplikacije poput baze podataka koje intenzivno koriste dijeljeni predmemorijski sloj.

Ukratko, kako prepoznati da nešto nije u redu s NUMA? Imate neki neugodan zvuk, iznenada jedan od CPU-a izgleda preopterećen. Dok analizirate upite u PostgreSQL-u, vidite da ništa slično tome ne postoji. Ti upiti ne bi trebali toliko intenzivno opterećivati CPU. Ovo možete dugo uhvatiti. Lakše je od samog početka primijeniti ispravne preporuke za konfiguraciju NUMA za PostgreSQL.

Što se zapravo događa? NUMA – to je Non-Uniform Memory Access. Čemu to služi? Imate CPU, uz njega se nalazi njegova lokalna memorija. A ta memorija može povlačiti memoriju s drugih CPU-a preko međuspojnica.

Ako pokrenete numactl --hardware, dobit ćete veliku listu. Među ostalim, bit će tu polje udaljenosti. Bit će brojevi – 10-20, nešto slično tome. Ti brojevi predstavljaju broj skokova potrebnih za povlačenje te udaljene memorije za lokalnu upotrebu. U principu, dobra ideja. To značajno poboljšava performanse kod određenih opterećenja.

Zamislite sada da imate jedan CPU koji prvo pokušava koristiti svoju lokalnu memoriju, a zatim pokušava povući drugu memoriju preko interconnecta za nešto. I na taj CPU dolazi cijeli vaš page cache PostgreSQL – sve, nekoliko gigabajta. Uvijek dobijate najgori slučaj jer CPU u ovom modulu memorije obično ima malo prostora. A cijela memorija koja se koristi prolazi kroz te interconnecte. Postaje sporo i žalosno. Imate procesor koji neprekidno opservira ovaj čvor, stalno je preopterećen. A vrijeme pristupa toj memoriji je loše, sporo. Ova situacija je ono što ne želite kada koristite ovo za bazu podataka.

Stoga je ispravnija opcija za bazu podataka da operacijski sustav Linux uopće ne zna što se događa. Da se obraća memoriji onako kako se obraća.

Zašto je to tako? Činilo bi se da bi trebalo biti obrnuto. To se događa iz jednog jednostavnog razloga, jer nam treba puno memorije za page cache – desetci, stotine gigabajta.

I ako smo sve to izdvojili i skastali naše podatke tamo, dobit od korištenja cache-a će biti značajno veća nego dobit od takvog pametnog pristupa memoriji. Na ovaj način ćemo ostvariti dobit koja nije usporediva u odnosu na to da ćemo učinkovitije pristupati memoriji koristeći NUMA.

Dakle, postoji dva pristupa do sada, sve dok svijetla budućnost ne dođe, i baza podataka ne zna sama na kojim CPU-ima se nalaze i odakle joj nešto treba povući.

Pravi pristup je potpuno isključiti NUMA, na primjer, pri ponovnom pokretanju. U većini slučajeva dobitak je toliko velik da se ne postavlja pitanje koja je bolja opcija.

Postoji još jedna opcija. Otužni smo je više nego prvu, jer kada nam klijent dođe na podršku, ponovno pokretanje servera za njega je veliki posao. Njegov poslovanje se odvija. A problemi zbog NUMA su im poznati. Stoga se trudimo isključiti je manje invazivnim načinima, nego rebootom, ali ovdje budite pažljivi i provjerite da je zaista isključena. Jer, kako iskustvo pokazuje, kada isključujemo NUMA na roditeljskom procesu PostgreSQL-a, to je dobro, ali to nije nužno jamstvo da će to funkcionirati. Mora se provjeriti i vidjeti da je zaista isključena.

Post koji je napisao Robert Haas je izvrstan. On je jedan od committera PostgreSQL-a. Ključni je developer svih niskonivoznih elemenata. I ako se prođe kroz linkove u ovom postu, opisane su neke zanimljive priče o tome kako su ljudima NUMA otežavali život. Pogledajte, proučite popis koji treba postaviti na serveru kako bi naša baza podataka dobro radila. Ove postavke treba zabilježiti i provjeravati, jer u suprotnom neće biti dobro.

Skrećem pažnju da se ovo odnosi na sve postavke o kojima ću govoriti. Obično se baze podataka organiziraju u načinu master-slave radi otpornosti na kvarove. Ne zaboravite unijeti ove postavke na slave, jer će u jednom trenutku doći do kvara, a vi ćete se prebaciti na slave koji će postati master.

U hitnoj situaciji, kada je stanje kritično, kada vam neprestano zvoni telefon i kada šef dolazi s velikom palicom, nećete imati vremena razmišljati o provjeri. A rezultati mogu biti vrlo nepovoljni.

Sljedeća tema su huge pages. Teže ih je testirati posebno, a ni nema smisla to raditi, iako postoje benchmarkovi koji to mogu. Lako se nalaze na internetu.

Koji je smisao? Imate server koji nije preskup a sadrži puno radne memorije, na primjer, više od 30 GB. Ne koristite huge pages. To znači da imate jasno preopterećenje u korištenju memorije. A to preopterećenje nije nimalo ugodno.

Zašto je to tako? Što se događa? Operativni sustav se sjeća memorije u malim dijelovima. To je zgodno, tako je historijski započelo. Ako uđemo u detalje, OS mora pretvarati virtualne adrese u fizičke. I to nije najjednostavniji proces, stoga OS rezultat te operacije pohranjuje u Translation Lookaside Buffer (TLB).

I s obzirom na to da je TLB cache, u toj situaciji nastaju svi problemi koje cache ima. Prvo, ako imate jako puno radne memorije koja je podijeljena u sitne dijelove, taj buffer postaje jako velik. A ako je cache velik, pretraživanje postaje sporije. Preopterećenje je značajno i ono samo zauzima prostor, tj. nešto neprikladno koristi radnu memoriju.

Dva – što više cache raste u takvoj situaciji, to je veća vjerojatnost da ćete imati cache misses. I učinkovitost ovog cachea brzo pada s rastećom veličinom. Stoga su operativni sustavi smislili jednostavan pristup. U Linuxu se to već dugo koristi. U FreeBSD-u se nedavno pojavilo. Ali govorimo o Linuxu. To su huge pages.

I ovdje treba napomenuti da su huge pages, kao ideja, prvotno promovirali zajednice koje su uključivale Oracle i IBM, tj. proizvođači baza podataka su ozbiljno razmišljali o tome kako će ovo koristiti, uključujući baze podataka.

Kako to povezati s PostgreSQL-om? Prvo, u Linux jezgru moraju biti uključene huge pages.

Drugo, moraju biti izričito navedene sysctl parametrom – koliko ih ima. Brojevi ovdje dolaze s nekog starog servera. Možete izračunati koliko vam otprilike treba shared buffers kako bi huge pages stale unutra.

I ako je cijeli server dodijeljen PostgreSQL-u, dobra polazna točka je ili 25 % RAM-a dodijeliti za shared buffers, ili 75 %, ako ste sigurni da će vaša baza podataka sigurno stati u tih 75 %. Ovo je prva polazna točka. I izračunajte, ako imate 256 GB RAM-a, tada će vam otprilike 64 GB biti za shared buffers. Izračunajte s nekim marginama – koliko bi ta brojka trebala biti.

Do verzije 9.2 (ako se ne varam, od verzije 8.2) mogla se koristiti vanjska biblioteka za povezivanje PostgreSQL-a s huge pages. A to se uvijek treba raditi. Prvo, trebate da jezgro ispravno alocira huge pages. A drugo, aplikacija koja radi s njima mora moći iskoristiti te strane. Samo tako neće moći. Budući da je PostgreSQL alocirao memoriju u stilu system 5, to se moglo učiniti pomoću libhugetlbfs — to je potpuno ime biblioteke.

U verziji 9.3 poboljšana je izvedba PostgreSQL pri upravljanju memorijom i odustalo se od system 5 metode alokacije memorije. Svi su se jako obradovali, jer, inače, kada pokušate pokrenuti dva instanca PostgreSQL na jednoj mašini, on kaže da mu nedostaje šerirane memorije. I zahtijeva da se ispravi sysctl. A taj sysctl je takav da treba ponovo pokrenuti sistem i tako dalje. Uglavnom, svi su se obradovali. No, alokacija memorije preko mmap-a je pokvarila korištenje ogromnih stranica. Većina naših klijenata koristi velike šerirane baferove. I snažno smo preporučili da se ne prelazi na 9.3, jer je tamo overhead počinjao u dobrim postotcima biti značajan.

Ali, zajednica je obratila pažnju na ovaj problem i u 9.4 su vrlo dobro preradili ovo rješenje. I u 9.4 je uvedena opcija u postgresql.conf, gdje se može uključiti try, on ili off.

Try je najbezbednija opcija. Prilikom pokretanja PostgreSQL-a, kada alocira šeriranu memoriju, pokušava da dobije tu memoriju iz ogromnih stranica. I ako ne uspe, vraća se na uobičajenu alokaciju. I ako koristite FreeBSD ili Solaris, možete postaviti try, to je uvek sigurno.

Ako je on, jednostavno se ne pokreće ako nije uspeo da alocira iz ogromnih stranica. Ovo je već isključivo stvar izbora. Ali ako imate try, proverite da li ste zaista alocirali ono što vam treba, jer postoji puno prostora za greške. Trenutno, ova funkcionalnost radi samo na Linuxu.

Još jedna mala napomena pre nego što pređemo dalje. Transparentne ogromne stranice još uvek nisu u PostgreSQL-u. Ne može ih pravilno iskoristiti. I pri transparentnim ogromnim stranicama, u situacijama gde je potreban veliki deo šerirane memorije, prednosti se javljaju samo pri veoma velikim količinama. Ako imate terabajte memorije, tada to može igrati ulogu. Kada govorimo o uobičajenim primenama, kada imate 32, 64, 128, 256 GB memorije na mašini, tada su obične ogromne stranice u redu, a transparentne jednostavno isključujemo.

I zadnja stvar koja se tiče memorije, nije direktno povezana sa propusnošću, ali može jako zakomplikovati život. Cela propusnost će jako stradati zbog toga što server stalno prelazi u swap.

I to će biti vrlo neugodno u nizu situacija. Glavna neugodnost leži u tome što se ponašanje modernih jezgri malo razlikuje od starijih Linux jezgri. Ovo je nešto na što je neugodno naletjeti, jer kada govorimo o radu sa swapom, završava to s nepravovremenim dolaskom OOM-killera. A OOM-killer koji nije stigao na vrijeme i skinuo PostgreSQL, to je neprijatno. O tome će svi saznati, tj. do posljednjeg korisnika.

Što se događa? Imate puno RAM-a, sve dobro funkcionira. No, iz nekog razloga, server se zamrzava u swapu i time usporava. Naizgled, ima dovoljno memorije, ali tako se događa.

Ranije smo savjetovali da se vm.swappiness postavi na nulu, tj. da se isključi swap. Nekada se smatralo da 32 GB RAM-a i odgovarajući shared bufferi predstavljaju ogromnu količinu. Osnovna svrha swap-a je da bude mjesto gdje možete smjestiti koru ako ispadnete. No, to više nije bila posebno ostvarena svrha. A što ćete kasnije napraviti s tom korom? To postaje pitanje koje ne objašnjava jasno zašto je swap uopće potreban, pogotovo u toj veličini.

No, u modernijim, tj. trećim verzijama jezgri, ponašanje se promijenilo. Ako isključite swap, tj. postavite ga na nulu, pre ili kasnije, čak i uz preostalu količinu RAM-a, OOM-killer će doći da ubije najintenzivnije potrošače. Jer će smatrati da uz takvo opterećenje imamo još malo raspoložive memorije i da ćemo pasti, tj. neće ubiti sistemski proces, već nešto manje važno. To će manje važno biti intenzivni potrošač shared memorije, to jest postmaster. Nakon toga, bit će dobro ako bazu nećete morati obnavljati.

Zato sada, koliko se sjećam, većina distribucija postavlja podrazumijevano na oko 6, tj. u kojem trenutku početi koristiti swap ovisno o tome koliko je memorije preostalo. Sada savjetujemo da se postavi vm.swappiness = 1, jer to praktički isključuje swap, ali ne dovodi do takvih efekata kao s nepredviđenim dolaskom OOM-killera koji sve to ubija.

Što dalje? Kada govorimo o performansama baza podataka i polako se približavamo diskovima, svi se hvataju za glavu. Jer istina da je disk spor, a memorija brza, svima je poznata od malih nogu. Svi znaju da će u bazi podataka biti problema s diskovnom performansom.

Glavni problem s performansama PostgreSQL, povezan s uzletima checkpoints-a, ne nastaje zbog sporosti diska. Umjesto toga, dolazi do nerazmjernosti između propusnosti memorije i diska. Ova nerazmjernost može se javljati na različitim mjestima. PostgreSQL nije pravilno podešen, operativni sustav nije podešen, hardver nije postavljen i hardver nije ispravan. Ovaj problem se ne javlja samo kada se sve odvija ispravno, tj. ili nema opterećenja, ili su postavke i hardver dobro odabrani.

Što je to i kako to izgleda? Obično, ljudi koji rade s PostgreSQL-om više puta su se suočili s tim problemom. Objasnit ću. Kao što sam rekao, PostgreSQL povremeno pravi checkpoints kako bi prljave stranice u zajedničkoj memoriji prenio na disk. Ako imamo veliki kapacitet zajedničke memorije, checkpoint počinje intenzivno utjecati na disk, jer zapisuje te stranice putem fsync-a. Dolazi u kernel buffer i zapisuje se na diskove uz pomoć fsync-a. I ako je kapacitet ovog procesa velik, možemo primijetiti neugodan učinak, to jest, vrlo visoku iskorištenost diskova.

Ovdje imam dvije slike. Sada ću objasniti što je to. To su dva vremenski korelirana grafikona. Prvi grafikon prikazuje diskovnu iskorištenost. Ovdje doseže gotovo 90% u tom trenutku. Ako imate opterećenje baze podataka s fizičkim diskovima, s RAID kontrolerom, i iskorištenost je pod 90%, to su loše vijesti. To znači da će uskoro doći do 100% i ulaz-izlaz će se zaustaviti.

Ako imate diskovni niz, tada je priča malo drugačija. Ovisi o tome kako je podešen, o kojoj se vrsti niza radi itd.

A ovdje je paralelno konfiguriran grafikon iz unutarnje postgresove prikaze koja pokazuje kako se odvija checkpoint. I zelenom bojom ovdje je prikazano koliko je buffera, ovih prljavih stranica, u tom trenutku stiglo u ovaj checkpoint za sinkronizaciju. To je najvažnije što ovdje trebate znati. Vidimo da imamo mnogo stranica koje su stigle i u nekom trenutku naletjeli smo na ograničenje, tj. pisanje je trajalo dugo, ovdje je očito diskovni sustav vrlo zauzet. I naš checkpoint snažno utječe na disk. U idealnom slučaju situacija bi trebala izgledati ovako, tj. manje pisanja bi se odvijalo ovdje. A mi to možemo ispraviti postavkama kako bismo tako nastavili. Tj. mala iskorištenost, ali negdje ipak nešto pišemo.

Što trebate učiniti kako biste pobijedili ovaj problem? Ako je IO pod bazom podataka stalo, to znači da će svi korisnici koji su došli izvršavati svoje upite čekati.

Ako pogledamo iz perspektive Linuxa, ako ste nabavili dobar hardver, pravilno ga konfigurirali i ispravno podesili PostgreSQL kako bi rjeđe radio ove checkpointove, šireći ih međusobno po vremenu, onda ćete se naći u zadanim parametrima Debiana. Za većinu Linux distribucija ovakva je slika: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Što to znači? S jezgre 2.6 pojavio se jedan demon za ispiranje. Pdglush ovisno o tome tko ga koristi, bavi se pozadinskim ispuštanjem prljavih stranica iz kernel buffera i ispuštanjem, kada god je to potrebno, prljavih stranica kada već pozadinsko ispuštanje ne pomaže.

Kada dolazi do pozadine? Kada je 10 % od cijelog operativnog pamćenja koje je dostupno na serveru zauzeto prljavim stranicama u kernel buffera, poziva se posebna funkcija za ispuštanje u pozadini. Zašto je ona pozadinska? Kao parametar prihvaća koliko stranica ispuštati. I, recimo, ispušta N stranica. Na neko vrijeme ta stvar zaspi. A onda se ponovno pojavljuje i ispušta još određeni broj stranica.

Ovo je izuzetno jednostavna priča. Ovdje je zadaća poput bazena, kada se u jednu cijev izlijeva, a u drugu ulijeva. Naš checkpoint je stigao i ako je poslao malo prljavih stranica na ispuštanje, postepeno će se iz kernel buffera pgflush sve to uredno razdvojiti.

Ako se ove prljave stranice nastave nakupljati, nakupljat će se do 20%, a nakon toga će operativni sustav prioritizirati preslikavanje na disk, jer će doći do gubitka napajanja, a sve će biti loše. Izgubit ćemo te podatke, primjerice.

Koja je caka? Caka je u tome da su ovi parametri u modernom svijetu 20 i 10% od ukupne memorije koja postoji na računalu, jednostavno monstruozni s gledišta propusnosti bilo kojeg diska koji imate.

Zamislite da imate 128 GB radne memorije. 12,8 GB dolazi u vaš sustav za pohranu. I bez obzira na to kakav imate predmemorijski sustav ili polje, oni to neće izdržati.

Stoga preporučujemo odmah prilagoditi ove brojke prema mogućnostima vašeg RAID kontrolera. Odmah imam preporuku za kontroler s 512 MB predmemorije.

Sve se vrlo jednostavno računa. Možete postaviti vm.dirty_background u bajtima. I ove postavke poništavaju prethodne dvije. Bilo omjer prema zadanim postavkama ili aktivirani oni s bajtima, radit će oni s bajtima. Ali budući da sam DBA konzultant i radim s različitim klijentima, pokušavam se osigurati, pa ako su u bajtima, neka budu u bajtima. Nitko nije dao nikakvo jamstvo da dobar administrator neće dodati memoriju serveru, restartovati ga, a brojka će ostati ista. Samo izračunajte te brojke da sigurno sve stane unutra.

Što će se dogoditi ako ne stane? Imam zapisano da se bilo kakvo ispuštanje učinkovito zaustavlja, ali zapravo je to samo fraza. Operativni sustav ima veliki problem – ima mnogo prljavih stranica, stoga učinkovito se zaustavlja ono ulaz/izlaz koje generiraju vaši klijenti, tj. aplikacija koja je poslala sql upit prema bazi, čeka. Bilo koji ulaz/izlaz u nju ima najniži prioritet, jer je baza zauzeta checkpointom. I kada će ga završiti nije jasno. Kada ste postigli ne pozadinsko ispuštanje, to znači da je sav IO zauzet njime. I dok se to ne završi, nećete moći ništa učiniti.

Tamo su još dva važna trenutka koja nadmašuju ovu prezentaciju. Ove postavke trebaju odgovarati postavkama u postgresql.conf, tj. postavkama checkpointa. A vaš sustav za pohranu mora biti adekvatno konfiguriran. Ako imate cache na RAID-u, tada bi trebao imati bateriju. Ljudi kupuju RAID s dobrim cache-om bez baterije. Ako imate SSD u RAID-u, oni moraju biti serverni, trebali bi imati kondenzatore. Ovdje je opširna kontrolna lista. Na ovoj poveznici nalazi se moje izlaganje o tome kako podešavati performanse diska u PostgreSQL-u. Sve te kontrolne liste su tamo.

Što još može ozbiljno zakomplicirati situaciju? To su dva parametra. Oni su relativno novi. Po defaultu mogu biti uključeni u različitim aplikacijama. I mogu zakomplicirati život jednako jako, ako su pogrešno uključeni.

Postoje dvije relativno nove stvari. Već su se pojavile u trećim jezgrama. To su sched_migration_cost u nanosekundama i sched_autogroup_enabled, koji je po defaultu samo jedan.

Kako to kvare život? Što je sched_migration_cost? Linux scheduler može migrirati proces s jednog CPU-a na drugi. I za PostgreSQL, koji izvršava upite, migracija na drugi CPU potpuno je nejasna. S stanovišta operativnog sustava, kada prebacujete prozore između OpenOffice-a i terminala, to može biti dobro, ali za bazu podataka – to je vrlo loše.

Zato je razumna politika postaviti migration_cost na neku visoku vrijednost, barem nekoliko tisuća nanosekundi.

Druga stvar – to je autogroup. Postoji dobra ideja za specifične radne opterećenja, koja nisu vezana uz moderne baze podataka – to je grupiranje procesa prema virtualnom terminalu s kojeg su pokrenuti. To je praktično za neke zadatke. U praksi, PostgreSQL je višekorisnička sistem s prefork arhitekturom, koji se pokreće iz jednog terminala. Imate lock writer, checkpoint, i svi vaši klijentski zahtjevi bit će grupirani na jedan scheduler, na jedan CPU. I čekat će zajedno da se oslobodi, ometajući jedni druge i oduzimajući mu vrijeme duže nego što bi trebali. To je situacija koja u slučaju takvog opterećenja nije potrebna i zato to treba isključiti.

Moj kolega Aleksej Lesovski radio je testove s jednostavnim pgbench, gdje je povećavao migracijski trošak i isključivao autogroup. Razlika na slabom hardveru bila je skoro 10%.Postoji rasprava na postgres mailing listi gdje ljudi dijele rezultate kako su slične promjene utjecale na brzinu zahtjeva. utjecale na 50%.Takvih priča ima prilično mnogo.

I na kraju, o politici štednje energije. Dobro je što sada Linux možete koristiti na laptopu. I navodno će dobro trošiti bateriju. Ali iznenada se pokazuje da to može biti slučaj i na serveru.

Štoviše, ako iznajmljujete server od nekog hostera, „dobri“ hosting ne brinu o tome da vaša performansa bude bolja. Njihov cilj je da iskoriste svoje hardverske resurse maksimalno efikasno. Stoga mogu u operativnom sistemu po defaultu uključiti laptop režim štednje energije.

Ako koristite na serveru s bazom podataka pod intenzivnim opterećenjem ovu stvar, vaš izbor je acpi_cpufreq + performance. Čak će već s ondemandom biti problema.

Intel_pstate je već malo drugačiji drajver. Sada se preferira ovaj, kao novijeg i efikasnijeg.

I, sukladno tome, governor samo performance. Ondemand, powersave i sve drugo – to nije za vas.

Rezultati prema explain analyze PostgreSQL mogu se razlikovati za nekoliko redoslijeda ako uključite powersave, jer će CPU pod vašom bazom biti raspoređen na potpuno nepredvidiv način.

Ove stvari mogu biti uključene po defaultu. Pažljivo provjerite – nisu li uključene po defaultu. To može biti zaista veliki problem.

I na kraju želim zahvaliti ekipi iz naše DBA tima PosgreSQL-Consulting, a posebno Maksu Boguku i Alekseju Lesovskom, koji svaki dan stiču iskustvo u ovom poslu. Pokušavamo učiniti sve najbolje za naše klijente kako bi im sve ovo radilo. To je poput uputa za sigurnost u aviotransportu. Sve je napisano krvlju. Svaki od ovih vijaka otkriven je tijekom nekog problema. S radošću ih dijelim s vama.

Pitanja:

Hvala! Ako, na primjer, tvrtka želi uštedjeti i na jednom serveru smjestiti bazu podataka i aplikacijsku logiku ili, ako tvrtka slijedi modnu tendenciju mikroservisnih arhitektura, u kojima se PostgreSQL pokreće u kontejneru. U čemu je stvar? Sysctl globalno utječe na cijelo jezgro. Nisam čuo da se sysctl na neki način virtualiziraju kako bi radili odvojeno u kontejneru. Postoji samo cgroup i kontrola postoji samo za dio. Kako s tim živjeti? Ili ako želite performanse, pokrenite PostgreSQL na odvojenom fizičkom serveru i optimizirajte ga?

Na vaše pitanje smo odgovorili na otprilike tri načina. Ako se radi o fizičkom serveru koji se može optimizirati itd., opustite se, sve će dobro raditi bez tih postavki. Ako dobijete opterećenje koje zahtijeva ove postavke, do fizičkog servera ćete doći prije nego do ovih postavki.

Koji je problem? Ako je to virtualka, vjerojatno ćete imati mnogo problema, na primjer, s tim da na većini virtualki postoji prilično neusklađeno kašnjenje diska. Čak i ako je propusnost diskova dobra, jedna neuspješna transakcija operacije ulaza-izlaza, koja ne utječe značajno na prosječnu propusnost, koja se dogodila tijekom checkpointa ili zapisivanja u WAL, znatno će naštetiti bazi. I to ćete primijetiti prije nego se suočite s tim problemima.

Ako imate NGINX na istom serveru, imat ćete isti problem. Borit će se za zajedničku memoriju. I do problema opisanih ovdje nećete doći.

No s druge strane, neki od ovih parametara će vam ipak biti relevantni. Na primjer, s sysctl postavite dirty_ratio kako ne bi bio prevelik – u svakom slučaju, to će pomoći. Na ovaj ili onaj način, imat ćete interakciju s diskom. I to će biti po pogrešnom modelu. Ovo su u suštini defaultni parametri koje sam pokazao. I u svakom slučaju, bolje ih je promijeniti.

Mogući su problemi s NUMA. VmWare, primjerice, dobro radi s NUMA s potpuno suprotnim postavkama. I ovdje treba birati – fizički server ili ne.

Imam pitanje vezano uz Amazon AWS. Imaju unaprijed konfigurirane slike. Jedna od njih zove se Amazon RDS. Ima li tamo nekih prilagođenih postavki za njihov operativni sustav?

Ima postavki, ali to su drugačije postavke. Ovdje konfiguriramo operativni sustav s obzirom na to kako će baza podataka to koristiti. A ondje postoje parametri koji određuju kamo idemo, takvo oblikovanje. Dakle, trebamo toliko resursa, a sada ćemo ih trošiti. Nakon toga, Amazon RDS te resurse priključuje, i tu se performanse smanjuju. Ima pojedinačnih priča o tome kako ljudi počinju s tim eksperimentirati. Ponekad čak i prilično uspješno. No to nema veze s postavkama OS-a. To je kao hakiranje oblaka. To je druga priča.

Zašto Transparent huge pages ne daju učinak u usporedbi s Huge TLB?

Ne daju. Ovo se može objasniti na mnogo načina. No, zapravo, oni jednostavno ne daju taj učinak. Kakva je priča s PostgreSQL? On pri pokretanju dodjeljuje veliki dio zajedničke memorije. Transparent, ili ne transparent – potpuno je nevažno. Činjenica da se dodjeljuju pri pokretanju objašnjava sve. I ako je memorije jako puno i treba rekonstruirati shared_memory segment, tada će Transparent huge pages biti relevantni. U PostgreSQL-u je on jednostavno tijekom pokretanja dodijeljen ogromnoj komadu i to je to, a dalje se ne događa ništa posebno. Naravno, može se koristiti, ali postoji rizik od curruption shared_memory, kada će nešto ponovo dodijeliti. PostgreSQL o tome ne zna.

Izvor: habr.com