PostgreSQL jõudluse parandamiseks mõeldud Linuxi häälestus. Ilya Kosmodemyanski

2015. aasta Ilya Kosmodemyanski ettekande "PostgreSQL jõudluse parandamiseks mõeldud Linuxi häälestus" kokkuvõte

Klišee: Tahan märkida, et see ettekand on dateeritud 2015. aasta novembrisse — on möödunud üle 4 aasta ja palju on juhtunud. Ettekandes käsitletud versioon 9.4 ei ole enam toetatud. Viimase 4 aasta jooksul on ilmunud 5 uut PostgreSQL versiooni ning 15 Linuxi tuuma versiooni. Kui neid kohti üle kirjutada, saame lõpuks teistsuguse ettekande. Kuid siin käsitletakse Linuxi põhihäälestust PostgreSQL jaoks, mis on endiselt aktuaalne.

Minu nimi on Ilya Kosmodemyanski. Töötan ettevõttes PostgreSQL-Consulting. Täna räägin pisut, mida teha Linuxiga, mis puudutab andmebaase üldiselt ja PostgreSQL-i konkreetselt, kuna põhimõtted on üsna sarnased.

Millest me räägime? Kui suhtlete PostgreSQL-iga, tuleb mingil määral olla UNIX-i administraator. Mis see tähendab? Kui võrrelda Oracle'i ja PostgreSQL-i, peab Oracle'is olema 80% andmebaasi DBA ja 20% Linuxi administraator.

PostgreSQL on natuke keerulisem. PostgreSQL-i puhul peab Linuxi toimimisest palju paremini aru saama. Ja samas peab veidi järele jõudma, kuna viimasel ajal on toimunud palju värskendusi. Uued tuumad ilmuvad, uus funktsionaalsus tuleb, jõudlus paraneb jne.

Miks me räägime Linuxist? Mitte sellepärast, et oleme Linuxi konverentsil Peterburis, vaid sellepärast, et tänapäeva tingimustes on üks kõige põhjendatumaid operatsioonisüsteeme andmebaaside ning eelkõige PostgreSQL-i jaoks – just Linux. Kuna FreeBSD, kahjuks, areneb mingis väga kummalises suunas. Ja tulevad probleemid nii jõudluse kui paljude muude asjadega. PostgreSQL-i jõudlus Windowsis – see on üldse eraldi karm teema, mis sõltub siitä, et Windowsil ei ole sellist jagatud mälu nagu UNIX-il, ja PostgreSQL põhineb just sellel, kuna see on mitme protsessi süsteem.

Ja eksootika, nagu Solaris, usun ma, huvitab vähem inimesi, seega liikume edasi.

Kaasaegsetel Linuxi jaotustel on üle 1000 syctl parameetri, sõltuvalt sellest, kuidas tuuma kokku panna. Kui vaatame erinevaid seadeid, saame neid veel paljusid viise kohandada. On olemas failisüsteemi parameetreid, näiteks kuidas mälu mountida. Kui tekib küsimusi, kuidas käivitada: mida BIOSis aktiveerida, kuidas riistvara konfigureerida jne.

See on väga suur teema, millest võiks rääkida mitu päeva, mitte ühe lühikese ettekande jooksul, aga ma peatun praegu olulistel punktidel, kuidas vältida neid takistusi, mis kindlasti ei luba teil hästi hallata andmebaasi Linuxis, kui te neid ei paranda. Oluline on ka see, et paljud parameetrid on vaikimisi seatud mitte just sellistele seadistustele, mis sobiksid andmebaasi jaoks. T. e. vaikimisi töötab see halvasti või ei tööta üldse.

Millised on traditsioonilised häälestusobjektid Linuxis? Arvan, et kuna te kõik tegelete Linuxi haldamisega, pole eriti vaja selgitada, mis on häälestusobjektid.

Saab häälestada:

• CPU.
• Mälu.
• Salvestus.
• Muud. Sellega räägime lõpus naljana. Näiteks võivad sellised parameetrid nagu energiasäästupoliitika mõjutada jõudlust väga ettearvamatult ja mitte kõige meeldivamal viisil.

Milline on PostgreSQL'i ja andmebaasi eripära üleüldiselt? Probleem on selles, et ei saa reguleerida mõnda üksikut mutrit ja vaadata, kas jõudlus on oluliselt paranenud.

Jah, selliseid mutreid on, kuid andmebaas on keeruline asi. See suhtleb kõigi serveri ressurssidega ja eelistab suhelda täielikult. Kui vaatate Oracle'i tänapäevaseid soovitusi, kuidas kasutada hostitud OS-i, siis see meenutab nalja mongoli kosmonautidest – sööta koera ja mitte midagi puudutada. Anname andmebaasile kõik ressursid, andmebaas lahendab kõik ise.

Põhimõtteliselt on PostgreSQL-il samasugune olukord. Erinevus seisneb selles, et andmebaas ei oska endale kõiki ressursse ise võtta, st kuskil tuleb Linuxi tasandil ise kõik ära lahendada.

Põhimõte on mitte valida ühte spetsiifilist sihtmärki ja hakata seda häälestama, näiteks mälu, CPU või midagi sarnast, vaid analüüsida töökoormust ja püüda maksimaalselt parandada läbilaskevõimet, et meie andmebaas suudaks kõige efektiivsemalt hallata koormust, mille head programmeerijad meile loonud on, sealhulgas meie kasutajad.

Siin on selline joonis, et selgitada, mis see on. On olemas Linuxi OS puhverside, jagatud mälu ja jagatud puhver PostgreSQL-is. PostgreSQL erinevalt Oracle'ist töötab otse ainult tuumapuhverside kaudu, st et leht peab diskilt jõudma tema jagatud mällu, mis tähendab, et see peab läbima kernel bufferi ja sama kehtib tagasitee kohta.

Selle süsteemi all elavad kettad. Joonistasin selle ketaste kujul. Tegelikult võivad seal olla RAID-kontroller jne.

Ja see sisend-väljund toimub kas või mingil viisil selle kaudu.

PostgreSQL on klassikaline andmebaas. Seal sees on lehed. Kõik sisend-väljund toimub lehtede kaudu. Me tõstame lehti mällu. Ja kui midagi ei juhtunud, siis me lihtsalt lugesime neid, siis nad aeglaselt kaovad sellest vahemälust, jagatud puhverdest ja naasevad kettale.

Kui me kuskil midagi asendasime, siis kogu leht märgitakse mustaks. Ma märkisin need siin sinise värviga. Ja see tähendab, et see leht peab olema sünkroniseeritud plokkide salvestamisega. St kui me selle mustaks tegime, siis tegime kirje WAL-sse. Ja mingil hetkel tekkis nähtus nimega checkpoint. Ja sellesse logisse sai kirja teave selle kohta, et see on toimunud. Ja see tähendab, et kõik mustad lehed, mis seal sel hetkel olid jagatud puhverdes, sünkroniseeriti kettaga salvestamisega fsync kaudu kernel'i puhvri abil.

Miks seda tehakse? Kui meil on elektrikatkestus, ei pea me muretsema, et kõik andmed on kadunud. Perpetuaalne mälu, millest me kõik oleme kuulnud, on praegu rohkem teoreetiline mõte – see on helge tulevik, mille poole me loomulikult püüame ja mis meile meeldib, kuid seni elame me ikka veel 20 aastat minevikus. Ja seda tuleb jälgida.

Küsimus, kuidas maksimeerida läbilaskevõimet, on häälestada kõik need etapid nii, et kõik liiguks kiiresti edasi-tagasi. Jagatud mälu põhineb peamiselt lehekülje puhvritel. PostgreSQL-is saadame päringu select, see toob andmed kettalt. Need jõuavad jagatud puhvritesse. Seega, et see paremini töötaks, peab olema palju mälu.

Kuna kõik toimiks hästi ja kiiresti, peate operatsioonisüsteemi kõigil etappidel õigesti seadistama. Samuti tuleb tasakaalustada riistvara, sest kui mõnes kohas on tasakaaluhäired, võite küll omada suurt mälu, kuid see töötab siiski aeglaselt.

Ja vaatame iga punkti lähemalt.

Ette need lehed kiiremini liikuda saaks, tuleb saavutada järgmised tingimused:

• Esiteks tuleb tõhusamalt töötada mäluga.
• Teiseks peab see üleminek olema efektiivsem, kui lehed mälust kõvakettale jõuavad.
• Ja kolmandaks peavad olema kvaliteetsed kõvakettad.

Kui teil on 512 GB RAM-i serveril ja kõik see jõuab lõpuks SATA kõvakettale ilma igasuguse vahemäluta, siis muutub kogu andmebaasiserver mitte ainult kõrvitsaks, vaid kõrvitsaks SATA liidesega. Te peate sellega otse kokku puutuma. Ja miski ei päästa teid sellest.

Esimese punkti osas mälust on kolm asja, mis võivad elu oluliselt raskendada.

Esimene neist on NUMA. NUMA on süsteem, mis on loodud tulemuslikkuse parandamiseks. sõltuvalt töökoormusest saab erinevaid asju optimeerida. Ja oma praeguses vormis ei ole see andmebaasi rakenduste jaoks, mis kasutavad intensiivselt lehekülje vahemälu ja jagatud puhvreid, just eriti kasulik.

Kahe sõnaga. Kuidas mõista, et NUMA-ga on midagi valesti? Teil on ebamugav müra, äkki avastate, et mõni CPU on ülekoormatud. Samas analüüsite PostgreSQL-i päringuid ja näete, et seal pole midagi sellist. Need päringud ei tohiks CPU-d nii intensiivselt koormata. Sellist olukorda on kaua raske tabada. Lihtsam on algusest peale kasutada õiget soovitust NUMA seadistamiseks PostgreSQL jaoks.

Mis tegelikult toimub? NUMA on Non-Uniform Memory Access. Mis on selle mõte? Teil on CPU, mille läheduses on tema kohaliku mälu. Ja see mälu interconnects võib tuua mälu teistelt CPU-delt.

Kui käivitate numactl --hardware, siis näete suurt väljatrükki. Muuhulgas on seal ka kauguste väli. Seal on numbrid - 10-20, midagi sellist. Need numbrid on üksnes hüpetega, et seda kauget mälu ühenduda ja kohalikult kasutada. Üldiselt on see hea idee. See kiirendab tõhusust teatud koormuste puhul.

Kujutage nüüd ette, et teil on üks CPU, mis esmalt proovib kasutada oma lokaalset mälu ja seejärel püüab interconnect'i kaudu tõmmata teist mälu millegi jaoks. Ja kõik teie PostgreSQL page cache'i mahud jõuavad selle CPU-ni – paar gigabaiti. Te saate alati halva tulemuse, sest selle mälu mooduli kohta on CPU-s tavaliselt vähe mälurubit. Ja kogu mälu, mida teenindatakse, liigub läbi nende interconnect'ide. Tulemuseks on aeglane ja kurb olukord. Teie protsessor, mis teenindab seda sõlme, on pidevalt üle koormatud. Ja selle mälu ligipääsu aeg – halb ja aeglane. See on olukord, mida te ei soovi, kui kasutate seda andmebaasi jaoks.

Seetõttu on andmebaasi jaoks õigem lahendus, et Linuxi operatsioonisüsteem ei teaks üldse, mis toimub. Et ta käsitleks mälu sama moodi nagu tavaliselt.

Miks on nii? Tundub, et peaks olema vastupidi. See juhtub ühel lihtsal põhjusel – me vajame page cache'i jaoks palju mälu – kümneid, sadu gigabaiti.

Ja kui me oleme kõik need andmed välja tõstnud ja vahemäcacheerinud, siis kasu vahemäcacheerimise kasutamisest on märkimisväärselt suurem kui sellisest nutikast mäluhaldusest saadud kasu. Nii saavutame me võidu, mis ei ole võrreldav selle uue mäluhaldurimeetodi tõhusama rakendamisega NUMA abil.

Teisest küljest on sel hetkel kaks lähenemist, kuni helge tulevik saabub ja andmebaas oskab ise aru saada, millistel CPU-del ta töötab ja kust tal midagi tõmmata on vaja.

Seega on õige lähenemine NUMA täielik väljalülitamine., näiteks taaskäivitamisel. Enamasti on kasu nii suur, et pole üldse küsimust, kuidas paremini toimida.

On olemas teine variant. Me kasutame seda tihedamini kui esimest, kuna kui klient meie tugiteenusele tuleb, on serveri taaskäivitamine tema jaoks suur probleem. Tal on seal äri käimas. Ja NUMA probleemide tõttu nad kannatavad. Seetõttu püüame vähem invasiivsete meetoditega välja lülitada, kui taaskäivitamine, kuid siin tuleb ettevaatlikult kontrollida, et see tõesti välja lülitus. Kuna kogemus näitab, et kui me välja lülitame vanema PostgreSQL NUMA protsessi, siis see on hea, kuid pole sugugi kindel, et see töötab. Tuleb kontrollida ja vaadata, et see tõepoolest välja lülitus.

On olemas hea postitus Robert Haasilt. Ta on üks PostgreSQL-i arendajatest. Üks võtme arendaja kõigist madalate tasemete tööriistadest. Ja kui selle postituse linkide kaudu edasi liikuda, siis seal on mitmeid värvikaid lugusid selle kohta, kuidas NUMA inimese elu keerulisemaks tegi. Vaadake, uurige süsteemiadministraatorite kontrollnimekirja, mida serveris seadistada, et meie andmebaas hästi töötaks. Need seadistused tuleb üles kirjutada ja kontrollida, sest muidu ei ole asjad head.

Märgin ära, et see kehtib kõikide seadistuste kohta, millest ma räägin. Kuid tavaliselt kogutakse andmebaase master-slave režiimis, et tagada tõrketaluvus. Ärge unustage neid seadistusi slave'ile teha, sest ühel hetkel võib teil juhtuda õnnetus, te lülitate üle slave'ile ja see saab masteriks.

Kriitilises olukorras, kui kõik on väga halvasti, heliseb teie telefon pidevalt ja ülemus jookseb kohale suures käes, teil pole aega mõelda, et kontrollida. Ja tulemused võivad olla väga kahetsusväärsed.

J следующий момент – это huge pages. Huge pages on keeruline eraldi testida, ega sellel pole mõtet, kuigi on bänkmärgid, mis oskavad seda teha. Need on kergesti ülesleitavad.

Mis mõte on? Teil on mitte väga kallis server, millel on palju RAMi, näiteks rohkem kui 30 GB. Te ei kasuta huge pages. See tähendab, et teil on kindlasti mälukasutuse ülekatte. Ja see ülekaal ei ole sugugi meeldiv.

Miks nii on? Mis toimub? Operatsioonisüsteem eraldab mälu väikeste tükkidena. See on mugav ja nii on ajalooliselt kujunenud. Kui vaadata sügavamale, peab OS tõlkima virtuaalsed aadressid füüsilisteks. See ei ole kõige lihtsam protsess, mistõttu OS talletab selle operatsiooni tulemuse Translation Lookaside Buffer (TLB) mällu.

Kuna TLB on vahemälu, siis sellises olukorras tekivad kõik vahemälu probleemid. Esiteks, kui teil on väga palju raamatu mälu ja see on kõik jaotatud väikesteks tükkideks, siis muutub see vahemälu väga suureks. Ja kui vahemälu on suur, siis on selle otsimine aeglasem. Üksus on suur ja see ise tarvitab ruumi, st. midagi vale kasutab operatiivmälu. See on esimene asi.

Teiseks, mida suuremaks kasvab vahemälu, seda tõenäolisem on, et teil tekivad vahemälu tabamised (cache misses). Ja selle vahemälu efektiivsus langeb kiiresti koos selle suuruse kasvuga. Seetõttu on operatsioonisüsteemides välja töötatud lihtne lähenemine. Linuxis on see juba ammu kasutusel. FreeBSD-s ilmus see mitte nii kaua aega tagasi. Kuid me räägime samuti Linuxist. See on huge pages.

Siin tuleb märkida, et huge pages, kui idee, sai algselt propageeritud kogukondade poolt, kuhu kuulusid Oracle ja IBM, st andmebaasi tootjad mõtlesid tõsiselt, et see tuleb kasuks, sealhulgas andmebaasidele.

Kuidas neid PostgreSQL'iga kooskõlastada? Esiteks peavad Linuxi tuumas olema sisse lülitatud huge pages.

Teiseks peavad need olema selgelt määratletud sysctl parameetriga – kui palju neid on. Numbrid on siin mõnelt vanalt serverilt. Saate arvutada, kui palju teie shared buffers ligikaudu on, et huge pages sinna sisse mahuks.

Ja kui kogu server on pühendatud PostgreSQL'ile, siis hea lähtepunkt on kas 25% RAM-ist jagada shared buffersi jaoks või 75%, kui olete kindel, et teie andmebaas mahtus kindlasti sellesse 75%. See on esimene lähtepunkt. Ja arvutage, kui teil on 256 GB RAM-i, siis vastavalt on 64 GB teie shared bufferseid. Arvutage see mõningase varuga – mis numbriks peaks see olema seatud.

Versioonis 9.2 (kui ma ei eksi, alates versioonist 8.2) oli võimalik PostgreSQL ühendada huge pages'i abil kolmanda osapoole teegi kaudu. Seda on alati vajalik teha. Esiteks peab tuuma suudma õigesti jaotada huge pages'e. Teiseks peab rakendus, mis nendega töötab, olema suuteline neid kasutama. Muul juhul nad ei tööta. Kuna PostgreSQL jagas mälu system 5 stiilis, oli selleks võimalik kasutada libhugetlbfs'i — see on teegi täisnimi.

Versioonis 9.3 parandati PostgreSQL-i jõudlust mälu haldamisel ja loobuti system 5 mälu jaotamise meetodist. Kõik olid väga õnnelikud, sest muidu proovid käivitada kahte PostgreSQL'i eksemplari ühel masinal, ja ta ütleb, et mul pole jagatud mälu piisavalt. Ja ütleb, et sysctl'i tuleb parandada. Seal on selline sysctl, et tuleb veel taaskäivitada jms. Ühesõnaga, kõik rõõmustasid. Kuid mäluhalduse mmap rikkus huge pages'i kasutamise. Enamik meie kliente kasutab suuremaid jagatud puufe. Ja me soovisime tungivalt, et nad ei üleminekuks versioonile 9.3, sest seal algas overhead märkimisväärselt kasvama.

Kuid siiski pöördus community selle probleemi poole ja 9.4 versioonis tehti sellele üritusele väga head muudatused. Samuti ilmus 9.4-s postgresql.conf failis parameeter, millega saab aktiveerida try, on või off.

Try on kõige ohutum parameeter. PostgreSQL-i käivitamisel, kui see eraldab jagatud mälu, üritab ta saada mälumahtu huge pages’ist. Ja kui see ei õnnestu, siis kukub tagasi tavalisse eraldamisse. Ja kui teil on FreeBSD või Solaris, siis võite kasutada try-d, see on alati ohutu.

Kui on, siis see lihtsalt ei käivitu, kui ei suuda huge pages’ist eraldada. Siin on juba see, mis kellelegi sobib. Kuid kui teil on try, siis kontrollige, et teil on tõeliselt vajalik mälu eraldatud, sest seal on palju vigu. Praegu töötab see funktsionaalsus ainult Linuxis.

Veel üks väike märkus, enne kui edasi liigume. Transparent huge pages ei kehti PostgreSQL jaoks praegu. Ta ei saa neid normaalselt kasutada. Ja Transparent huge pages puhul sellise töökoormuse korral, kus vajatakse suurt osa jagatud mälu, toovad kasu ainult väga suurte mahtude korral. Kui teil on terabaite mälu, siis võib see mängida rolli. Kui räägime tavalisematest rakendustest, kus teil on masinas 32, 64, 128, 256 GB mälu, on tavalised huge pages täiesti piisavad, ning Transparent lihtsalt keelame.

Ja viimane asi, mis on seotud mäluga, ei ole otseselt seotud läbilaskevõimega, kuid võib elu väga keeruliseks teha. Kogu läbilaskevõime kannatab tõsiselt, kui server pidevalt vahetab.

Ja ja see toob kaasa mitmeid ebamugavusi. Peamine probleem seisneb selles, et tänapäevaste kernide käitumine erineb natuke vanematest Linuxi kernidest. See on asi, millele astuda on üsna ebameeldiv, sest kui me räägime swap'iga töötamisest, lõppeb see mitte õigeaegse OOM-killer'i saabumisega. Ja OOM-killer, kes ei saabu õigel ajal ja kutsub PostgreSQL-i kokku kukkuma, on ebameeldiv. Sellest saavad teada kõik, st viimase kasutajani.

Mis toimub? Teie serveris on suur hulk RAMi ja kõik töötab hästi. Kuid mingil põhjusel seisab server swap'is ja aeglustub seetõttu. Tundub, et mälu on palju, aga see juhtub siiski.

Varem soovitasime vm.swappiness seada nulli, st swap välja lülitada. Varem tundus, et 32 GB RAM ja vastavad jagatud pu Buffers on tohutu hulk. Swap'i peamine eesmärk on lihtsalt saata kernel kuhugi, kui meil on probleem. Ja see polnud enam eriti vajalik. Ja siis, mida sa selle keregiga teed? See on juba selline ülesanne, kus pole eriti selge, miks swap sellise suurusega vajalik on.

Kuid kaasaegsetes, st kolmandates tuumaversioonides on käitumine muutunud. Ja kui seadistada swap nulliks, st välja lülitada, siis varem või hiljem hakkab isegi väikese mälusisalduse juures OOM-killer teie juurde tulema, et kõrvaldada kõige intensiivsemad mälukasutajad. Ta arvab, et sellise koormuse korral on meil veel vähe ja me läheme üle, st mitte süsteemi protsessi tappa, vaid tappa midagi vähem tähtsat. Selleks vähem oluliseks osutub intensiivne jagatud mälu kasutaja, nimelt postmaster. Ja peale seda on hea, kui andmebaasi ei pea taastama.

Seetõttu on nüüd vaikesätteid, kui ma õigesti mäletan, enamus distributsioonides umbes 6, st millal hakata swap-i kasutama sõltuvalt sellest, kui palju mälu on jäänud. Käesoleval hetkel soovitame seadistada vm.swappiness = 1, sest see praktiliselt lülitab selle välja, kuid ei põhjusta selliseid efekte, nagu ootamatult saabunud OOM-killer, kes kõik need asjad kõrvaldada.

Mis edasi? Kui räägime andmebaaside jõudlusest ja järk-järgult liigume ketaste poole, hakkavad kõik pead kinni haarama. Sest tõde, et ketas on aeglane ja mälu kiire, on kõigile lapsest peale tuttav. Ja kõik teavad, et andmebaasis on ketta jõudluse probleemid.

Peamine PostgreSQL-i jõudluse probleem, mis on seotud checkpoints'i tõusudega, ei tulene sellest, et ketas on aeglane. Pigem on see tingitud sellest, et mälu ja ketta läbilaskevõime ei ole tasakaalus. Samuti võivad need olla tasakaalus eri kohtades. PostgreSQL ei ole seadistatud, operatsioonisüsteem ei ole seadistatud, riistvara ei ole seadistatud ja riistvara on vale. Seda probleemi ei tekki ainult siis, kui kõik toimub nii nagu peab, st kas koormust ei ole või seadistused ja riistvara on hästi valitud.

Mis see on ja kuidas see välja näeb? Tavaline on, et inimesed, kes töötavad PostgreSQL-iga, on sellesse protsessi korduvalt astunud. Selgitaksin. Nagu ma ütlesin, teeb PostgreSQL perioodiliselt checkpoint'e, et määrdunud lehed jagatud mälust kettale salvestada. Kui meil on suur jagatud mälu maht, hakkab checkpoint intensiivselt kettale mõjuma, sest see salvestab need lehed fsync'i kaudu. Need jõuavad kernel'i puutasse ja kirjutatakse kettale fsync'i abil. Ja kui selle protsessi maht on suur, võime täheldada ebameeldivat efekti, nimelt väga suurt kettakasutust.

Siin on mul kaks pilti. Selgitan nüüd, mis need on. Need on kaks ajaliselt korreleeritud graafikut. Esimene graafik – see on kettakasutus. Siin ulatub see peaaegu 90%-ni antud hetkel. Kui teie andmebaasil on füüsilised kettad ja RAID-kontrolleri kettakasutus on 90% ulatuses, siis on see halvad uudised. See tähendab, et veel natuke ja jõuame 100% ja sisendi-väljundi protsess peatus.

Kui teil on kettamassiiv, siis seal on lugu natuke erinev. Seal sõltub see sellest, kuidas see on seadistatud, milline massiiv see on jne.

Siin on samal ajal konfigureeritud graafik sisemisest postgres'i vaatepunktist, mis näitab, kuidas kontrollpunkt toimub. Roheline värv näitab, kui palju puhverdusi, neid määrdunud lehti, on sellel hetkel kontrollpunktis sünkroniseerimiseks saabunud. See on peamine, mida siin on vaja teada. Näeme, et meil on siin palju lehti saabunud ja mingil hetkel tõukame piiri, st kirjutame-kirjutanud, siin on selgelt kett süsteem väga hõivatud. Kontrollpunkt mõjutab diskimist tugevalt. Ideaalis peaks olukord välja nägema pigem nii, et meil oleks siin vähem kirjutamist. Saame seadistustega seda parandada, et tulevikus nii oleks. St madal kasutamine, kuid midagi me siin kirjutame.

Mida teha, et selle probleemi võita? Kui teie andmebaasi all IO peatub, tähendab see, et kõik kasutajad, kes tulid oma päringute täitmiseks, peavad ootama.

Kui vaadata Linuxi perspektiivist, siis kui oled võtnud hea riistvara, seadisti selle õigesti ning seadisti PostgreSQL nii, et ta teeks checkpoint'e harvemini, lahutades need ajas üksteisest, siis satud debiani vaikesätetele. Enamikus Linuxi distributsioonides on selline pilt: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Mida see tähendab? Alates tuumast 2.6 ilmus üks daemon andmete eemaldamiseks. Pdglush sõltuvalt sellest, kes mida kasutab, tegeleb ta töökeskkonnas mustade lehtede eemaldamisega kernel-buffersist ja eemaldamisega, kui tuleb igal juhul mustade lehtede eemaldamine, kui juba taustal toimub eemaldamine ei aita.

Millal toimub taustaline tegevus? Kui 10% kogu serveri RAM-st on hõivatud mustade lehtedega kernel-bufferis, siis kutsutakse esile eriline funktsioon taustal eemaldamiseks. Miks see on taustaline? Ta võtab parameetrina, kui palju lehti eemaldada. Ja ütleme, et eemaldab N lehte. Ja mõneks ajaks see asi uinub. Siis tuleb see jälle tagasi ja eemaldab veel mingi arvu lehti.

See on ülimalt lihtne lugu. Siin on ülesanne nagu basseiniga, kus ühte toru valatakse, ühest torust voolab välja. Meil on checkpoint ja kui ta on saatnud liiga vähe määrdunud lehti äraviskamiseks, siis need hakkavad järk-järgult kernel bufferist pgflush'ist kenasti laiali minema.

Kui need määrdunud lehed jätkavad kogunemist, kogunevad nad 20%-ni, siis on operatsioonisüsteemil prioriteet need kirjutada kettale, sest toide võib katkeda ja siis on meil kõik halvasti. Kaotame need andmed, näiteks.

Mis on trikk? Trikk seisneb selles, et need parameetrid, 20% ja 10% kogu masina operatiivmälu kohta, on täiesti uskumatu diskisüsteemi läbilaskevõime seisukohast.

Kujutage ette, et teil on 128 GB operatiivmälu. 12,8 GB jõuab teie kettasüsteemi. Ja sõltumata sellest, milline vahemälu teil seal on, ei talu nad nii palju.

Seetõttu soovitame need numbrid seadistada kohe vastavalt teie RAID-kontrolleri võimalustele. Mul on siin kohe soovitus kontrolleriga, millel on 512 MB vahemälu.

Kõik on väga lihtne. Saate vm.dirty_background määrata baitides. Need seaded tühistavad kaks eelnevat. Kas vaikimisi ratio või kui aktiveeritud on need, mis on baitides, siis on need, mis on baitides, jõus. Kuna olen DBA-nõustaja ja töötan erinevate klientidega, püüan ma ettevaatlik olla, seega, kui baitides, siis baitides. Keegi ei andnud mingit garantiid, et hea administraator ei lisa serverile mälu, ei taaskäivita seda ja number jääb samaks. Lihtsalt arvutage need numbrid nii, et kõik mahuks kindlasti sisse.

Mida juhtub, kui te ei pressi? Olen kuulnud, et iga flushimine peatutakse tõhusalt, kuid tegelikult on see kõigest kujundlik väljend. Opsüsteem on suure probleemi keskel – tal on liiga palju määrdunud lehti, seega tõhusalt peatatakse IO, mis on teie klientide päringutest tulenev, st kui rakendus saatis SQL-päringu andmebaasile, ootab see. Kõik sisend-väljund, mis sinna jõuab, on madalaima prioriteediga, kuna andmebaas on kinni checkpoin'is. Ja kui see valmis saab, on täiesti arusaamatu. Ja kui olete jõudnud mitte-taustal, mitte-bakgrep flushimiseni, tähendab see, et kõik teie IO on sellega hõivatud. Ja kuni see pole lõpetatud, ei saa te midagi teha.

Siin on veel kaks olulist punkti, mis jäävad sellest aruandest väljapoole. Need seaded peavad vastama postgresql.conf seadetele, st checkpoint seaded. Ja teie kettasüsteem peab olema nõuetekohaselt konfigureeritud. Kui teil on RAID-i peal vahemälu, peab sellel olema patarei. Inimesed ostavad RAID-i hea vahemäluga ilma patareita. Kui teil on RAID-is SSD-d, peavad need olema serveri SSD-d, seal peavad olema kondensaatorid. Siin on põhjalik kontrollnimekiri. Selle lingi kaudu leiate minu ettekande kohtlemise seadistamisest PostgreSQL-is. Seal on kõik need kontrollnimekirjad.

Mis veel väga palju elu keeruliseks võib teha? Need on kaks parameetrit. Need on suhteliselt uued. Need võivad vaikimisi olla sisse lülitatud erinevates rakendustes. Ja need võivad elu keeruliseks teha sama palju, kui need on valesti sisse lülitatud.

On kaks suhteliselt uut asja. Need ilmuvad juba kolmandates tuumades. Need on sched_migration_cost nanosekundites ja sched_autogroup_enabled, mis vaikimisi on üks.

Ja kuidas need elu rikuvad? Mis on sched_migration_cost? Linuxi ajakava võib migratsiooniprotsessi ühest CPU-st teise. Ja PostgreSQL-i jaoks, mis täidab päringuid, ei ole migreerimine teise CPU-le täiesti selge, miks seda teha. Operatiivsystemi vaatenurgast, kui vahetate aknaid OpenOffice'i ja terminali vahel, võib see olla hea, kuid andmebaasi jaoks – see on väga halb. Seetõttu on mõistlik poliitika seadistada migration_cost mõneks suureks väärtuseks, vähemalt paar tuhat nanosekundit.

Mida see scheduler'ile tähendab? See arvab, et selle aja jooksul on see protsess endiselt aktiivne. St kui teil on mingi pikk tehing, mis võtab aega, siis scheduler saab sellest aru. Ta arvab, et seni, kuni see aegumisaeg pole möödunud, ei ole vaja seda protsessi kuhugi migreerida. Kui protsess sel ajal midagi teeb, siis ei toimu migratsiooni, vaid see lõpetab töö sellel CPU-l, mis on talle määratud. Ja tulemus on suurepärane.

Teine asi on autogroup. On hea idee spetsiifiliste töökoormuste jaoks, mis ei ole seotud kaasaegsete andmebaasidega – gruppida protsessid vastavalt sellele virtuaalsele terminalile, millelt need käivitati. See on mugav mõnede ülesannete jaoks. Praktikas on PostgreSQL mitme protsessi süsteem prefork'iga, mis käivitatakse ühest terminalist. Teil on lukustaja, kontrollpunkt ja kõik teie kliendi päringud rühmitatakse ühele scheduler'ile, ühele CPU-le. Ja nad ootavad seal sõbralikult, kuni see vabaneb, et mitte teineteist segada ja kasutada seda kauem. See on lugu, mis ei ole sellise koormuse korral sugugi vajalik, seega tuleks see välja lülitada.

Minu kolleeg Aleksei Lesovski tegi katseid lihtsa pgbench'iga, kus ta suurendas migration_cost'i järsult ja väljas kirjutas autogroup'i. Halva riistvara puhul tuli vahe peaaegu 10%.. Postgres'i meililistil on arutelu, kus inimesed toovad välja tulemusi, kuidas sellised muudatused mõjutasid päringu kiirus. mõjutasid 50%.. Selliseid lugusid on üsna palju.

Ja lõpetuseks energia salvestamise poliitika. Hästi, et nüüd saab Linuxit kasutada sülearvutis. Ja see peaks tõeliselt hästi akku kasutama. Kuid üllatuslikult selgub, et serverites võib sama olla.

Veelgi enam, kui rendite servereid mõnelt hostimisettevõttelt, siis 'head' hostinguteenuse pakkujad ei hooli sellest, et teil oleks parem jõudlus. Nende ülesanne on tagada, et nende riistvara töötaks maksimaalselt tõhusalt. Seetõttu võivad nad vaikimisi operatsioonisüsteemi abil sisse lülitada sülearvutirežiimi, mis säästab energiat.

Kui kasutate intensiivse koormuse aluseks oleva andmebaasi serveris seda head, siis teie valik on acpi_cpufreq + performance. Isegi ondemand'iga võivad juba olla probleemid.

Intel_pstate on nüüd veidi erinev draiver. Praegu eelistatakse just seda, kuna see on uuenduslikum ja paremini töötav.

Seega on governor ainult performance. Ondemand, powersave ja kõik muu – need ei puuduta teid.

Explain analyze PostgreSQL tulemused võivad erineda mitu korda, kui aktiveerite powersave, sest teie aluses kapoti all ajakava CPU-d täiesti ettearvamatul viisil.

Need asjad võivad olla vaikesätetena sisse lülitatud. Vaadake hoolikalt – ei ole nad vaikimisi sisse lülitatud? See võib olla tõeliselt suur probleem.

Ja lõpuks tahaksin tänada meie DBA meeskonda PostgreSQL-Consulting, nimelt Maks Boguuit ja Aleksei Lesovskit, kes iga päev sellel alal oma vigadest õpivad. Püüame meie klientidele maksimaalselt head teenust pakkuda, et nende süsteemid töötaksid. See on nagu lennunduse ohutusjuhendite puhul. Kõik on siin verega kirjutatud. Iga nende mutri avastamine toimus mingi probleemi käigus. Jagame neid rõõmuga teiega.

Küsimused:

Aitäh! Kui näiteks ettevõte soovib säästa ja käitada ühel serveril andmebaasi ja rakenduse loogikat või kui ettevõte järgib trendi mikroteenuste arhitektuuris, kus PostgreSQL töötab konteineris. Mis on nipiks? Sysctl mõjutab globaalset kogu südamikku. Ma ei ole kuulnud, et sysctl kuidagi virtualiseeritaks, et need töötaksid konteineris eraldi. On ainult cgroup ja seal on ainult osaline kontroll. Kuidas sellega elada? Või kui soovite jõudlust, siis käitage PostgreSQL eraldi raua serveris ja optimeerige seda?

Oleme teie küsimusele vastanud umbkaudu kolme erineva viisiga. Kui jutt ei ole rauaserverist, mida saab optimeerida jne, siis rahunege, kõik töötab hästi ka nende seadistusteta. Kui teil tekib koormus, mis nõuab nende seadistuste tegemist, siis jõuate rauaserverile varem kui nende seadistusteni.

Mis probleem selles on? Kui see on virtuaalmasin, siis on tõenäoliselt mitmeid probleeme, näiteks sellele, et enamikul virtuaalmasinatest on ketta latentsus ebajärjekindel. Isegi kui kettamaht on hea, siis üks ebaõnnestunud sisendi-väljastusoperatsiooni tehing, mis ei mõjuta oluliselt keskmist läbilaskevõimet, võib märkimisväärselt mõjutada andmebaasi, kui see toimub checkpoint'i või WAL-i kirjutamise ajal, ja te märkate seda kiiremini, kui võiks arvata.

Kui teil on NGINX samal serveril, on probleem sama. See võitleb jagatud mäluruumi pärast. Ja te ei jõua siinkohal kirjeldatud probleemideni.

Teiselt poolt teatud parameetrid on siiski teie jaoks olulised. Näiteks, seadistage sysctl dirty_ratio, et see ei oleks nii äärmuslik – igal juhul see aitab. Teie ketta kasutamine toimub mingil viisil. Ja see ei toimi õigesti. Need on üldiselt vaikimisi seadistused, mida ma näitasin. Ja igal juhul on parem neid muuta.

NUMA võib tekitada probleeme. Näiteks töötab VmWare NUMA-ga hästi, kui seaded on täpselt vastupidised. Siin tuleb teha valik – kas raudserver või mitte.

Mul on küsimus, mis on seotud Amazon AWS-iga. Neil on eelkonfigureeritud image. Üks neist on nimetatud Amazon RDS-iks. Kas seal on mingid kohandatud seaded nende operatsioonisüsteemi jaoks?

Seal on seaded, kuid need on teistsugused. Siin seadistame operatsioonisüsteemi selle perspektiivist, kuidas andmebaas seda kasutab. Ja seal on parameetrid, mis määravad, kuhu me praegu suundume, nii-öelda shaping. See tähendab, et me vajame nii palju ressursse, ja me hakkame neid kohe kasutama. Pärast seda ühendab Amazon RDS need ressursid ja seal esineb jõudluse langus. On eraldi juhtumeid, kus inimesed hakkavad sellega eksperimenteerima. Mõnikord isegi üsna edukalt. Kuid see ei ole seotud operatsioonisüsteemi seadistustega. See on nagu pilve häkkimine. See on hoopis teine lugu.

Miks Transparent huge pages ei anna efekti võrreldes Huge TLB-ga?

Nad ei anna. Seda saab selgitada mitmeti, kuid tegelikult nad lihtsalt ei anna seda. Milline on PostgreSQL ajalugu? Ta jagab käivitamisel suure osa jagatud mälust. Kas nad on läbipaistvad või mitte – pole absoluutselt oluline. Fakt, et nad jaotatakse käivitamisel, seletab kõik. Ja kui mälu on väga palju ja tuleb ümber jaotada jagatud mälu segment, siis läbipaistvad suured lehed (Transparent huge pages) saavad asjakohaseks. PostgreSQL jaotab lihtsalt käivitamisel tohutu tüki ja kõik, ja edasi seal midagi erilist ei toimu. Loomulikult on võimalik kasutada, kuid on oht saada jagatud mälu rikutud, kui see peab midagi uuesti jaotama. PostgreSQL ei tea sellest.

Allikas: habr.com