Nastavitev Linuxa za izboljšanje zmogljivosti PostgreSQL. Ilja Kosmodemjanski

Transkript poročila Ilye Kosmodemyanskyja iz leta 2015 "Nastavitev Linuxa za izboljšanje zmogljivosti PostgreSQL"

Izjava o omejitvi odgovornosti: Ugotavljam, da je to poročilo datirano iz novembra 2015 - minilo je več kot 4 leta in veliko časa. Različica 9.4, obravnavana v poročilu, ni več podprta. V zadnjih 4 letih je bilo izdanih 5 novih izdaj PostgreSQL in 15 različic jedra Linuxa. Če prepišete te odlomke, boste na koncu dobili drugačno poročilo. Tukaj pa upoštevamo temeljno prilagoditev Linuxa za PostgreSQL, ki je še danes pomembna.

Moje ime je Ilya Kosmodemyansky. Delam pri PostgreSQL-Consulting. In zdaj bom govoril malo o tem, kaj storiti z Linuxom v zvezi z bazami podatkov na splošno in še posebej s PostgreSQL, ker so načela precej podobna.

O čem bomo govorili? Če komunicirate s PostgreSQL, potem morate biti do neke mere skrbnik UNIX. Kaj to pomeni? Če primerjamo Oracle in PostgreSQL, potem morate biti v Oraclu 80 % skrbnik baze podatkov DBA in 20 % skrbnik Linuxa.

Pri PostgreSQL je malo bolj zapleteno. S PostgreSQL morate veliko bolje razumeti, kako deluje Linux. In ob tem še malo poteci za lokomotivo, ker se je zadnje čase vse kar lepo posodobilo. Izdajo se nova jedra, pojavijo se nove funkcionalnosti, izboljša se zmogljivost itd.

Zakaj govorimo o Linuxu? Sploh ne zato, ker smo na Linux konferenci Peter, ampak zato, ker je v sodobnih razmerah eden najbolj upravičenih operacijskih sistemov za uporabo baz podatkov nasploh in še posebej PostgreSQL Linux. Ker se FreeBSD na žalost razvija v neko zelo čudno smer. In težave bodo tako pri uspešnosti kot pri marsičem drugem. Učinkovitost PostgreSQL v sistemu Windows je na splošno ločena resna težava, ki temelji na dejstvu, da Windows nima enakega skupnega pomnilnika kot UNIX, medtem ko je PostgreSQL ves vezan na to, ker je večprocesni sistem.

In mislim, da vse manj zanima eksotika, kot je Solaris, tako da gremo.

Sodobna distribucija Linuxa ima več kot 1 možnosti syctl, odvisno od tega, kako zgradite jedro. Hkrati, če pogledamo različne orehe, lahko nekaj prilagodimo na več načinov. Obstajajo parametri datotečnega sistema, kako jih namestiti. Če imate vprašanja o tem, kako ga zagnati: kaj omogočiti v BIOS-u, kako konfigurirati strojno opremo itd.

To je zelo velik obseg, o katerem bi lahko razpravljali več dni in ne v enem kratkem poročilu, zdaj pa se bom osredotočil na pomembne stvari, kako se izogniti tistim grabljam, ki vam bodo zagotovo preprečile dobro uporabo vaše baze podatkov v Linuxu, če ne popravljaj jih. In hkrati je pomembna točka, da številni privzeti parametri niso vključeni v nastavitve, ki so pravilne za bazo podatkov. To pomeni, da bo privzeto delovalo slabo ali sploh ne.

Kateri tradicionalni cilji prilagajanja so v Linuxu? Mislim, da ker se vsi ukvarjate z administracijo Linuxa, ni treba posebej razlagati, kaj so cilji.

Uglasite lahko:

• CPE.
• Spomin
• Skladiščenje.
• drugo. O tem se bomo pogovorili na koncu za prigrizek. Tudi na primer parametri, kot so politike varčevanja z energijo, lahko vplivajo na delovanje na zelo nepredvidljiv in ne najbolj prijeten način.

Kakšne so posebnosti PostgreSQL in podatkovne baze nasploh? Težava je v tem, da ne morete prilagoditi nobene posamezne matice in videti, da se je naša uspešnost bistveno izboljšala.

Ja, obstajajo taki pripomočki, vendar je baza podatkov kompleksna stvar. Interakcija je z vsemi viri, ki jih ima strežnik, in raje komunicira v največji možni meri. Če pogledate trenutna Oraclova priporočila o tem, kako uporabljati gostiteljski OS, bo to kot v šali o tistem mongolskem kozmonavtu – nahranite psa in se ničesar ne dotikajte. Dajmo bazi podatkov vse vire, baza bo sama vse uredila.

Načeloma je do neke mere popolnoma enaka situacija s PostgreSQL. Razlika je v tem, da baza podatkov še ne more vzeti vseh virov zase, torej nekje na nivoju Linuxa moraš vse urediti sam.

Glavna ideja ni izbrati enega samega cilja in ga začeti prilagajati, na primer pomnilnik, CPE ali kaj podobnega, ampak analizirati delovno obremenitev in poskušati čim bolj izboljšati prepustnost, tako da je obremenitev, ki so jo ustvarili dobri programerji za nas, vključno z našimi uporabniki.

Tukaj je slika, ki pojasnjuje, kaj je. Obstaja medpomnilnik OS Linux in skupni pomnilnik ter skupni medpomnilniki PostgreSQL. PostgreSQL, za razliko od Oracla, deluje neposredno samo prek medpomnilnika jedra, tj., da stran z diska pride v njegov skupni pomnilnik, mora iti skozi medpomnilnik jedra in nazaj, popolnoma enaka situacija.

Diski živijo v tem sistemu. To sem narisal kot diske. Pravzaprav lahko obstaja krmilnik RAID itd.

In ta input-output se tako ali drugače zgodi skozi to zadevo.

PostgreSQL je klasična baza podatkov. Notri je stran. Vsi vhodni in izhodni podatki se izvajajo s pomočjo strani. S stranmi dvigujemo bloke v pomnilnik. In če se nič ne zgodi, jih samo preberemo, nato postopoma izginejo iz tega predpomnilnika, iz skupnih medpomnilnikov in končajo nazaj na disku.

Če nekje kaj zamenjamo, potem je cela stran označena kot umazana. Tukaj sem jih označil z modro. In to pomeni, da mora biti ta stran sinhronizirana s shrambo blokov. Se pravi, ko smo ga umazali, smo naredili vnos v WAL. In v nekem čudovitem trenutku je prišel pojav, imenovan kontrolna točka. In v ta dnevnik je bila zapisana informacija, da je prišel. In to pomeni, da so bile vse umazane strani, ki so bile v tistem trenutku tukaj v teh medpomnilnikih v skupni rabi, sinhronizirane s shranjevalnim diskom z uporabo funkcije fsync prek medpomnilnika jedra.

Zakaj se to počne? Če smo izgubili napetost, potem nismo dobili situacije, da so vsi podatki izgubljeni. Vztrajni spomin, o katerem so nam vsi govorili, je tako daleč v teoriji podatkovnih baz - to je svetla prihodnost, h kateri seveda stremimo in nam je všeč, a zaenkrat živijo v minus 20 letih. In seveda je treba vse to spremljati.

In naloga maksimiranja prepustnosti je natančno prilagajanje vseh teh stopenj, tako da se vse hitro premika naprej in nazaj. Skupni pomnilnik je v bistvu predpomnilnik strani. V PostgreSQL smo poslali izbirno poizvedbo ali kaj podobnega, ta je te podatke pridobil z diska. Končali so v skupnih medpomnilnikih. Zato mora biti za boljše delovanje veliko pomnilnika.

Da bi vse to delovalo dobro in hitro, morate na vseh stopnjah pravilno konfigurirati operacijski sistem. In izberite uravnoteženo strojno opremo, ker če imate neravnovesje na nekem mestu, lahko naredite veliko pomnilnika, vendar ne bo dovolj hitro servisiran.

In pojdimo skozi vsako od teh točk.

Če želite, da te strani potujejo naprej in nazaj hitreje, morate doseči naslednje:

• Najprej morate učinkoviteje delati s pomnilnikom.
• Drugič, ta prehod, ko gredo strani iz pomnilnika na disk, bi moral biti učinkovitejši.
• In tretjič, morajo biti dobri diski.

Če imate v strežniku 512 GB RAM-a in vse skupaj konča na trdem disku SATA brez predpomnilnika, potem se celoten strežnik baze podatkov spremeni ne le v bučo, ampak v bučo z vmesnikom SATA. Neposredno boste naleteli nanj. In nič te ne bo rešilo.

Kar zadeva prvo točko s spominom, obstajajo tri stvari, ki lahko zelo otežijo življenje.

Prvi med njimi je NUMA. NUMA je stvar, ki je narejena za izboljšanje zmogljivosti. Glede na delovno obremenitev je mogoče optimizirati različne stvari. In v svoji novi trenutni obliki ni zelo dober za aplikacije, kot so baze podatkov, ki intenzivno uporabljajo skupne medpomnilnike predpomnilnika strani.

Na kratko. Kako lahko ugotovite, ali je z NUMA kaj narobe? Imate nekakšno neprijetno trkanje, nenadoma je neki CPU preobremenjen. Hkrati analizirate poizvedbe v PostgreSQL in vidite, da tam ni nič podobnega. Te poizvedbe ne bi smele biti tako intenzivne za procesor. To lahko ujamete dolgo časa. Lažje je že od samega začetka uporabiti pravilno priporočilo o tem, kako konfigurirati NUMA za PostgreSQL.

Kaj se pravzaprav dogaja? NUMA pomeni neenoten dostop do pomnilnika. Kaj je smisel? Imate CPE, poleg njega je njegov lokalni pomnilnik. In te pomnilniške povezave lahko črpajo pomnilnik iz drugih procesorjev.

Če tečeš numactl --hardware, potem boste dobili tako velik list. Med drugim bo na voljo polje razdalje. Tam bodo številke - 10-20, nekaj takega. Te številke niso nič drugega kot število skokov za prevzem tega oddaljenega pomnilnika in njegovo lokalno uporabo. Načeloma dobra ideja. To močno pospeši delovanje pri različnih delovnih obremenitvah.

Zdaj si predstavljajte, da imate en CPE, ki najprej poskuša uporabiti svoj lokalni pomnilnik, nato pa poskuša za nekaj pridobiti drug pomnilnik prek medsebojne povezave. In ta CPE dobi vaš celoten predpomnilnik strani PostgreSQL - to je to, nekaj gigabajtov. Vedno dobite najslabši primer, ker je na CPE običajno malo pomnilnika v samem modulu. In ves pomnilnik, ki je servisiran, gre skozi te medsebojne povezave. Izpade počasi in žalostno. In vaš procesor, ki servisira to vozlišče, je nenehno preobremenjen. In dostopni čas tega pomnilnika je slab, počasen. To je situacija, ki je ne želite, če to uporabljate za bazo podatkov.

Zato je za bazo pravilnejša možnost, da operacijski sistem Linux ne ve, kaj se tam sploh dogaja. Tako da dostopa do pomnilnika, kot ga ima.

Zakaj? Zdi se, da bi moralo biti obratno. To se zgodi iz enega preprostega razloga: potrebujemo veliko pomnilnika za predpomnilnik strani - desetine, stotine gigabajtov.

In če smo vse to dodelili in tam predpomnili naše podatke, bo dobiček od uporabe predpomnilnika bistveno večji kot dobiček od tako zapletenega dostopa do pomnilnika. In tako bomo imeli neprimerljivo korist v primerjavi z dejstvom, da bomo z uporabo NUMA učinkoviteje dostopali do pomnilnika.

Zato sta trenutno tu dva pristopa, dokler ne nastopi svetla prihodnost in sama baza podatkov ne more ugotoviti, na katerih procesorjih teče in od kod mora kaj potegniti.

Zato je pravilen pristop, da v celoti onemogočite NUMA, na primer pri ponovnem zagonu. V večini primerov so dobitki takšnih velikosti, da se vprašanje, kaj je boljše, sploh ne pojavi.

Obstaja še ena možnost. Uporabljamo ga pogosteje kot prvega, saj ko stranka pride k nam po podporo, je ponovni zagon strežnika zanj velik zalogaj. Tam ima podjetje. In imajo težave zaradi NUMA. Zato ga poskušamo onemogočiti na manj invazivne načine kot ponovni zagon, vendar pazite, da preverite, ali je onemogočen. Ker, kot kažejo izkušnje, je dobro, da onemogočimo NUMA na nadrejenem procesu PostgreSQL, sploh pa ni nujno, da bo deloval. Moramo preveriti, ali se je res izklopila.

Obstaja dobra objava Roberta Haasa. To je eden od posredovalcev PostgreSQL. Eden ključnih razvijalcev vseh nizkonivojskih gibletov. In če sledite povezavam iz te objave, opisujejo več barvitih zgodb o tem, kako je NUMA ljudem otežila življenje. Poglejte, preučite kontrolni seznam sistemskega skrbnika o tem, kaj je treba konfigurirati na strežniku, da bo naša zbirka podatkov dobro delovala. Te nastavitve je treba zapisati in preveriti, ker sicer ne bo prav dobro.

Upoštevajte, da to velja za vse nastavitve, o katerih bom govoril. Toda običajno se baze podatkov zbirajo v načinu master-slave zaradi tolerance napak. Ne pozabite narediti teh nastavitev na pomožni enoti, ker boste nekega dne imeli nesrečo in boste preklopili na pomožno enoto, ki bo postala glavna.

V izrednih razmerah, ko je vse zelo slabo, vam telefon nenehno zvoni in vaš šef priteče z veliko palico, ne boste imeli časa razmišljati o preverjanju. In rezultati so lahko zelo katastrofalni.

Naslednja točka so ogromne strani. Ogromne strani je težko testirati ločeno in nima smisla to početi, čeprav obstajajo primerjalna merila, ki to zmorejo. Z lahkoto jih je poguglati.

Kaj je smisel? Imate ne zelo drag strežnik z veliko RAM-a, na primer več kot 30 GB. Ne uporabljate ogromnih strani. To pomeni, da imate zagotovo dodatne stroške v smislu uporabe pomnilnika. In ta režija še zdaleč ni najbolj prijetna.

Zakaj? Torej, kaj se dogaja? Operacijski sistem dodeljuje pomnilnik v majhnih delih. To je tako priročno, tako se je zgodilo v zgodovini. In če gremo v podrobnosti, mora OS prevesti virtualne naslove v fizične. In ta postopek ni najenostavnejši, zato operacijski sistem predpomni rezultat te operacije v Translation Lookaside Buffer (TLB).

In ker je TLB predpomnilnik, se v tej situaciji pojavijo vse težave, ki so del predpomnilnika. Prvič, če imate veliko RAM-a in je ves dodeljen v majhnih kosih, postane ta medpomnilnik zelo velik. In če je predpomnilnik velik, je iskanje po njem počasnejše. Overhead je zdrav in zaseda prostor, kar pomeni, da RAM porabi nekaj napačnega. Tokrat.

Dva - bolj ko se predpomnilnik poveča v takšni situaciji, večja je verjetnost, da boste imeli zgrešene predpomnilnike. In učinkovitost tega predpomnilnika hitro upada, ko se njegova velikost povečuje. Zato so operacijski sistemi pripravili preprost pristop. V Linuxu se uporablja že dolgo časa. V FreeBSD se je pojavil ne tako dolgo nazaj. Ampak govorimo o Linuxu. To so ogromne strani.

In tukaj je treba opozoriti, da so ogromne strani kot idejo sprva spodbujale skupnosti, ki so vključevale Oracle in IBM, torej proizvajalci podatkovnih baz so močno menili, da bo to uporabno tudi za baze podatkov.

In kako se to lahko spoprijatelji s PostgreSQL? Prvič, ogromne strani morajo biti omogočene v jedru Linuxa.

Drugič, izrecno jih je treba določiti s parametrom sysctl – koliko jih je. Številke tukaj so iz nekega starega strežnika. Izračunate lahko, koliko medpomnilnikov v skupni rabi imate, da se tja lahko prilegajo ogromne strani.

In če je vaš celoten strežnik namenjen PostgreSQL, potem je dobro izhodišče, da 25 % RAM-a dodelite medpomnilnikom v skupni rabi ali 75 %, če ste prepričani, da bo vaša zbirka podatkov zagotovo sodila v teh 75 %. Izhodišče ena. In upoštevajte, če imate 256 GB RAM-a, potem boste imeli v skladu s tem 64 GB velikih medpomnilnikov. Približno izračunajte z rezervo - na koliko naj bo ta številka nastavljena.

Pred različico 9.2 (če se ne motim, od različice 8.2) je bilo mogoče povezati PostgreSQL z ogromnimi stranmi s pomočjo knjižnice tretje osebe. In to je treba vedno storiti. Najprej potrebujete jedro, da lahko pravilno dodeli ogromne strani. In drugič, da jih aplikacija, ki dela z njimi, lahko uporablja. Ne bo uporabljen samo tako. Ker je PostgreSQL dodelil pomnilnik v slogu sistema 5, je to mogoče storiti z uporabo libhugetlbfs - to je polno ime knjižnice.

V 9.3 je bila zmogljivost PostgreSQL izboljšana pri delu s pomnilnikom in metoda dodeljevanja pomnilnika System 5 je bila opuščena. Vsi so bili zelo veseli, ker drugače poskušaš zagnati dve instanci PostgreSQL na enem računalniku, on pa pravi, da nimam dovolj skupnega pomnilnika. In pravi, da je treba sysctl popraviti. In obstaja takšen sysctl, da morate še vedno znova zagnati itd. Na splošno so bili vsi zadovoljni. Toda dodelitev pomnilnika mmap je prekinila uporabo ogromnih strani. Večina naših strank uporablja velike skupne medpomnilnike. In močno priporočamo, da ne preklopite na 9.3, ker so se režijski stroški začeli izračunavati v dobrih odstotkih.

Toda skupnost je bila pozorna na to težavo in v 9.4 je zelo dobro predelala ta dogodek. In v 9.4 se je v postgresql.conf pojavil parameter, v katerem lahko omogočite poskus, vklop ali izklop.

Poskusi je najvarnejša možnost. Ko se PostgreSQL zažene, ko dodeli skupni pomnilnik, poskuša ta pomnilnik zgrabiti z ogromnih strani. In če ne deluje, se vrne na običajno izbiro. In če imate FreeBSD ali Solaris, potem lahko poskusite, vedno je varno.

Če je vklopljen, se preprosto ne zažene, če ne more izbrati med ogromnimi stranmi. Tukaj gre že za to, kdo in kaj je lepše. Če pa poskusite, potem preverite, ali imate res poudarjeno tisto, kar potrebujete, saj je prostora za napake veliko. Trenutno ta funkcija deluje samo v sistemu Linux.

Še ena majhna opomba, preden nadaljujemo. Transparentne ogromne strani še niso povezane s PostgreSQL. Ne more jih normalno uporabljati. In s prozornimi ogromnimi stranmi za tako delovno obremenitev, ko je potreben velik del pomnilnika v skupni rabi, so prednosti le pri zelo velikih količinah. Če imate terabajte pomnilnika, lahko to pride v poštev. Če govorimo o bolj vsakdanjih aplikacijah, ko imate na računalniku 32, 64, 128, 256 GB pomnilnika, potem so običajne ogromne strani OK, Transparent pa preprosto onemogočimo.

In zadnja stvar v zvezi s spominom ni neposredno povezana s sadjem, saj vam lahko resnično uniči življenje. Na vso prepustnost bo močno vplivalo dejstvo, da se strežnik nenehno izmenjuje.

In to bo na več načinov zelo neprijetno. In glavna težava je, da se sodobna jedra obnašajo nekoliko drugače kot starejša jedra Linuxa. In na to stvar je precej neprijetno stopiti, ker ko govorimo o nekem delu s swapom, se to konča s prezgodnjim prihodom OOM-killerja. In OOM-morilec, ki ni prišel pravočasno in je izpustil PostgreSQL, je neprijeten. Za to bodo vedeli vsi, torej do zadnjega uporabnika.

Kaj se dogaja? Tam imate veliko količino RAM-a, vse deluje dobro. Toda iz nekega razloga strežnik visi v swapu in se zaradi tega upočasni. Zdi se, da je veliko pomnilnika, vendar se to zgodi.

Prej smo svetovali nastavitev vm.swappiness na nič, tj. onemogočanje zamenjave. Prej se je zdelo, da je 32 GB RAM-a in ustreznih skupnih medpomnilnikov ogromno. Glavni namen zamenjave je, da imamo kam vreči skorjo, če pademo. In ni bilo več posebej izpolnjeno. In kaj boš potem naredil s to skorjo? To je naloga, pri kateri ni povsem jasno, zakaj je potrebna zamenjava, še posebej takšne velikosti.

Toda v modernejših, tj. tretjih različicah jedra, se je obnašanje spremenilo. In če nastavite swap na nič, torej ga izklopite, potem bo prej ali slej, tudi če ostane nekaj RAM-a, k vam prišel OOM killer, da pobije najbolj intenzivne porabnike. Ker bo menil, da nam pri taki obremenitvi še malo ostane in bomo skočili ven, torej ne zato, da bi zakoličili sistemski proces, ampak da bi zakoličili nekaj manj pomembnega. Ta manj pomemben pa bo intenziven porabnik skupnega pomnilnika, namreč poštar. In potem bo dobro, če baze ne bo treba obnavljati.

Zato je zdaj privzeto, kolikor se spomnim, večina distribucij je nekje okoli 6, tj. na kateri točki bi morali začeti uporabljati zamenjavo, odvisno od tega, koliko pomnilnika je ostalo. Zdaj priporočamo nastavitev vm.swappiness = 1, ker ga to praktično izklopi, vendar ne daje enakih učinkov kot pri OOM-killerju, ki je nepričakovano prišel in uničil celotno stvar.

Kaj je naslednje? Ko govorimo o zmogljivosti podatkovnih baz in se postopoma premikamo proti diskom, se vsi začnejo prijeti za glavo. Kajti resnica, da je disk počasen in pomnilnik hiter, je vsem znana že od otroštva. In vsi vedo, da bo baza podatkov imela težave z delovanjem diska.

Glavna težava z zmogljivostjo PostgreSQL, povezana s skoki kontrolnih točk, se ne pojavi, ker je disk počasen. To je najverjetneje posledica dejstva, da pomnilnik in pasovna širina diska nista uravnotežena. Vendar morda na različnih mestih niso uravnoteženi. PostgreSQL ni konfiguriran, OS ni konfiguriran, strojna oprema ni konfigurirana in strojna oprema ni pravilna. In ta težava se ne zgodi le, če se vse zgodi, kot bi moralo, torej ali ni obremenitve ali pa so nastavitve in strojna oprema dobro izbrani.

Kaj je to in kako izgleda? Običajno so ljudje, ki delajo s PostgreSQL, v to zadevo vstopili več kot enkrat. Bom razložil. Kot sem rekel, PostgreSQL občasno naredi kontrolne točke za izpis umazanih strani iz skupnega pomnilnika na disk. Če imamo veliko deljenega pomnilnika, potem začne checkpoint intenzivno vplivati ​​na disk, saj te strani odloži s fsync. Prispe v medpomnilnik jedra in se zapiše na diske s pomočjo fsync. In če je obseg tega posla velik, potem lahko opazimo neprijeten učinek, in sicer zelo veliko izkoriščenost diskov.

Tukaj imam dve sliki. Zdaj bom pojasnil, kaj je to. To sta dva časovno korelirana grafa. Prvi graf je uporaba diska. Tu doseže skoraj 90 % v tem trenutku. Če imate napako v bazi podatkov s fizičnimi diski, pri čemer je izkoriščenost krmilnika RAID 90 %, potem je to slaba novica. To pomeni, da še malo in doseže 100 in V/I se bo ustavil.

Če imate diskovno polje, je zgodba nekoliko drugačna. Odvisno je od tega, kako je konfiguriran, kakšen niz je itd.

In vzporedno je tukaj konfiguriran graf iz notranjega pogleda postgres, ki pove, kako pride do kontrolne točke. In zelena barva tukaj prikazuje, koliko medpomnilnikov, teh umazanih strani, je v tistem trenutku prispelo na to kontrolno točko za sinhronizacijo. In to je glavna stvar, ki jo morate vedeti. Vidimo, da imamo tukaj veliko strani in v nekem trenutku smo udarili v tablo, se pravi, pisali smo in pisali, tukaj je diskovni sistem očitno zelo zaseden. In naša kontrolna točka zelo močno vpliva na disk. V idealnem primeru bi situacija morala izgledati bolj tako, se pravi, da smo imeli manj snemanja tukaj. In lahko z nastavitvami popravimo, da bo tako še naprej. Se pravi, reciklaža je majhna, ampak nekje tukaj nekaj pišemo.

Kaj je treba storiti, da bi premagali to težavo? Če ste ustavili IO pod bazo podatkov, to pomeni, da bodo vsi uporabniki, ki so prišli izpolniti svoje zahteve, čakali.

Če pogledate z vidika Linuxa, če ste vzeli dobro strojno opremo, jo pravilno konfigurirali, normalno konfigurirali PostgreSQL, tako da redkeje postavlja te kontrolne točke, jih med seboj porazdeli skozi čas, potem stopite v privzete parametre Debian. Za večino distribucij Linuxa je to slika: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Kaj to pomeni? En splakovalni demon se je pojavil iz jedra 2.6. Pdglush, odvisno od tega, kdo uporablja katero, ki se ukvarja z zavrženjem umazanih strani v ozadju iz vmesnega pomnilnika jedra in zavrženjem, ko je treba zavreči umazane strani ne glede na vse, ko zavrženje ozadja ne pomaga.

Kdaj pride ozadje? Ko 10 % celotnega RAM-a, ki je na voljo na strežniku, zasedejo umazane strani v medpomnilniku jedra, se v ozadju prikliče posebna funkcija odpisa. Zakaj je ozadje? Kot parameter upošteva, koliko strani odpisati. In, recimo, odpiše N strani. In za nekaj časa ta stvar zaspi. In potem spet pride in kopira še nekaj strani.

To je izjemno preprosta zgodba. Tukaj je problem kot pri bazenu, ko se zlije v eno cev, teče v drugo. Naša kontrolna točka je prispela in če je poslala nekaj umazanih strani v zavrženje, bo postopoma vsa stvar lepo rešena iz medpomnilnika jedra pgflush.

Če se te umazane strani še naprej kopičijo, se jih nabere do 20%, potem pa je OS prioriteta, da vse skupaj odpiše na disk, ker bo zmanjkalo električne energije in nam bo vse slabo. Te podatke bomo na primer izgubili.

V čem je trik? Trik je v tem, da ti parametri v sodobnem svetu znašajo 20 in 10 % celotnega RAM-a, ki je na stroju, so popolnoma pošastni glede na prepustnost katerega koli diskovnega sistema, ki ga imate.

Predstavljajte si, da imate 128 GB RAM-a. 12,8 GB prispe v vaš diskovni sistem. In ne glede na to, kakšen predpomnilnik imate tam, ne glede na to, katero polje imate tam, ne bodo zdržali tako dolgo.

Zato priporočamo, da te številke takoj prilagodite glede na zmogljivosti vašega krmilnika RAID. Tukaj sem takoj dal priporočilo za krmilnik, ki ima 512 MB predpomnilnika.

Vse se šteje za zelo preprosto. Lahko postavite vm.dirty_background v bajtih. In te nastavitve prekličejo prejšnji dve. Razmerje je privzeto ali pa so aktivirani tisti z bajti, potem bodo delovali tisti z bajti. Ker pa sem DBA svetovalec in delam z različnimi strankami, poskušam vleči slamice in zato, če v bajtih, potem v bajtih. Nihče ni dal nobenega zagotovila, da dober administrator ne bo strežniku dodal več pomnilnika, ga znova zagnal in bo številka ostala enaka. Preprosto izračunajte te številke, da se vse ujema z garancijo.

Kaj se zgodi, če se ne ujemate? Napisal sem, da je vsakršno zardevanje učinkovito ustavljeno, ampak v resnici je to figura govora. Operacijski sistem ima veliko težavo - ima veliko umazanih strani, zato je IO, ki ga ustvarijo vaši odjemalci, dejansko ustavljen, tj. aplikacija je prišla poslati sql poizvedbo v bazo podatkov in čaka. Vsak vhod/izhod vanjo je najnižje prioritete, ker je baza podatkov zasedena s kontrolno točko. In kdaj bo končala, je popolnoma nejasno. In ko dosežete splakovanje brez ozadja, to pomeni, da so vsi vaši IO zasedeni. In dokler se ne konča, ne boste storili ničesar.

Tukaj sta še dve pomembni točki, ki presegata obseg tega poročila. Te nastavitve se morajo ujemati z nastavitvami v postgresql.conf, tj. nastavitvami kontrolnih točk. In vaš diskovni sistem mora biti ustrezno konfiguriran. Če imate predpomnilnik v RAID-u, mora imeti baterijo. Ljudje kupujejo RAID z dobrim predpomnilnikom brez baterije. Če imaš SSD v RAID, potem morajo biti strežniški, tam morajo biti kondenzatorji. Tukaj je podroben kontrolni seznam. Ta povezava vsebuje moje poročilo o tem, kako konfigurirati zmogljivostni disk v PostgreSQL. Tam so vsi ti kontrolni seznami.

Kaj še lahko močno oteži življenje? To sta dva parametra. So relativno novi. Privzeto jih je mogoče vključiti v različne aplikacije. In prav tako lahko otežijo življenje, če so vklopljeni nepravilno.

Obstajata dve relativno novi stvari. Pojavili so se že v tretjih jedrih. To je sched_migration_cost v nanosekundah in sched_autogroup_enabled, ki je privzeto ena.

In kako ti uničijo življenje? Kaj je sched_migration_cost? V sistemu Linux lahko razporejevalnik preseli proces iz enega procesorja v drugega. In za PostgreSQL, ki izvaja poizvedbe, je selitev na drug CPE popolnoma nejasna. Z vidika operacijskega sistema je to morda dobro, ko okna preklapljate med openoffice in terminalom, vendar za podatkovno bazo je to zelo slabo. Zato je razumna politika nastavitev migration_cost na neko veliko vrednost, vsaj nekaj tisoč nanosekund.

Kaj bo to pomenilo za načrtovalca? Šteje se, da je v tem času postopek še vroč. Se pravi, če imate dolgotrajno transakcijo, ki nekaj počne že dolgo časa, bo planer to razumel. Domneval bo, da dokler ta časovna omejitev ne mine, tega procesa ni treba nikamor preseliti. Če hkrati proces nekaj naredi, potem ne bo nikamor preseljen, tiho bo deloval na CPU, ki mu je bil dodeljen. In rezultat je odličen.

Druga točka je samodejno združevanje. Obstaja dobra ideja za posebne delovne obremenitve, ki niso povezane s sodobnimi zbirkami podatkov – to je združevanje procesov glede na virtualni terminal, iz katerega se zaženejo. To je priročno za nekatera opravila. V praksi je PostgreSQL večprocesni sistem s preforkom, ki teče iz enega terminala. Imate pisatelja zaklepanja, kontrolno točko in vse vaše zahteve odjemalcev bodo združene v en razporejevalnik za vsak CPU. In tam bodo složno čakali, da bo prost, da se bodo med seboj vmešavali in ga dlje zaposlili. To je zgodba, ki je ob taki obremenitvi popolnoma nepotrebna in jo je zato treba izklopiti.

Moj kolega Alexey Lesovsky je naredil teste s preprostim orodjem pgbench, kjer je povečal migration_cost za red velikosti in izklopil samodejno združevanje. Razlika na slabi strojni opremi je bila skoraj 10%. Obstaja razprava na poštnem seznamu postgres, kjer ljudje dajejo rezultate podobnih sprememb hitrosti poizvedbe vplival 50%. Takih zgodb je kar veliko.

In končno, o politiki varčevanja z energijo. Dobra stvar je, da je Linux zdaj mogoče uporabljati na prenosniku. Pa še baterijo bo menda dobro porabil. Toda nenadoma se izkaže, da se to lahko zgodi tudi na strežniku.

Poleg tega, če najamete strežnike od nekega gostitelja, potem "dobrim" gostiteljem ni mar, da imate boljše zmogljivosti. Njihova naloga je zagotoviti, da je njihovo železo čim bolj učinkovito izkoriščeno. Zato lahko privzeto omogočijo način varčevanja z energijo prenosnika v operacijskem sistemu.

Če te stvari uporabljate na strežniku z bazo podatkov pod veliko obremenitvijo, potem je vaša izbira acpi_cpufreq + permormance. Tudi pri ondemand bodo težave.

Intel_pstate je nekoliko drugačen gonilnik. In zdaj je dana prednost temu, saj je kasnejši in deluje bolje.

In zato je guverner le uspešnost. Ondemand, varčevanje z energijo in vse ostalo se ne nanaša na vas.

Rezultati razlage analize PostgreSQL se lahko razlikujejo za več vrst velikosti, če omogočite varčevanje z energijo, ker bo CPE v vaši bazi podatkov praktično deloval na popolnoma nepredvidljiv način.

Ti elementi so lahko privzeto vključeni. Pozorno poglejte, ali so ga privzeto vklopili. To je lahko res velik problem.

In na koncu bi se želel zahvaliti fantom iz naše ekipe DBA PosgreSQL-Consulting, namreč Maxu Boguku in Alexeyu Lesovskyju, ki vsak dan napredujeta pri tej zadevi. In poskušamo narediti najboljše, kar lahko, za naše stranke, tako da vse deluje zanje. To je tako kot z navodili za varnost v letalstvu. Tukaj je vse zapisano s krvjo. Vsak od teh orehov se znajde v procesu neke vrste težave. Z veseljem jih delim z vami.

Vprašanja:

Hvala vam! Če želi na primer podjetje prihraniti denar in bazo podatkov ter logiko aplikacije postaviti na en strežnik ali če podjetje sledi modnemu trendu mikrostoritvenih arhitektur, v katerih PostgreSQL teče v vsebniku. V čem je trik? Sysctl bo globalno vplival na celotno jedro. Nisem še slišal, da bi bil sysctl nekako virtualiziran, tako da deluje ločeno v vsebniku. Obstaja samo cgroup in tam je samo del nadzora. Kako lahko živiš s tem? Ali če želite zmogljivost, zaženite PostgreSQL na ločenem strežniku strojne opreme in ga prilagodite?

Na vaše vprašanje smo odgovorili na približno tri načine. Če ne govorimo o strežniku strojne opreme, ki ga je mogoče nastaviti itd., Potem se sprostite, brez teh nastavitev bo vse delovalo v redu. Če imate tako obremenitev, da morate narediti te nastavitve, boste na železni strežnik prišli prej kot na te nastavitve.

V čem je problem? Če je to virtualni stroj, potem boste najverjetneje imeli veliko težav, na primer z dejstvom, da je na večini virtualnih strojev zakasnitev diska precej nedosledna. Tudi če je prepustnost diska dobra, ena neuspešna V/I transakcija, ki ne vpliva močno na povprečno prepustnost, ki se je zgodila v času kontrolne točke ali v času pisanja v WAL, bo baza podatkov zaradi tega močno trpela. In to boste opazili, preden boste naleteli na te težave.

Če imate NGINX na istem strežniku, boste imeli isto težavo. Boril se bo za skupni spomin. In ne boste prišli do tukaj opisanih težav.

Toda po drugi strani bodo nekateri od teh parametrov še vedno pomembni za vas. Na primer, nastavite dirty_ratio s sysctl, da ne bo tako noro - v vsakem primeru bo to pomagalo. Tako ali drugače boste imeli interakcijo z diskom. In bo po napačnem vzorcu. To je na splošno privzeto za parametre, ki sem jih prikazal. In v vsakem primeru jih je bolje spremeniti.

Lahko pa pride do težav z NUMA. VmWare na primer dobro deluje z NUMA z ravno nasprotnimi nastavitvami. In tukaj morate izbrati - železni strežnik ali ne-železni.

Imam vprašanje v zvezi z Amazon AWS. Imajo vnaprej konfigurirane slike. Eden od njih se imenuje Amazon RDS. Ali obstajajo nastavitve po meri za njihov operacijski sistem?

Tam so nastavitve, vendar so drugačne. Tukaj konfiguriramo operacijski sistem glede na to, kako bo baza podatkov uporabljala to stvar. In obstajajo parametri, ki določajo, kam naj gremo zdaj, kot je oblikovanje. To pomeni, da potrebujemo toliko virov, da jih bomo zdaj pojedli. Po tem Amazon RDS poostri te vire in zmogljivost tam pade. Obstajajo posamezne zgodbe ljudi, ki so se začeli ukvarjati s to zadevo. Včasih celo precej uspešno. Vendar to nima nobene zveze z nastavitvami OS. To je kot vdiranje v oblak. To je druga zgodba.

Zakaj Transparent huge pages nima učinka v primerjavi z Huge TLB?

Ne dajaj. To je mogoče razložiti na več načinov. A v resnici tega preprosto ne dajo. Kakšna je zgodovina PostgreSQL? Ob zagonu dodeli velik kos skupnega pomnilnika. Ali so transparentni ali ne, je popolnoma nepomembno. Dejstvo, da izstopajo že na začetku, pojasni vse. In če je veliko pomnilnika in morate znova zgraditi segment shared_memory, potem bodo Transparent ogromne strani ustrezne. V PostgreSQL je na začetku preprosto dodeljen v velikem kosu in to je to, nato pa se tam ne zgodi nič posebnega. Seveda ga lahko uporabite, vendar obstaja možnost, da pride do poškodbe shared_memory, ko nekaj znova dodeli. PostgreSQL tega ne pozna.

Vir: www.habr.com