Tööstuslik lähenemine PostgreSQL-i häälestamisele: eksperimendid andmebaasidega ». Nikolai Samohvalov

Soovitame tutvuda Nikolai Samohvalovi ettekande "Tööstuslik lähenemine PostgreSQL-i tuunimisele: eksperimendid andmebaasidega" kokkuvõttega.

Shared_buffers = 25% – kas see on palju või vähe? Või just paras? Kuidas mõista, kas see – üsna vananenud – soovitus sobib teie konkreetsele juhtumile?

On aeg läheneda postgresql.conf parameetrite valimise küsimusele "täiskasvanulikult". Mitte pimedate "autotuunijate" või vananenud nõuannete abil artiklitest ja blogidest, vaid põhinedes:

1. täpselt läbiviidud katsetele andmebaasides, mis viiakse läbi automatiseeritult, suure koguse ning tingimustes, mis on võimalikult lähedased "lahingutingimustele",
2. süvateadmistele DBMS-i ja OS-i toimimistest.

Kasutades Nancy CLI (https://gitlab.com/postgres.ai/nancy), vaatleme konkreetset näidet – tuntud shared_buffers – erinevates olukordades, erinevates projektides ja proovime aru saada, kuidas optimaalselt seadistada meie infrastruktuuri, andmebaasi ja koormust.

Räägime katsetest andmebaasidega. See on lugu, mis kestab veidi üle kuue kuu.

Natuke minust. Kogemus Postgresiga on üle 14 aasta. Olen asutanud mitmeid sotsiaalsete võrgustike ettevõtteid. Ükskõik kus on kasutatud ja kasutatakse Postgresit.

Samuti on RuPostgres grupil Meetup, 2. koht maailmas. Jõuame järk-järgult 2000 inimese lähedale. RuPostgres.org.

Ja erinevate konverentside raames, sealhulgas Highload, vastutan andmebaaside eest, sealhulgas Postgresi eest alates selle asutamisest.

Ja viimase paar aastat olen oma Postgresi konsultatsioonipraktikat taaselustanud 11 ajavööndis.

Ja kui ma seda paar aastat tagasi tegin, oli mul aktiivse käsitöö katkestus Postgresiga, tõenäoliselt alates 2010. aastast. Üllatusin, kui vähe DBA igapäevaelu on muutunud, kui palju on endiselt vaja palju käsitööd. Ja ma mõtlesin kohe, et siin on midagi valesti, peaksime rohkem automatiseerima.

Kuna see kõik toimus kaugjuhtimise teel, olid enamik kliente pilves. Ja palju on juba tõeliselt automatiseeritud. Umbes sellest natuke hiljem. St. kõik see viis mõttele, et peaks olema rida tööriistu, st. mingi platvorm, mis automatiseerib praktiliselt kõik DBA toimingud, et saaks hallata suurt hulka andmebaase.

Selles ettekandes ei käsitleta:

• „Hõbedasi kuulikesi“ ja väiteid, nagu – seadke 8 GB või 25% shared_buffers ja teil on kõik hästi. Shared_buffersi osas ei ole palju juttu.
• Häkkimise "sisutükkid".

Mis siis saab?

• Saavad olema optimeerimise põhimõtted, mida me rakendame ja arendame. Saavad olema erinevad ideed, mis meil teel tekivad, ja erinevad tööriistad, mida me peamiselt Open Source'is loome, st aluse teeme Open Source'is. Veel enam, meil on toetustiketid, peaaegu kogu suhtlus toimib Open Source'is. Saate jälgida, mida me praegu teeme, mis tuleb järgmise väljaandega jne.
• Samuti on olemas teatud kogemus nende põhimõtete, nende tööriistade kasutamisest mitmesugustes ettevõtetes: alates väikestest idufirmadest kuni suurte ettevõteteni.

Kuidas see kõik areneb?

Esiteks, DBA peamine ülesanne, peale instantside loomise tagamise, varukoopiate taastamise jne, on kitsaskohtade leidmine ja jõudluse optimeerimine.

Praegu on see korraldatud nii. Me vaatame jälgimist, näeme midagi, mõned detailid jäävad puudu. Me hakkame süvenema põhjalikumalt, tavaliselt käsitsi, ja mõistame, mida sellega teha.

Ja on kaks lähenemist. Pg_stat_statements on vaikimisi lahendus aeglaste päringute tuvastamiseks. Ja Postgresi logide analüüs pgBadgeriga.

Igal lähenemisel on tõsised puudused. Esimese lähenemise puhul on meil kõik parameetrid kõrvale heidetud. Ja kui me näeme rühmi SELECT * FROM table where veerg on «?» või «$», algusest peale Postgresi versioonis 10, ei tea me – kas see on indeksi skaneerimine või järjestikune skaneerimine. See sõltub väga palju parameetrist. Kui paned sinna harvaesineva väärtuse, on see indeksi skaneerimine. Kui paned sinna väärtuse, mis katab 90% tabelist, on see ilmselgelt järjestikune skaneerimine, sest Postgres tunneb statistikat. Ja see on pg_stat_statements tõsine puudus, kuigi mingid tööd käivad.

Logide analüüsi kõige olulisem puudus on see, et te ei saa endale lubada "log_min_duration_statement = 0", tavaliselt. Ja sellest me räägime ka. Seega, te ei näe kogu pilti. Ja mingi päring, mis on väga kiire, võib tarbida tohutult palju ressursse, kuid te ei näe seda, kuna see jääb teie künnise alla.

Kuidas DBA lahendavad leitud probleemid?

Näiteks leidsime mingi probleemi. Mida tavaliselt tehakse? Kui olete arendaja, siis teete midagi mingis instantsis, mis ei ole nii suures mahus. Kui olete DBA, siis teil on staging. Ja see võib olla ainult üks. Ja ta on kuue kuu võrra maha jäänud. Ja te arvate, et lähete tootmisesse. Ja isegi kogenud DBA-d kontrollivad pärast tootmises, replikas. Ja juhtub, et luuakse ajutine indeks, veendutakse, et see aitab, eemaldatakse see ja antakse arendajatele, et nad saaksid selle migreerimisfailidesse panna. Just selline jaburus toimub praegu. Ja see on häda.

• Konfiguratsioonide häälestamine.
• Indeksite kogumi optimeerimine.
• SQL-päringu muutmine (see on kõige keerulisem viis).
• Ressursside lisamine (enamiku juhtude puhul kõige lihtsam viis).

Sellega on seotud väga palju. Postgresis on palju tööriistu. Tuleb palju teada. Postgresis on palju indekseid, sealhulgas tänu sellele konverentsi korraldajatele. Ja seda kõike tuleb teada, ja see tekitab DBA-de seas tunnet, et DBA-d tegelevad musta maagia. T. e. tuleb kümme aastat tegutseda, et hakata seda normaalselt mõistma.

Ja mina olen selle musta maagia vastane. Ma tahan, et oleks tehnoloogia, mitte oleks kõike intuitiivselt.

Elu näited

Olen seda vähemalt kahes projektis jälginud, sealhulgas oma omas. Järjekordne blogipostitus teatab meile, et väärtus 1 000 default_statistict_target jaoks on hea. Hea, proovime tootmises.

Ja siin me, kasutades oma tööriista kaks aastat hiljem, katsetades andmebaasidega, millest täna räägime, saame võrrelda, mis oli ja mis on saanud.

Ja selleks peame looma eksperimendi. See koosneb neljast osast.

• Esimene – keskkond. Me vajame riistvara. Ja kui ma tulen mõnesse ettevõttesse ja sõlmin lepingu, siis ütlen, et nad annaksid mulle sama riistvara, mis on tootmises. Iga teie meistri jaoks on mul vaja vähemalt ühte sellist riistvara. Olgu see virtuaalne masin Amasonis või Google'is, või tahan ma just sellist riistvara. T. e. tahan taastada keskkonna. Ja keskkonna mõisted hõlmavad Postgressi peaversiooni.
• Teine osa – meie uuringute objekt. See on andmebaas. Seda saab luua mitmel viisil. Näitan, kuidas.
• Kolmas osa – koormus. See on kõige keerulisem hetk.
• Ja neljas osa on see, mida me kontrollime, st millega me võrreldes hakkama saame. Oletame, et me saame konfiguratsioonis muuta ühte või mitut parameetrit, või saame luua indeksi jne.

Me alustame eksperimenti. Siin on pg_stat_statements. Vasakul on see, mis oli. Paremal on see, mis on saanud.

Vasakul on default_statistics_target = 100, paremal = 1 000. Me näeme, et see aitas meid. Üldiselt paranes kõik 8% võrra.

Aga kui me kerime allapoole, siis seal on pgBadgerist või pg_stat_statements'ist pärinevad päringute grupid. Siin on kaks varianti. Me näeme, et mõni päring langes 88%. Ja siin on juba inseneriline lähenemine. Me saame kaevuda sügavamale, sest see on huvitav, miks see langes. Tuleb mõista, mis seal statistikaga oli. Miks suurem hulga kaste statistikates viib halvematele tulemustele.

Või me ei pea kaevama, vaid saame teha "ALTER TABLE ... ALTER COLUMN" ja tuua tagasi 100 kasti selle veeru statistikas. Ja eksperimendi käigus saame veenduda, et see lahendus aitas. Kõik. See on inseneriline lähenemine, mis aitab meil näha pilti ja langetada otsuseid andmete, mitte intuitsiooni põhjal.

Mõned näited teistest valdkondadest. Testides on CI-testid juba aastaid. Ükski projekt ei tohiks enam mõistlikus meelest elada ilma automaatsete testideta.

Teistes tööstusharudes: lennunduses, autotööstuses, kui katsetame aerodünaamikat, on meil samuti võimalik eksperimente teha. Me ei hakka kohe midagi plaanidest kosmosesse saatma ega viima mõnda autot kohe maanteele. Näiteks on olemas aerodünaamiline tunnel.

Teiste valdkondade jälgimistest saame järeldusi teha.

Esiteks on meil spetsiaalne keskkond. See on production'ile lähedane, kuid mitte liiga lähedane. Selle peamine omadus on see, et see peab olema odav, korduv ja maksimaalselt automatiseeritud. Veel peavad olema spetsiaalsed vahendid põhjalikuks analüüsiks.

Tõenäoliselt, kui me lennukit tõstsime ja lendame, on meil vähem võimalusi uurida iga millimeetri ulatust tiiva pinnal kui aerodünaamilises túnnis. Meil on parem varustus diagnostikaks. Me saame lubada rohkem kaalu, mida me ei saa lennuki õhus olles lubada. Niisamuti ka Postgresiga. Me saame mõnel juhul eksperimentide käigus lubada täielikku päringulogimist. Ja me ei soovi seda tootmises teha. Võib-olla aktiveerime selle plaanide kaudu auto_explain abil.

Ja nagu ma ütlesin, kõrge automatiseerimise tase tähendab, et me vajutame nuppu ja kordame. Nii peaks see olema, et oleks palju eksperimente ja see oleks voogesituses.

Nancy CLI – andmebaasistuudio alus

Ja me tegime sellise asja. Ehk siis rääkisin neist ideedest juunis, peaaegu aasta tagasi. Ja meil on juba avatud lähtekoodiga Nancy CLI, mis on alus andmebaasi labori ehitamiseks.

Nancy — See on avatud lähtekoodiga, Gitlabis. Võite öelda, et saate proovida. Andsin selle kohta lingi slaidides. Saate sellele klõpsata ja seal on help kõigis parameetrites.

Muidugi on seal veel palju arenduses. Seal on palju ideid. Kuid see on juba see, mida me rakendame praktiliselt igapäevaselt. Ja kui meil tekib idee – mis juhtub, kui kustutame 40 000 000 rida, ja kõik seisab IO-s, siis saame eksperimendi läbi viia ja süvitsi uurida, et mõista, mis toimub, ning proovida seda jooksvalt parandada. Ehk siis teeme eksperimenti. Näiteks kohandame midagi ja vaatame, mis lõpuks välja tuleb. Ja me ei tee seda tootmises. See on idee sisu.

Kus see võib toimida? See võib töötada kohapeal, st seda saab teha igal pool, isegi MacBookis. Vajalik on docker, saame minna. Ja kõik. Saame selle käivitada mingis instantsis riistvaral või virtuaalmasinas, kus iganes.

Ja on ka võimalus käivitada kaugelt Amazonis EC2 instantsides, spotides. See on väga tore võimalus. Näiteks eile viisime läbi üle 500 eksperimendi i3 instantsiga, alustades kõige nooremast kuni i3-16-xlarge'ni. Ja need 500 eksperimenti maksid meile 64 dollarit. Igaüks kestis 15 minutit. See tähendab, et kuna kasutatakse spote, on see väga odav – 70% allahindlus, Amazonis on sekundipõhine mõõtmine. Te saate teha väga palju. Saate läbi viia tõelist uuringut.

Ja kolme peamise versiooni Postgres toimetatakse. Pole väga keeruline täiendada mõningaid vana ja uut 12. versiooni samuti.

Me saame objekti määrata kolmel viisil. Need on:

• Dump/sql-fail.
• Peamine viis on PGDATA kausta kloonimine. Reeglina võetakse see varunduss serverist. Kui teil on korralikud binaarsed varukoopiad, siis sealt saate kloone teha. Kui teil on pilved, siis teeb teie eest seda pilveteenus, nagu Amazon ja Google. See on peamine meetod reaalse tootmise kloonide jaoks. Me arendame seda viisil.
• Viimane meetod sobib uuringuteks, kui on soov uurida, kuidas Postgresis mingi asi töötab. See on pgbench. Te saate seda genereerida pgbenchiga. See on lihtsalt üks valik 'db-pgbench'. Ütlete, millise skaalaga soovite töödelda. Ja kõik genereeritakse pilves, nagu öeldud.

Ja koormus:

• Koormust saame täita ühe SQL-voo kaudu. See on kõige primitiivsem meetod.
• Või saame emuleerida koormust. Ja emuleerida saame peamiselt järgmisel viisil. Me peame koguma kõik logid. Ja see on valulik. Ma näitan, miks. Ja pgreplay abil, mis on sisse ehitatud Nancy'sse, mängime selle tagasi.
• Või teine variant. Nii nimetatud käsitsi koormus, mida me teeme teatud jõupingutustega. Analüüsides meie praegust koormust tootmissüsteemis, välja tõmmata populaarsed päringugrupid. Ja pgbench abil saame laboratooriumis seda koormust emuleerida.

• Või peame täitma mingi SQL, st me kontrollime mingit migratsiooni, loome indeksi, teostame ANALYZE. Ja vaatame, mis oli enne vaakumist ja pärast vaakumit. Ühesõnaga, mis tahes SQL.
• Või muudame konfiguraatoris ühte või mitut seadet. Saame paluda, et kontrollitaks näiteks 100 väärtust Amazonis meie terabaidi andmebaasi jaoks. Ja mõne tunni pärast on teil tulemus. Üldiselt kestab terabaidi andmebaasi käivitamine mitu tundi. Kuid arenduses on meil patch, meil on võimalik seeria, st saate järjestikku samal serveril kasutada sama pgdata ja kontrollida. Postgres taaskäivitatakse, vahemälu tühi. Ja saate lasta koormust.

• Saabub kataloog, kus on hulk erinevaid faile, alustades pg-snapshots.stat***. Ja seal on kõige huvitavamad – need on pg_stat_statements ja pg_stat_kcacke. Need on kaks laiendust, mis analüüsivad päringuid. Ja pg_stat_bgwriter sisaldab mitte ainult pgwriter statistikat, vaid ka checkpoint'i ja seda, kuidas backend’id ise mustad vahemälud välja tõukavad. Ja seda kõike on huvitav vaadata. Näiteks kui seadistame shared_buffers'i, siis on väga huvitav vaadata, kui palju keegi seal välja tõukab.
• Saabuvad ka Postgresi logid. Kaks logi – ettevalmistuse logi ja koormuse mängimise logi.
• Suhteliselt uus funktsioon – FlameGraphs.
• Samuti, kui olete kasutanud pgreplay või pgbench koormuse mängimise variante, siis tuleb nende originaalne väljund. Ja te näete latentsust ja TPS-i. Saate aru, kuidas nad seda nägid.
• Teave süsteemi kohta.
• Põhilised kontrollid CPU ja IO. See on rohkem EC2 eksemplaride jaoks Amazonis, kui soovite voos käivitada 100 ühesugust eksemplari ja seal jooksutada 100 erinevat katset, siis teil on 10 000 katsetust. Ja peate veenduma, et te ei saa defektset eksemplari, mida keegi juba rõhub. Sellel riistvaral aktiveerivad teised ja teie ressursid jäävad väheseks. Sellised tulemused on parem kõrvaldada. Ja just Aleksei Kopytovi sysbench'i abil teeme mõned lühikesed kontrollid, mis tulevad ja mida saab teistega võrrelda, st saate aru, kuidas CPU ja IO käituvad.

Millised on tehnilised raskused erinevate ettevõtete näitel?

Oletame, et tahame reaalset koormust logide abil korrata. Suurepärane idee, kui see on avatud lähtekoodiga pgreplay’i peale kirjutatud. Me kasutame seda. Kuid et see korralikult töötaks, peate lubama täieliku päringute logimise parameetrite ja ajastusega.

Seal on mõned keerukused duration ja timestamp'i osas. Me jätame selle kõigi köögilisest aspektist kõrvale. Peamine küsimus on – kas saate endale seda lubada või ei saa?

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

Probleem on selles, et see ei pruugi olla saadaval. Te peate esmalt mõistma, millist voogu hakata logima. Kui teil on pg_stat_statements, saate sellise päringu abil (link saadaval esitluses) aru saada, kui palju byte'e kirjutatakse sekundis.

Me vaatame päringu pikkust. Me ei pööra tähelepanu sellele, et seal ei ole parameetreid, kuid me teame päringu pikkust ja teame, kui mitu korda sekundi jooksul see täidetakse. Seega saame umbkaudselt hinnata, kui palju byte'e sekundis. Me võime eksida kaks korda, kuid me saame selle meetodi abil kindlasti umbes arvu teada.

Me näeme, et see päring täidetakse 802 korda sekundis. Ja me näeme, et bytes_per sec – 300 kB/s kirjutatakse pluss miinus. Ja tavaliselt saame sellise voolu endale lubada.

Aga! Asi on selles, et erinevaid logimise süsteeme on palju. Ja vaikimisi kasutavad inimesed tavaliselt 'syslog'.

Ja kui teil on syslog, võib teil olla selline pilt. Võtame pgbench'i, aktiveerime päringute logimise ja vaatame, mis välja tuleb.

Ilma logimiseta – see on vasak pool. Me saime 161 000 TPS. Syslog'i kasutades – see Ubuntu 16.04 Amazonis annab meile 37 000 TPS. Ja kui me muudame spetsiaalsete logimise meetodite kaheks, siis on olukord palju parem. See tähendab, et me ootasime langust, kuid mitte nii suurt.

Ja CentOS 7 puhul, kus ka journald osaleb, muutes logid binaarfookus koopiate otsimiseks jms, on seal olukord tõeliselt kohutav – TPS langeb 44 korda.

Ja see on see, millega inimesed elavad. Ja sageli on ettevõtetes, eriti suurtes, seda väga raske muuta. Kui saate hüpata syslog'ist eemale, siis tehke seda.

• Hinnake IOPS-i ja kirjutamisvoogu.
• Kontrollige oma logimise süsteemi.
• Kui prognoositud koormus on liiga suur, kaaluge sampeldamise varianti.

Meil on pg_stat_statements. Nagu ma ütlesin, peab see kindlasti olema. Ja me saame võtta ja iga päringute rühma spetsiaalselt kirjeldada failis. Ja edasi saame kasutada pgbench'i väga mugavat funktsiooni – mitu faili saab edastada valiku '-f' abil.

Ta mõistab palju «-f». Ja võime öelda «@» abil, kui suur osa igast failist peaks olema. T. e. me saame öelda, et seda teostame 10 % juhtudest, ja seda 20 %. Ja see läheneb meile sellele, mida näeme tootmises.

Kuidas me saame aru, mis meil tootmises on? Kui suur on ja mida? Siin on see natuke kõrvale kaldumine. Meil on veel üks toode. postgres-checkup. Ka see põhineb Open Source'is. Ja me arendame seda aktiivselt.

See tekkis pisut teistel põhjustel. Sellepärast, et monitooring ei ole piisav. T. e. te tulete, vaatate andmebaasi, vaatate olemasolevaid probleeme. Ja tavaliselt teete health_check'i. Kui olete kogenud DBA, siis teete health_check'i. Vaadake indeksite kasutust jne. Kui teil on OKmeter, siis on suurepärane. See on suurepärane monitooring Postgres'i jaoks. OKmeter.io – palun, kasutage seda, seal on kõik väga hästi tehtud. See on tasuline.

Kui seda ei ole, siis tavaliselt on teil vähe, mis on. Monitooringus on tavaliselt ainult CPU, IO ja see ka ettevaatlikult, ja kõik. Aga meil on vaja rohkem. Me peame nägema, kuidas avaküpsetamine töötab, kuidas kontrollpunkt töötab, IO-s tuleb eristada kontrollpunkti bgwriter'ist ja tagurpidi jne.

Probleem on see, et kui sa aitad mingi suure ettevõttega, siis nad ei saa midagi kiiresti rakendada. Ei saa kiiresti osta OKmeterit. Võib-olla ostavad nad selle kuue kuu pärast. Ei saa kiiresti paigaldada mingeid pakette.

Ja meil tuli idee, et me vajame sellist spetsiaalset tööriista, mis ei nõua midagi installimist, t. e. te ei pea tootmisesse midagi installima. Paigaldage see oma sülearvutisse või jälgimisserverisse, kust te seda käivitama hakkate. Ja see analüüsib palju asju: operatsioonisüsteemi, failisüsteemi ja Postgres'i, tehes kergeid päringuid, mida saab tootmises jooksutada ja mis ei põhjusta süsteemi seiskumist.

Me nimetasime selle Postgres-checkup'iks. Kui rääkida arstiteemal, siis see on regulaarne tervisekontroll. Kui rääkida autode teemal, siis see on nagu tehniline ülevaatus. Teete oma autole tehnilise ülevaatuse iga kuue kuu või aasta tagant, olenevalt margist. Aga kas teete tehnilist ülevaatust oma andmebaasile? T. e. kas teete regulaarselt süvaanalüüse? Seda tuleb teha. Kui teete varukoopiaid, siis tehke ka kontroll, see ei ole vähem oluline.

Ja meil on selline tööriist. See hakkas aktiivselt arenema alles kolm kuud tagasi. See on veel noor, kuid seal on palju head.

Kogume kõige „mõjukamad” päringute grupid – K003 aruanne Postgres-checkupis

Ja seal on K gruppide aruanne. Kolm aruannet hetkel. Ja seal on selline aruanne nagu K003. Seal on pg_stat_statements tipp, sorteeritud total_time järgi.

Kui me sorteerime päringute grupid total_time järgi, näeme grupi, mis koormab meie süsteemi kõige enam, st tarbib rohkem ressursse. Miks ma kutsub neid päringute gruppideks? Sest me oleme parameetrid välja visanud. Need pole enam päringud, vaid päringute grupid, st need on abstraktne.

Ja kui me optimeerime ülevalt alla, kergendame oma ressurse ja lükkame edasi hetke, mil peame tegema uuenduse. See on väga hea viis raha säästa.

Võib-olla ei ole see väga hea viis kasutajate hoolitsemiseks, sest me ei pruugi näha harvikuid, kuid väga tüütu juhtumeid, kui inimene ootas 15 sekundit. Kokkuvõttes on need harvad, et me ei näe neid, kuid kasutame ressurssi.

Mis juhtus selle tabeliga? Me tegime kaks snapshots. Postgres_checkup teeb teile delta iga mõõtme jaoks: total-time, calls, rows, shared_blks_read jne. Kõik, delta on arvutatud. pg_stat_statements suur probleem on see, et ta ei mäleta, millal see nulliti. Kui pg_stat_database mäletab, siis pg_stat_statements ei mäleta. Sa näed seal 1 000 000 arvu, kuid kust me selle arvutasime, me ei tea.

Ja siin me teame, meil on kaks snapshots. Me teame, et delta oli selle juhtumi puhul 56 sekundit. Väga väike vahe. Sorteeritud total_time järgi. Edasi saame diferentseerida, st jagame kõik mõõtmed durationiga. Kui me iga mõõtme jagame durationiga, saame kõnede arvu sekundis.

Jätkame total_time sekundis – see on minu lemmik mõõde. See on määratud sekundites, st kui palju sekundeid kulus meie süsteemil selle päringute grupi täitmiseks sekundis. Kui sa seal näed rohkem kui sekund sekundis, tähendab see, et vajad rohkem kui ühe tuuma. See on väga hea mõõde. Sa saad aru, et sellele isikule on näiteks vajalik minimaalselt kolm tuuma.

See on meie know-how, midagi sellist ma pole kuskil näinud. Pange tähele – see on väga lihtne asi – sekund sekundis. Mõnikord, kui teie CPU on 100%, siis pool tundi sekundis, st te tegelesite ainult nende päringutega pool tundi.

Edasi näeme ridade arvu sekundis. Me teame, mitu rida sekundis tagastati.

Ja edasi on veel huvitav asi. Kui palju me shared_buffers-st sekundis lugesime. Hitid olid juba seal, rida saime kas operatsioonisüsteemi vahemälust või kettalt. Esimene variant on kiire, teine võib olla kiire, aga võib ka mitte olla, see sõltub olukorrast.

Teine diferentsieerimise viis on, et jagame selle grupi päringute arvu. Teises veerus on teil alati üks päring, jagatud päringu järgi. Ja siis on huvitav – kui palju millisekundeid oli selle päringu täitmiseks. Me teame, kuidas see päring keskmiselt käitub. Iga päringu jaoks kulus 101 millisekundit. See on traditsiooniline mõõdik, mis on oluline meie arusaamiseks.

Kui palju ridu iga päring keskmiselt tagastas. Näeme, et see grupp tagastab 8. Kui palju keskmiselt vahemälust võeti ja loeti. Näeme, et kõik on ideaalne vahemälus. Esimese grupi jaoks on puhtad hitid.

Ja iga rea neljas alareal on see, kui protsenti koguarvust. Meil on calls. Oletame, et 1 000 000. Ja me saame aru, millise panuse see grupp annab. Näeme, et antud juhul paneb esimene grupp vähem kui 0,01% panuse. See tähendab, et ta on nii aeglane, et me ei näe seda üldpildis. Aga teine grupp – 5% kõigist kutsetest. See tähendab, et 5% kõigist kutsetest on teine grupp.

Total_time kohta on ka huvitav. Esimese grupi päringute jaoks kulus 14% kogu töötamisajast. Teise jaoks 11% jne.

Ma ei süvene detailidesse, aga seal on nüansse. Meie pealtnäha ilmub viga, kuna kui me võrreldes võrdleme, võivad snapshotid nihkuda, st mõned päringud võivad kaduda ja teises enam mitte esineda, ning mõned võivad uued ilmuda. Ja me seal arvutame vea välja. Kui näete 0, siis on kõik hästi. Vigu pole. Kui veaprotsent on kuni 20%, on see OK.

Edasi naaseme meie teema juurde. Me peame koostama töökoormuse. Me läheme ülevalt alla, kuni saavutame 80% või 90%. Tavaliselt on see 10-20 gruppi. Ja teeme failid pgbench jaoks. Seal kasutame random. Mõnikord ei õnnestu see, kahjuks. Ja Postgres 12-s on rohkem võimalusi selle lähenemisviisi kasutamiseks.

Ja ja oleme selliselt kogunud 80–90 % kogu ajast. Mida edaspidi pärast „@“ sisestada? Vaatame kõnesid, vaatame, kui palju protsente ja mõistame, et peaksime olema siin teatud protsendiga. Nendest protsentidest suudame mõista, kuidas iga faili tasakaalustada. Pärast seda kasutame pgbench'i ja hakkame tööle.

Meil on ka K001 ja K002.

K001 on suur string, mis sisaldab nelja alamsõnumeid. See iseloomustab meie koormust. Vaadake teist veergu ja teist alamsõnumit. Näeme, et umbes 1,5 sekundit sekundis, st kui on kaks tuuma, on see hea. Laadimine on umbes 75 %. Ja see töötab nii. Kui meil on 10 tuuma, siis oleme täiesti rahulikud. Nii saame ressursse hinnata.

K002 – see on minu meelest päringute klassid, st SELECT, INSERT, UPDATE, DELETE. Ja eraldi SELECT FOR UPDATE, kuna see lukustab.

Siit saame järeldada, et tavalised SELECT-lugejad moodustavad 82 % kõigist kõnedest, kuid samal ajal 74 % kogu ajast. St neid kutsutakse palju, kuid nad tarvitavad vähem ressursse.

Ja tuleme tagasi küsimuse juurde: „Kuidas valida õigesti shared_buffers?“. Ma olen täheldanud, et enamik teste põhinevad ideel – vaatame, kui palju läbi läheb, st mis on läbilaskevõime. Seda mõõdetakse tavaliselt TPS või QPS-iga.

Ja püüame max õhku välja pigistada kohalt koos seadistuste kaudu, et saada võimalikult palju tehinguid sekundis. Siin on täpselt 311 sekundi kohta SELECT jaoks.

Aga keegi ei sõida tööle ja tagasi koju autoga täis kiirusel. See on rumal. Nii on ka andmebaasidega. Me ei tohiks sõita täiskiirusel, ja keegi ei tee seda. Keegi ei ela produtsioonis, kus on 100% CPU. Kuigi võib-olla keegi elab, aga see pole hea.

Idee on selline, et me sõidame tavaliselt 20% oma võimekusest, soovitatavalt mitte rohkem kui 50%. Ja püüame optimeerida reageerimisaega meie kasutajatele. St me peame keerama oma nuppe nii, et latentsus oleks minimaalne 20% kiirusel, tinglikult. See on idee, mida püüame oma katsetes kasutada.

Ja lõpuks soovitused:

• Kohustuslik on luua Database Lab.
• Võimaluse korral tehke see väljakutsena, et saaks selle mõneks ajaks üles seada – mängida ja kõrvaldada. Kui teil on pilved, siis on see loomulik, st omage palju seisvaid.
• Olge uudishimulikud. Ja kui midagi on valesti, siis kontrollige katsetega, kuidas see käitub. Nancy't saab kasutada, et ise õpetada ja kontrollida, kuidas andmebaas töötab.
• Ja suunake minimaalset reageerimisaega.
• Ja ärge kartke Postgrese lähtekoodi. Kui töötate lähtekoodiga, peate teadma inglise keelt. Seal on väga palju kommentaare, kõik on selgelt seletatud.
• Ja kontrollige andmebaasi tervist regulaarselt, vähemalt kord kolme kuu jooksul käsitsi või Postgres-checkupiga.

Küsimused

Aitäh palju! Väga huvitav teema.

Kaks asja.

Jah, kaks asja. Ainult et ma ei saanud täiesti aru. Kui me Nancy'ga töötame, kas me saame reguleerida vaid ühte parameetrit või terve grupi?

Meil on delfiini konfiguratsiooni parameeter. Saate sinna samaaegselt palju keerata. Kuid tuleb mõista, et kui muudad palju asju, võid vale järelduse teha.

Jah. Miks ma küsisin? Sest on keeruline katsetada, kui sul on vaid üks parameeter. Sa keerad seda, vaatad, kuidas see töötab. Seadistad selle. Siis alustad järgmisega.

Samaaegselt saab reguleerida, kuid see sõltub olukorrast, muidugi. Kuid parem on testida ühe ideed korraga. Eile tuli meil idee. Meil oli väga sarnane olukord. Oli kaks konfiguratsiooni. Ja me ei suutnud aru saada, miks vahe on nii suur. Ja tekkis idee, et on vaja kasutada dikotoomiat, et järjestikku mõista ja leida, kus on erinevus. Saame kohe pool parameetritest üheks muuta, siis veerandi jne. Kõik on paindlik.

Ja on veel küsimus. Projekt on noor, areneb. Kas dokumentatsioon on juba valmis, on üksikasjalik kirjeldus?

Olen seal spetsiaalselt linki teinud parameetrite kirjeldustele. See on olemas. Kuid palju asju pole veel valmis. Otsin kaasosalisi. Ja ma leian neid, kui esinen. See on väga lahe. Keegi juba töötab minuga, keegi aitas ja tegi midagi. Ja kui teid see teema huvitab, andke tagasi side – mida puudub.

Kui jõuame laborisse, võib-olla tuleb ka tagasi side. Vaatame. Aitäh!

Tere! Aitäh ettekande eest! Nägin, et Amazoni tugi on olemas. Kas plaanitakse GSP tuge?

Hea küsimus. Oleme alustanud, kuid oleme selle peatama pannud, kuna soovime kokku hoida. T. e. on olemas tugi, kasutades run on localhost. Saate ise luua instantsi ja töötada kohapeal. Muide, me teeme nii. Getlabi puhul teen ma seda, seal on GSP. Kuid me ei näe mõtet teha just sellist orkestreerimist, kuna Google'il pole soodsaid spote. Seal on ??? instantsi, kuid neil on piirangud. Esiteks, neil on alati ainult 70% allahindlus ja seal ei saa hindadega mängida. Spote tõstame 5-10% võrra, et vähendada tõenäosust, et teid välja visatakse. T. e. spote kasutades saate kokku hoida, kuid neid võidakse teil igal ajal ära võtta. Kui hind on veidi kõrgem kui teistel, võidakse teid hiljem välja visata. Google'il on täiesti erinev eripära. Ja veel on üks väga halb piirang - need elavad ainult 24 tundi. Ja mõnikord tahame katsetusi viia läbi 5 päeva. Kuid spottidega on seda võimalik teha, spote on mõnikord kuud kestnud.

Tere! Aitäh ettekande eest! Mainisite checkup'i. Kuidas te arvutate stat_statements vigu?

Tõeliselt hea küsimus. Ma saan väga üksikasjalikult näidata ja rääkida. Lühidalt - vaatame, kuidas grupi päringud liikuma hakkavad: kui palju on kadunud ja kui palju uusi on tulnud. Ja seejärel vaatame kahte mõõdikut: total_time ja calls, seega on seal kaks viga. Ja vaatame, milline on kadunud gruppide panus. Seal on kaks alagruppi: läinud ja tulnud. Vaatame, milline on nende panus kogu pildis.

Kas te ei karda, et see toob seal kaks-kolm korda ringi aega, mis jääb snäpshotide vahel?

T. e. nad registreerusid uuesti või kuidas?

Näiteks, see päring on juba kord väljatõrjutud, seejärel tuli tagasi ja tõrjus jälle välja, seejärel tuli veel kord tagasi ja tõrjus jälle välja. Ja te arvutasite midagi, ja kus see kõik on?

Hea küsimus, tuleb uurida.

Ma tegin sarnast asja. Loomulikult tegin ma selle lihtsamaks üksi. Kuid pidin resettima, tegema reset stat_statements ja orienteeruma snäpshoti hetkel, et seal oleks vähem teatud osa, et see ei oleks veel saavutanud piiri, kui palju stat_statements võib koguda. Ja ma orienteerun, et tõenäoliselt ei ole midagi välja tõrjutud.

Jah-jah.

Aga kuidas muidu usaldusväärselt teha ma ei saa aru.

Kahjuks ei mäleta ma täpselt - kas me kasutame seal päringu teksti või queryid pg_stat_statements ja sellele orienteerume. Kui me orienteerume queryid, siis teoreetiliselt võrreldame me võrreldavaid asju.

Ei, ta võib mitmeid kordi vahepeal lõppeda ja uuesti tulla.

Sama ID-ga?

Jah.

Me uurime seda. Hea küsimus. Peame uurima. Aga praegu, mida näeme, on meil kas 0 kirjutatud...

See on muidugi haruldane juhtum, aga mind jahmatas, kui sain teada, et stat_statements võib seal lõppeda.

Pg_stat_statements-s võib olla palju erinevaid asju. Oleme kogenud, et kui teil on track_utility = on, siis teie komplektid jälgitakse ka.

Jah, muidugi.

Ja kui teil on Java Hibernate, mis on juhuslik, siis seal hakkab hash-tabel lukustuma. Ja kui te lülitate välja väga koormatud rakenduse, on teil 50-100 gruppi. Ja seal on enam-vähem kõik stabiilne. Üks viis selle vastu võitlemiseks on suurendada pg_stat_statements.max.

Jah, aga peate teadma, kui palju. Ja kuidagi peab sellega tegelema. Mina teen nii. St mul on pg_stat_statements.max. Ja vaatan, et ma ei ole hetkeseisuga jõudnud 70% -ni. Hästi, see tähendab, et me ei kaotanud midagi. Teeme reset'i. Ja kogume jälle. Kui järgmises hetkeseisus on alla 70%, siis tähendab see, et tõenäoliselt ei kaotanud me jälle midagi.

Jah. Vaikimisi on praegu 5000 ja paljudele sellest piisab.

Tavaliselt – jah.

Video:

P.S. Lisaks ütlen, et kui Postgres sisaldab konfidentsiaalseid andmeid, mis ei tohi testkeskkonda sattuda, siis saab kasutada PostgreSQL Anonymizer. Skeem on ligikaudu järgmine:

Allikas: habr.com