Linuxi häälestamine PostgreSQL-i jõudluse parandamiseks. Ilja Kosmodemyansky

Ilja Kosmodemyansky 2015. aasta aruande "Linux häälestamine PostgreSQL-i jõudluse parandamiseks" transkriptsioon

Kohustustest loobumine: märgin, et see aruanne on dateeritud 2015. aasta novembrisse – sellest on möödunud rohkem kui 4 aastat ja palju aega. Aruandes käsitletud versiooni 9.4 enam ei toetata. Viimase 4 aasta jooksul on välja antud 5 uut PostgreSQL-i ja 15 Linuxi kerneli versiooni. Kui kirjutate need kohad ümber, saate teistsuguse aruande. Kuid siin on üks põhiline Linuxi häälestus PostgreSQL-i jaoks, mis on endiselt asjakohane.

Minu nimi on Ilja Kosmodemyansky. Töötan ettevõttes PostgreSQL-Consulting. Ja nüüd räägin veidi sellest, mida teha Linuxiga seoses andmebaasidega üldiselt ja eriti PostgreSQL-iga, sest põhimõtted on üsna sarnased.

Mida arutatakse? Kui teil on tegemist PostgreSQL-iga, peate olema mingil määral UNIX-i administraator. Mida see tähendab? Kui võrrelda Oracle'i ja PostgreSQL-i, siis Oracle'is peate olema 80% DBA andmebaasi administraator ja 20% Linuxi administraator.

PostgreSQL on veidi keerulisem. PostgreSQL-iga peab teil olema palju parem ettekujutus Linuxi toimimisest. Ja samas jookse veidi vedurile järele, sest viimasel ajal on kõik päris lahedasti uuendatud. Ja uued tuumad tulevad välja ja ilmub uus funktsionaalsus, paraneb jõudlus jne.

Miks me räägime Linuxist? Üldse mitte sellepärast, et oleme Linuxi konverentsil Peter, vaid sellepärast, et tänapäevastes tingimustes on üks õigustatumaid operatsioonisüsteeme andmebaasidega üldiselt ja eriti PostgreSQL-iga opereerimiseks Linux. Sest FreeBSD areneb kahjuks mingis väga kummalises suunas. Ja probleeme tekib nii jõudluse kui ka paljude muude asjadega. PostgreSQL-i jõudlus Windowsis on üldiselt omaette karm teema, mis põhineb tõsiasjal, et Windowsil pole sellist ühismälu nagu UNIX, ja PostgreSQL on seotud selle äriga, kuna see on mitme protsessi süsteem.

Ja eksootika nagu Solaris pakub ma arvan, et kõigile vähem huvi pakub, nii et las käia.

Kaasaegsel Linuxi distributsioonil on olenevalt kerneli ülesehitusest üle 1 syctl-i valiku. Samas, kui vaadata erinevaid pähkleid, siis võib ikka olla palju võimalusi, kuidas midagi kohendada. Ühendamiseks on failisüsteemi valikud. Kui teil on küsimusi selle kohta, kuidas alustada: mida BIOS-is lubada, kuidas riistvara konfigureerida jne.

Tegemist on väga suure mahuga, millest võib rääkida mitu päeva ja mitte ühes lühikeses aruandes, vaid keskendun nüüd olulistele asjadele, kuidas vältida neid rehasid, mis ei võimalda Linuxis andmebaasiga hästi hakkama saada, kui sa ei paranda neid.. Ja samal ajal on oluline punkt see, et paljud vaikeparameetrid ei sisaldu seadistustes, mis on andmebaasi jaoks õiged. See tähendab, et vaikimisi töötab see halvasti või ei tööta üldse.

Millised on Linuxi traditsioonilised häälestamise eesmärgid? Arvan, et kuna te kõik tegelete Linuxi administreerimisega, pole vaja selgitada, mis on eesmärgid.

Saate häälestada:

• PROTSESSOR.
• Mälu
• Ladustamine.
• muud. Me räägime sellest suupiste lõpus. Isegi näiteks sellised sätted nagu energiasäästupoliitika võivad mõjutada jõudlust väga ettearvamatult ja mitte eriti meeldival viisil.

Millised on PostgreSQL-i ja üldse andmebaasi eripärad? Probleem on selles, et te ei saa mõnda kindlat mutrit näpistada ja näha, et meie jõudlus on palju paranenud.

Jah, selliseid vidinaid on, aga andmebaas on keeruline asi. Ta suhtleb kõigi serveril olevate ressurssidega ja eelistab täielikult suhelda. Kui vaadata Oracle'i praegusi juhiseid hosti OS-i kasutamise kohta, on see nagu Mongoolia astronaudi nali – anna koerale süüa ja ära puuduta midagi. Andkem andmebaasile kõik ressursid, andmebaas ise hävitab kõik.

Põhimõtteliselt on PostgreSQL-iga mingil määral täpselt sama olukord. Erinevus seisneb selles, et ka baas ei suuda enda jaoks kõiki ressursse võtta ehk kuskil Linuxi tasemel tuleb see kõik ise ära sorteerida.

Põhiidee pole mitte valida ühte sihtmärki ja hakata seda häälestama, näiteks mälu, protsessorit või muud taolist, vaid analüüsida töökoormust ja püüda võimalikult palju läbilaskevõimet parandada nii, et see koormus, mille head programmeerijad lõid. meile, sealhulgas meie kasutajatele.

Siin on pilt, mis selgitab, mis see on. On Linuxi OS-i puhver ja jagatud mälu ning PostgreSQL-i jagatud puhvrid. PostgreSQL töötab erinevalt Oracle'ist otse ainult kerneli puhvri kaudu, st selleks, et kettalt leht saaks ühismällu, peab see läbima kerneli puhvri ja tagasi täpselt samas olukorras.

Kettad elavad selle süsteemi all. Joonistasin selle ketastena. Tegelikult võib seal olla RAID-kontroller vms.

Ja see sisend-väljund toimub nii või teisiti selle äri kaudu.

PostgreSQL on klassikaline andmebaas. See on lehe sees. Ja kogu sisend-väljund toimub lehtede abil. Tõstame mälus plokke lehekülgede kaupa. Ja kui midagi ei juhtunud, lugesime need lihtsalt läbi, siis järk-järgult vajuvad nad sellest vahemälust, jagatud puhvritest ja jõuavad tagasi kettale.

Kui oleme kuskil midagi välja vahetanud, märgitakse kogu meie leht määrdunudks. Märkisin need siin sinisega. Ja see tähendab, et see leht tuleb plokisalvestusega sünkroonida. See tähendab, et kui tegime selle mustaks, tegime sissekande WAL-i. Ja ühel ilusal ajahetkel tuli nähtus nimega kontrollpunkt. Ja see logi salvestas teabe, et ta tuli. Ja see tähendab, et kõik määrdunud lehed, mis sel hetkel siin nendes jagatud puhvrites olid, sünkrooniti salvestuskettaga, kasutades fsynci läbi kerneli puhvri.

Milleks see mõeldud on? Kui kaotasime pinge, siis me ei saanud olukorda, et kõik andmed läksid kaduma. Püsiv mälu, millest kõik meile rääkisid, on seni andmebaaside teoorias - see on helge tulevik, mille poole me loomulikult püüdleme ja see meile meeldib, kuid siiani elavad nad ikkagi miinus 20 aasta pärast. Ja loomulikult tuleb seda kõike jälgida.

Ja läbilaskevõime maksimeerimise ülesanne on häälestada kõiki neid etappe nii, et see kõik käiks kiiresti edasi-tagasi. Ühismälu on põhimõtteliselt lehe vahemälu. PostgreSQL-is saatsime seal mingi valikulise päringu, see sai need andmed kettalt. Nad sattusid jagatud puhvritesse. Sellest tulenevalt peab selle paremaks toimimiseks olema palju mälu.

Selleks, et see kõik hästi ja kiiresti töötaks, peate operatsioonisüsteemi kõigil etappidel õigesti konfigureerima. Ja vali tasakaalustatud raud, sest kui sul on mõnes kohas tasakaalutus, siis saad teha palju mälu, aga seda serveeritakse ebapiisava kiirusega.

Vaatame läbi kõik need punktid.

Nende lehtede kiiremaks edasi-tagasi liikumiseks peate saavutama järgmise:

• Esiteks peate mäluga tõhusamalt töötama.
• Teiseks peaks see üleminek olema tõhusam, kui leheküljed mälust lähevad kettale.
• Ja kolmandaks peavad olema head plaadid.

Kui serveris on 512 GB muutmälu ja see kõik jõuab ilma vahemäluta SATA-kõvakettale, siis muutub kogu andmebaasiserver mitte lihtsalt kõrvitsaks, vaid SATA-liidesega kõrvitsaks. Te puutute sellega otse kokku. Ja miski ei päästa sind.

Mis puudutab esimest punkti mäluga, siis on kolm asja, mis võivad elu väga keeruliseks teha.

Esimene on NUMA. NUMA on asi, mis on loodud jõudluse parandamiseks. Sõltuvalt töökoormusest saate optimeerida erinevaid asju. Ja oma uuel praegusel kujul pole see eriti hea selliste rakenduste jaoks nagu andmebaas, mis kasutavad intensiivselt lehe vahemälu jagatud puhvreid.

Ühesõnaga. Kuidas aru saada, et NUMA-ga on midagi valesti? Teil on mingi ebameeldiv koputus, äkki on mõni protsessor ülekoormatud. Samal ajal analüüsid PostgreSQL-is päringuid ja näed, et seal pole midagi sarnast. Need päringud ei tohiks olla nii protsessorimahukad. Saate seda pikka aega püüda. Lihtsam on algusest peale kasutada õigeid nõuandeid NUMA seadistamiseks PostgreSQL-i jaoks.

Mis tegelikult toimub? NUMA tähistab mitteühtlast mälujuurdepääsu. Mis mõte sellel on? Teil on protsessor, selle kõrval on selle kohalik mälu. Ja need mäluühendused võivad tõmmata mälu teistelt protsessoritelt.

Kui jooksed numactl --hardware, siis saad nii suure lehe. Muuhulgas toimub ka distantside väljak. Seal on numbrid - 10-20, midagi sellist. Need numbrid ei ole midagi muud kui hüpete arv, et see kaugmälu üles võtta ja seda kohapeal kasutada. Põhimõtteliselt hea mõte. See parandab hästi jõudlust mitme töökoormuse korral.

Kujutage nüüd ette, et teil on üks protsessor, mis proovib esmalt kasutada oma kohalikku mälu, seejärel proovib millegi jaoks ühendada teise mälu. Ja kogu teie PostgreSQL-i lehe vahemälu jõuab sellesse CPU-sse – see on kõik, mitu gigabaiti seal on. Alati juhtub halvim juhtum, sest tavaliselt on selles moodulis protsessoris vähe mälu. Ja kogu serveeritud mälu käib nende ühenduste kaudu. See selgub aeglaselt ja kurvalt. Ja teil on protsessor, mis teenindab seda sõlme, on pidevalt ülekoormatud. Ja selle mälu juurdepääsuaeg on halb, aeglane. See on selline olukord, mida te ei soovi, kui kasutate seda juhtumit andmebaasi jaoks.

Seetõttu on andmebaasi jaoks õigem variant see, et Linuxi operatsioonisüsteem ei tea üldse, mis seal toimub. Nii et ta käsitleb mälu nii nagu ta kõnetab.

Miks nii? Näib, et see peaks olema vastupidi. See juhtub ühel lihtsal põhjusel, et vajame lehe vahemälu jaoks palju mälu – kümneid, sadu gigabaite.

Ja kui me kõik selle eraldame ja oma andmed sinna vahemällu salvestame, siis on vahemälu kasutamisest saadav kasu oluliselt suurem kui sellise kavala mälupöörduse kasu. Ja nii võidame võrreldamatult sellega, et NUMA abil pääseme mälule tõhusamalt ligi.

Seetõttu on hetkel kaks lähenemist, kuni on saabunud helge tulevik ja andmebaas ise ei saa aru, millistel protsessoritel see töötab ja kust midagi tõmbama peab.

Seetõttu on õige lähenemisviis NUMA täielikult keelatant taaskäivitamisel. Enamasti on võidud sellises järjekorras, et pole üldse küsimustki, kumb on parem.

On veel üks võimalus. Kasutame seda sagedamini kui esimest, sest kui klient tuleb meie juurde tuge otsima, siis tema jaoks on serveri taaskäivitamine terve asi. Tal on seal äri. Ja neil on NUMA tõttu probleeme. Seetõttu proovime selle keelata vähem invasiivsetel viisidel kui taaskäivitamine, kuid siin olge ettevaatlik ja kontrollige, kas see on keelatud. Kuna nagu kogemus näitab, et keelame NUMA PostgreSQL-i vanemprotsessis, on see hea, kuid see pole üldse vajalik, et see toimiks. Peame kontrollima ja nägema, et ta tõesti välja lülitus.

Robert Haasilt on hea postitus. See on üks PostgreSQL-i sidujatest. Üks kõigi madala tasemega sisemuste põhiarendajatest. Ja kui jälgida selle postituse linke, kirjeldab see mitmeid värvikaid lugusid sellest, kuidas NUMA inimeste elu keeruliseks tegi. Vaadake, uurige süsteemiadministraatori kontrollnimekirja selle kohta, mida tuleb serveris konfigureerida, et meie andmebaas hästi töötaks. Need seadistused tuleb salvestada ja üle kontrollida, sest muidu ei tule väga head.

Juhin teie tähelepanu asjaolule, et see kehtib kõigi sätete kohta, millest ma räägin. Kuid tavaliselt koostatakse andmebaasid tõrketaluvuse tagamiseks ülem-alluv-režiimis. Ära unusta neid seadistusi orja peal teha, sest ühel päeval juhtub sinuga avarii ja sa lähed orja peale ja sellest saab peremees.

Hädaolukorras, kui kõik on väga halvasti, telefon heliseb pidevalt ja ülemus jookseb suure pulgaga, pole sul aega kontrollimisele mõelda. Ja tagajärjed võivad olla väga katastroofilised.

Järgmine hetk on tohutud leheküljed. Hiiglaslikke lehti on raske eraldi testida ja sellel pole mõtet, kuigi on olemas etalonid, mis seda võimaldavad. Neid on lihtne googeldada.

Mis mõte sellel on? Teil on mitte väga kallis server, millel on palju RAM-i, näiteks rohkem kui 30 GB. Te ei kasuta suuri lehti. See tähendab, et teil on kindlasti mälukasutusega seotud üldkulud. Ja see üldkulu pole kaugeltki kõige meeldivam.

Miks nii? Ja mis toimub? Operatsioonisüsteem eraldab mälu väikeste tükkidena. Nii mugav, nii ajalooliselt. Ja kui lähete detailidesse, siis peab OS tõlkima virtuaalsed aadressid füüsilisteks. Ja see protsess pole kõige lihtsam, nii et OS salvestab selle toimingu tulemuse vahemällu tõlkevaatepuhvrisse (TLB).

Ja kuna TLB on vahemälu, siis selles olukorras tekivad kõik vahemälule omased probleemid. Esiteks, kui teil on palju RAM-i ja see kõik on eraldatud väikeste tükkidena, muutub see puhver väga suureks. Ja kui vahemälu on suur, on selle otsimine aeglasem. Overhead on terve ja võtab ise ruumi, st RAM-i kulutab midagi valesti. Seekord.

Kaks – mida rohkem vahemälu sellises olukorras kasvab, seda tõenäolisem on vahemälu vahelejäämine. Ja selle vahemälu efektiivsus langeb selle suuruse kasvades kiiresti. Nii et operatsioonisüsteemid leidsid lihtsa lähenemisviisi. Linux on seda juba pikka aega kasutanud. See ilmus FreeBSD-s mitte nii kaua aega tagasi. Aga me räägime Linuxist. Need on suured lehed.

Ja siinkohal tuleb märkida, et hiiglaslikud leheküljed surusid ideena alguses läbi kogukonnad, kuhu kuulusid Oracle ja IBM, st andmebaasitootjad mõtlesid tõsiselt, et sellest kasu oleks ka andmebaaside puhul.

Ja kuidas PostgreSQL-iga sõbruneda? Esiteks peavad Linuxi tuumas olema lubatud suured lehed.

Teiseks peavad need olema selgelt määratud parameetriga sysctl – kui palju neid on. Siin olevad numbrid on pärit mõnest vanast serverist. Saate arvutada ligikaudu, kui palju jagatud puhvreid teil on, et sinna mahuksid suured lehed.

Ja kui teil on kogu server pühendatud PostgreSQL-ile, siis on hea lähtepunkt anda 25% RAM-ist jagatud puhvritele või 75%, kui olete kindel, et teie andmebaas kindlasti mahub nende 75% hulka. Alguspunkt kõigepealt. Ja mõelge, kui teil on 256 GB muutmälu, siis on teil vastavalt 64 GB shed-puhvreid. Arvutage ligikaudu marginaaliga – milliseks peaksite selle arvu määrama.

Enne versiooni 9.2 (kui ma ei eksi, siis alates versioonist 8.2) oli võimalik kolmanda osapoole teeki kasutades sõbrustada tohutute PostgreSQL-i lehtedega. Ja seda tuleks alati teha. Esiteks on teil vaja kernelit, et saaksite suuri lehti õigesti eraldada. Ja teiseks, et nendega töötav rakendus saaks neid kasutada. Seda lihtsalt ei kasutata nii. Kuna PostgreSQL eraldas mälu süsteemi 5 stiilis, saab seda teha libhugetlbfs-i abil – see on teegi täisnimi.

9.3 parandas PostgreSQL-i mälu jõudlust ja eemaldas süsteemi 5 mälu eraldamise meetodi. Kõik olid väga rahul, sest muidu proovite käivitada kaks PostgreSQL-i eksemplari samas masinas ja ta ütleb, et mul pole piisavalt ühismälu. Ja ta ütleb, et peate sysctl parandama. Ja seal on selline sysctl, et peate ikkagi uuesti käivitama jne. Üldiselt olid kõik rahul. Kuid mmap-mälu eraldamine katkes tohutute lehtede abil. Enamik meie kliente kasutab suuri jagatud puhvreid. Ja soovitasime tungivalt mitte 9.3-le üle minna, sest seal hakati üldkulusid arvestama heade protsentidega.

Kuid teisest küljest juhtis kogukond sellele probleemile tähelepanu ja 9.4-s töötasid nad selle sündmuse väga hästi ümber. Ja 9.4-s ilmus faili postgresql.conf parameeter, milles saate proovi sisse lülitada, sisse või välja lülitada.

Proovige on kõige turvalisem valik. Kui PostgreSQL käivitub ja eraldab jagatud mälu, proovib see seda mälu tohututelt lehtedelt haarata. Ja kui see ei tööta, naaseb see tavapärasele valikule. Ja kui teil on FreeBSD või Solaris, võite proovida, see on alati ohutu.

Kui see on sisse lülitatud, siis see lihtsalt ei käivitu, kui see ei suutnud valida tohutute lehtede hulgast. Siin juba - kellele ja mis on armsam. Aga kui proovite, siis kontrollige, kas teil on tõesti see, mida vajate, esile tõstetud, sest vea jaoks on palju tühikuid. Praegu töötab see funktsioon ainult Linuxis.

Veel üks väike märkus, enne kui edasi liigume. Läbipaistvad suured lehed pole veel PostgreSQL-i kohta. Ta ei saa neid normaalselt kasutada. Ja sellise töökoormuse jaoks mõeldud Transparenti tohutute lehtede puhul, kui vajate suurt osa ühismälu, tulevad plussid ainult väga suurte mahtude korral. Kui teil on terabaiti mälu, võib see oma rolli mängida. Kui me räägime igapäevastest rakendustest, kui sul on masinas 32, 64, 128, 256 GB mälu, siis tavalised tohutud lehed on Ok ja lülitame lihtsalt Transparenti välja.

Ja viimane asi mälu juures ei ole otseselt seotud fruputiga, see võib elu väga ära rikkuda. Kogu läbilaskevõimet mõjutab suuresti asjaolu, et server vahetab pidevalt.

Ja see on mõnel hetkel väga ebameeldiv. Ja peamine probleem on selles, et tänapäevaste tuumade käitumine on pisut erinev vanemate Linuxi tuumade omast. Ja see asi, millele on üsna ebameeldiv astuda, sest kui me räägime mõnest tööst swapiga, siis see lõpeb OOM-killeri enneaegse saabumisega. Ja OOM-killer, mis ei tulnud õigeks ajaks ja viskas PostgreSQLi maha, on ebameeldiv. Kõik teavad sellest, see tähendab kuni viimase kasutajani.

Mis toimub? Teil on seal palju RAM-i, kõik töötab hästi. Kuid millegipärast jääb server vahetusse ja aeglustub selle tõttu. Näib, et mälu on palju, kuid see juhtub.

Varem soovitasime vm.swappiness seada nulliks, st keelata swap. Varem tundus, et 32 ​​GB muutmälu ja vastavad jagatud puhvrid on tohutult palju. Vahetuse põhieesmärk on, et oleks koht, kuhu maha kukkudes koorik visata. Ja seda pole eriti hästi tehtud. Ja mida sa selle koorega siis peale hakkad? See on juba selline ülesanne, kui pole väga selge, miks vahetust vaja on, eriti sellise suurusega.

Kuid kaasaegsemates, st tuuma kolmandates versioonides, on käitumine muutunud. Ja kui seate swapi nulli, st lülitate selle välja, siis varem või hiljem, isegi kui RAM on alles, tuleb teie juurde OOM-killer, kes tapab kõige intensiivsemad tarbijad. Sest ta arvestab sellega, et sellise töökoormuse juures on meil veel natuke üle ja me hüppame välja, ehk siis ei tapa süsteemi protsessi, vaid tapame midagi vähem tähtsat. See vähem oluline on ühismälu suur tarbija, nimelt postiülem. Ja pärast on hea, kui alust ei pea taastama.

Seetõttu on nüüd vaikimisi minu mäletamist mööda enamus distributsioone kuskil 6 ehk mis hetkel swap’i kasutama hakata, olenevalt sellest, kui palju mälu alles on. Soovitame nüüd seada vm.swappiness = 1, sest see lülitab selle praktiliselt välja, kuid ei anna selliseid efekte nagu ootamatu OOM-killer, mis tuli ja tappis kogu asja.

Mis järgmiseks? Kui me räägime andmebaaside jõudlusest ja tasapisi, järk-järgult oleme nagu kettad, kõik hakkavad peast kinni haarama. Sest tõde, et ketas on aeglane ja mälu kiire, on kõigile tuttav lapsepõlvest saati. Ja kõik teavad, et andmebaasis on ketta jõudlusega probleeme.

Peamine PostgreSQL-i jõudlusprobleem kontrollpunktide hüppega ei tulene sellest, et ketas on aeglane. Tõenäolisemalt on see tingitud asjaolust, et mälu ja ketta ribalaius ei ole tasakaalus. Samas ei pruugi need olla erinevates kohtades tasakaalus. PostgreSQL pole konfigureeritud, OS pole konfigureeritud, riistvara pole konfigureeritud ja riistvara on vale. Ja seda probleemi ei juhtu ainult siis, kui kõik läheb nii nagu peab, st kas pole koormust või on seaded ja riistvara hästi valitud.

Mis see on ja kuidas see välja näeb? Tavaliselt on PostgreSQL-iga töötavad inimesed sellesse ärisse sisenenud rohkem kui üks kord. ma seletan. Nagu ma ütlesin, teeb PostgreSQL perioodiliselt kontrollpunkte ühismälus olevate määrdunud lehtede kettale visamiseks. Kui meil on palju jagatud mälu, hakkab kontrollpunkt ketast intensiivselt mõjutama, kuna fsync tühjendab need lehed. See saabub kerneli puhvrisse ja kirjutatakse fsynci abil kettale. Ja kui selle juhtumi maht on suur, võime täheldada ebameeldivat efekti, nimelt ketaste väga suurt kasutamist.

Siin on mul kaks pilti. Selgitan nüüd, mis see on. Need on kaks ajaga korrelatsiooniga graafikut. Esimene graafik on ketta kasutamine. Siin jõuab see praegusel hetkel peaaegu 90% -ni. Kui teil on füüsiliste ketastega andmebaasi langus, mille RAID-kontrolleri kasutusaste on alla 90%, on see halb uudis. See tähendab, et natuke rohkem ja tuleb 100 ning sisend/väljund peatub.

Kui teil on kettamassiivi, on lugu veidi erinev. Seal oleneb, kuidas see on seadistatud, milline massiiv jne.

Ja paralleelselt konfigureeritakse siin sisemisest postgresi vaatest graafik, mis ütleb, kuidas kontrollpunkt toimub. Ja siinne roheline värv näitab, kui palju nende määrdunud lehtede puhvreid sel hetkel sünkroonimiseks sellesse kontrollpunkti jõudis. Ja see on siin peamine teada. Näeme, et meil on siin palju lehti ja mingi hetk sattusime tasusse ehk siis kirjutasime ja kirjutasime, siin on kettasüsteem selgelt väga hõivatud. Ja meie kontrollpunktil on kettale väga tugev mõju. Ideaalis peaks olukord välja nägema rohkem selline, st meil oli siin vähem rekordit. Ja me saame selle seadetega parandada, et see niimoodi jätkuks. See tähendab, et taaskasutus on väike, aga kuskil kirjutame siia midagi.

Mida tuleb teha, et sellest probleemist üle saada? Kui olete IO andmebaasi all peatanud, tähendab see, et kõik kasutajad, kes tulid oma päringuid täitma, ootavad.

Kui vaadata Linuxi vaatevinklist, siis kui sa võtsid hea riistvara, seadistasid selle õigesti, konfigureerisid PostgreSQL-i normaalselt nii, et see teeks neid kontrollpunkte harvemini, hajutaks neid ajas üksteise vahel, siis astud Debiani vaikeparameetritesse . Enamiku Linuxi distributsioonide puhul on see pilt: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Mida see tähendab? Alates kerneli versioonist 2.6 on ilmunud üks deemonlik õhetus. Pdglush, olenevalt sellest, kes mida kasutab, mis tegeleb taustal määrdunud lehtede kerneli puhvrist väljaviskamisega ja määrdunud lehtede väljaviskamisega, kui see on vajalik, olenemata sellest, kui tausta viskamine ei aita.

Millal taust tuleb? Kui 10% kogu serveris olevast RAM-ist on tuumapuhvris määrdunud lehtedega hõivatud, kutsutakse taustal spetsiaalne petufunktsioon. Miks ta on taustaga? See võtab parameetrina, mitu lehekülge maha kanda. Ja, ütleme, kirjutab maha N lehekülge. Ja korraks jääb see asi magama. Ja siis tuleb ta tagasi ja kirjutab veel mõned leheküljed maha.

See on äärmiselt lihtne lugu. Siin on ülesanne nagu basseiniga, kui valatakse ühte torusse, valatakse teise. Meie kontrollpunkt tuli ja kui see saatis mõned mustad lehed äraviskamiseks, siis järk-järgult kerneli puhvrist pgflush laheneb kogu see asi kenasti.

Kui neid musti lehti koguneb edasi, siis koguneb neid kuni 20%, pärast seda on OS-i prioriteet kogu asi kettale maha kanda, sest vool lendab välja ja meil läheb kõik halvasti. Näiteks kaotame need andmed.

Mis nipp see on? Trikk seisneb selles, et need parameetrid tänapäeva maailmas, kus on 20 ja 10% kogu masinas olevast muutmälust, on teie kõigi kettasüsteemide läbilaskevõime osas täiesti koletulikud.

Kujutage ette, et teil on 128 GB muutmälu. Teie kettasüsteemi tuleb 12,8 GB. Ja olenemata sellest, milline vahemälu teil seal on, ükskõik milline massiiv teil seal on, need ei pea nii palju vastu.

Seetõttu soovitame neid numbreid kohe kohandada, sõltuvalt teie RAID-kontrolleri võimalustest. Andsin siin kohe soovituse kontrolleri kohta, millel on 512 MB vahemälu.

Kõike peetakse väga lihtsaks. Saate panna vm.dirty_background baitidesse. Ja need sätted alistavad kaks eelmist. Kas suhe on vaikimisi või on aktiveeritud need, millel on bait, siis need, millel on bait, töötavad. Aga kuna olen DBA konsultant ja töötan erinevate klientidega, siis üritan kõrsi laduda ja seega kui baitides, siis baitides. Keegi ei andnud mingit garantiid, et hea admin ei lisa serverisse mälu, ei käivita seda ja see näitaja jääb samaks. Lihtsalt arvuta need numbrid välja, et kõik garantiiga sinna ära mahuks.

Mis juhtub, kui sa ei sobi? Olen kirjutanud, et see peatab tõhusalt igasuguse õhetuse, kuid tegelikult on see kõnekujund. Operatsioonisüsteemil on suur probleem - sellel on palju määrdunud lehti, mistõttu teie klientide loodud IO tõhusalt peatub, st rakendus on tulnud andmebaasi sql-päringut saatma, see ootab. Iga selle sisend/väljund on madalaima prioriteediga, kuna baas on hõivatud kontrollpunktiga. Ja kui ta lõpetab, on see täiesti arusaamatu. Ja kui olete jõudnud mitte-tausta-, mitte-tausta loputuseni, tähendab see, et kogu teie IO on sellega hõivatud. Ja kuni see lõpeb, ei tee te midagi.

On veel kaks olulist punkti, mis jäävad käesoleva raporti raamidest välja. Need sätted peaksid ühtima faili postgresql.conf sätetega, st kontrollpunktide sätetega. Ja teie kettasüsteem peab olema piisavalt konfigureeritud. Kui teil on RAID-is vahemälu, peab sellel olema aku. Inimesed ostavad hea vahemäluga RAID-i ilma akuta. Kui teil on RAID-is SSD, siis peavad need olema serveri omad, seal peavad olema kondensaatorid. Siin on laiendatud kontrollnimekiri. Sellel lingil on minu aruanne ketta jõudluse seadistamise kohta PostgreSQL-is. Kõik need kontrollnimekirjad on olemas.

Mis veel võib elu väga keeruliseks teha? Need on kaks võimalust. Need on suhteliselt uued. Vaikimisi saab neid lisada erinevatesse rakendustesse. Ja nad võivad elu sama palju keerulisemaks teha, kui neid valesti sisse lülitada.

Seal on kaks suhteliselt uut tükki. Need on ilmunud juba kolmandas tuumas. Need on sched_migration_cost nanosekundites ja sched_autogroup_enabled, mis on vaikimisi üks.

Ja kuidas nad elu rikuvad? Mis on sched_migration_cost? Linuxi planeerija saab protsessi ühest CPU-st teise migreerida. Ja päringuid täitva PostgreSQL-i jaoks on teisele CPU-le üleminek täiesti arusaamatu, miks. Operatsioonisüsteemi seisukohast võib see olla hea, kui vahetate akende openoffice'i ja terminali vahel, kuid andmebaasi jaoks - see on väga halb. Seetõttu on mõistlik poliitika seada migration_cost mõnele suurele väärtusele, vähemalt mõnele tuhandele nanosekundile.

Mida see planeerija jaoks tähendab? Eeldatakse, et selle aja jooksul on see protsess endiselt kuum. See tähendab, et kui teil on mingi pikk tehing, mis teeb midagi pikka aega, saab ajakava koostaja sellest aru. Ta eeldab, et kuni see aeg on möödas, ei pea seda protsessi kuhugi migreerima. Kui protsess samal ajal midagi teeb, siis seda ei migreerita kuhugi, see lõpetab rahulikult sellel CPU-l, mis talle eraldati. Ja tulemus on suurepärane.

Teine punkt on autorühmitus. On hea idee konkreetsete töökoormuste jaoks, mis ei ole seotud tänapäevaste andmebaasidega – see on protsesside rühmitamine virtuaalse terminali järgi, kust need käivitatakse. See on mõne töö jaoks mugav. Praktikas on PostgreSQL preforki mitme protsessiga süsteem, mis töötab ühest terminalist. Teil on lukukirjutaja, kontrollpunkt ja kõik teie kliendipäringud on rühmitatud ühte ajakavasse protsessori kohta. Ja nad ootavad seal koos, kui ta on vaba, et üksteist segada ja teda kauem hõivatud hoida. See on jutt, mis sellise koormuse puhul on täiesti ebavajalik ja seetõttu tuleks see välja lülitada.

Mu kolleeg Aleksei Lesovski tegi testid lihtsa pgbenchiga, kus ta suurendas migration_cost suurusjärgu võrra ja lülitas autogrupi välja. Halval rauatükil osutus erinevus peaaegu 10%. Postgresi meililistis on arutelu, kus inimesed teatavad tulemustest, nagu sarnased muudatused päringu kiiruses mõjutas 50%. Selliseid lugusid on päris palju.

Ja lõpuks energiasäästupoliitikast. Hea, et Linuxi saab nüüd sülearvutis kasutada. Ja väidetavalt kulutab see akut hästi. Kuid järsku selgub, et see võib juhtuda ka serveris.

Veelgi enam, kui rentite servereid mõnelt hostijalt, ei huvita "head" hostijad, et teil oleks parem jõudlus. Nende ülesanne on tagada, et nende rauda kasutatakse võimalikult tõhusalt. Seetõttu saavad nad vaikimisi sisse lülitada operatsioonisüsteemi sülearvuti energiasäästurežiimi.

Kui kasutate seda suure koormusega andmebaasiserveris, on teie valik acpi_cpufreq + permormance. Isegi nõudmisel tekivad juba probleemid.

Intel_pstate on veidi erinev draiver. Ja nüüd eelistatakse seda, kui hilisemat ja paremini töötavat.

Ja vastavalt sellele on kuberner ainult jõudlus. Ondemand, powersave ja kõik muu – see ei puuduta teid.

PostgreSQL-i seletusanalüüsi tulemused võivad energiasäästu lubamisel erineda mitme suurusjärgu võrra, kuna praktikas tekib CPU-d andmebaasi alla täiesti ettearvamatult.

Neid asju saab vaikimisi lubada. Vaadake hoolikalt, kas need on vaikimisi lubatud. See võib olla tõesti suur probleem.

Ja lõpuks tahtsin öelda tänu meie PosgreSQL-Consulting DBA meeskonna poistele, nimelt Max Bogukile ja Alexey Lesovskyle, kes täidavad iga päev selle ettevõtte konarusi. Ja oma klientide jaoks püüame anda endast parima, et see kõik nende jaoks toimiks. See on nagu lennundusjulgestusjuhistega. Siin on kõik verega kirjutatud. Kõik need pähklid avastatakse mingi probleemi käigus. Mul on hea meel neid teiega jagada.

Küsimused:

Aitäh! Kui näiteks ettevõte soovib säästa raha ning majutada andmebaasi ja rakenduste loogikat samas serveris või kui ettevõte järgib mikroteenuste arhitektuuride moetrendi, milles PostgreSQL töötab konteineris. Mis mõte sellel on? Sysctl mõjutab globaalselt kogu tuuma. Ma pole kuulnud, et sysctls oleks kuidagi virtualiseeritud nii, et need konteineris eraldi töötaksid. On ainult cgrupp ja ainult osal sellest on kontroll. Kuidas sa saad sellega elada? Või kui soovite jõudlust, käivitage PostgreSQL eraldi raudserveris ja häälestage seda?

Oleme teie küsimusele vastanud umbes kolmel viisil. Kui me ei räägi rauast serverist, mida saab tuunida vms, siis lõdvestuge, ilma nende seadeteta töötab kõik hästi. Kui teil on selline koormus, et peate need seadistused tegema, siis tulete rauast serverisse varem kui need seaded.

Milles on probleem? Kui see on virtuaalne masin, on teil tõenäoliselt palju probleeme, näiteks sellega, et enamikul virtuaalmasinatel on ketta latentsusaeg üsna ebaühtlane. Isegi kui ketta läbilaskevõime on hea, üks ebaõnnestunud sisend-/väljundtehing, mis ei mõjuta oluliselt keskmist läbilaskevõimet, mis juhtus kontrollpunkti või WAL-i kirjutamise ajal, kannatab see andmebaas suuresti. Ja te märkate seda enne, kui nende probleemidega kokku puutute.

Kui teil on samas serveris NGINX, on teil ka sama probleem. Ta võitleb ühise mälu eest. Ja siin kirjeldatud probleemideni te ei jõua.

Kuid teisest küljest on mõned neist parameetritest teie jaoks endiselt asjakohased. Näiteks sysctl-ga määrake dirty_ratio, et nii hulluks ei läheks - see aitab igal juhul. Ühel või teisel viisil suhtlete kettaga. Ja see saab olema vale. See on üldiselt minu näidatud parameetrite vaikeseade. Ja igal juhul on parem neid muuta.

Ja NUMA-ga võib probleeme tekkida. Näiteks VmWare töötab täpselt vastupidiste sätetega NUMA-ga hästi. Ja siin tuleb valida - raudserver või mitteraudne.

Mul on Amazon AWS-iga seotud küsimus. Neil on pildid eelkonfigureeritud. Üks neist kannab nime Amazon RDS. Kas nende operatsioonisüsteemi jaoks on kohandatud sätteid?

Seadistused on olemas, kuid need on erinevad seaded. Siin konfigureerime operatsioonisüsteemi vastavalt sellele, kuidas andmebaas seda ettevõtet kasutab. Ja on parameetrid, mis määravad, kuhu me nüüd minema peaksime, selline kujundamine. See tähendab, et meil on nii palju ressursse vaja, sööme need nüüd ära. Pärast seda kinnitab Amazon RDS need ressursid ja jõudlus langeb seal. Sellest, kuidas inimesed hakkavad selle asjaga keemiat tegema, on eraldi lood. Vahel isegi päris edukalt. Kuid sellel pole OS-i sätetega midagi pistmist. See on nagu pilve häkkimine. See on hoopis teine ​​lugu.

Miks pole läbipaistvatel tohututel lehtedel tohutut TLB-ga võrreldes mingit mõju?

Ära anna. Seda saab seletada mitmeti. Aga tegelikult nad lihtsalt ei anna seda. Mis on PostgreSQL-i ajalugu? Käivitamisel eraldab see suure osa jagatud mälust. Läbipaistvad nad on samal ajal või mitte läbipaistvad - see pole üldse oluline. See, et nad alguses silma paistavad, selgitab kõike. Ja kui mälu on palju ja teil on vaja jagatud_mälu segmenti uuesti üles ehitada, on läbipaistvad tohutud lehed asjakohased. PostgreSQLis tõstetakse see alguses lihtsalt suure tükiga esile ja ongi kõik ning siis ei juhtu seal midagi erilist. Muidugi saate seda kasutada, kuid kui see midagi ümber eraldab, on võimalus saada curruption shared_memory. PostgreSQL ei tea sellest.

Allikas: www.habr.com