Soovitan teil lugeda Nikolai Samohvalovi raporti "Tööstuslik lähenemine PostgreSQL-i häälestamisele: andmebaaside katsed" ärakirja.
Shared_buffers = 25% – kas seda on palju või vähe? Või just õige? Kuidas teate, kas see – üsna aegunud – soovitus on teie konkreetsel juhul asjakohane?
On aeg läheneda postgresql.confi parameetrite valimise küsimusele "nagu täiskasvanu". Mitte pimedate "automaathäälestajate" või artiklite ja ajaveebi vananenud nõuannete abil, vaid tuginedes:
- rangelt kontrollitud katsed andmebaasides, mis viiakse läbi automaatselt, suurtes kogustes ja tingimustes, mis on võimalikult lähedased "võitlemistele",
- DBMS-i ja OS-i funktsioonide sügav mõistmine.
Kasutades Nancy CLI (), vaatleme konkreetset näidet – kurikuulsaid jagatud_puhvreid – erinevates olukordades, erinevates projektides ning püüame välja mõelda, kuidas valida meie infrastruktuuri, andmebaasi ja koormuse jaoks optimaalne seade.
Räägime katsetest andmebaasidega. See on lugu, mis kestab veidi üle kuue kuu.
Natuke minust. Töökogemus Postgresiga üle 14 aasta. On asutatud mitmeid suhtlusvõrgustike ettevõtteid. Postgresi kasutati ja kasutatakse kõikjal.
Samuti RuPostgresi grupp Meetupil, 2. koht maailmas. Vaikselt läheneme 2 inimesele. RuPostgres.org.
Ja erinevate konverentside arvutites, sealhulgas Highloadis, vastutan andmebaaside, eriti Postgresi eest algusest peale.
Ja viimastel aastatel olen taaskäivitanud oma Postgresi nõustamispraktika 11 ajavööndi kaugusel siit.
Ja kui ma seda paar aastat tagasi tegin, oli mul aktiivses füüsilises töös Postgresiga väike paus, ilmselt alates 2010. aastast. Olin üllatunud, kui vähe on DBA töörutiin muutunud ja kui palju on vaja veel käsitsi tööd kasutada. Ja ma mõtlesin kohe, et siin on midagi valesti, pean kõike rohkem automatiseerima.
Ja kuna see kõik oli kauge, oli enamik kliente pilvedes. Ja ilmselt on palju juba automatiseeritud. Sellest lähemalt hiljem. See tähendab, et selle kõige tulemusel tekkis idee, et peaks olema mitmeid tööriistu, st mingi platvorm, mis automatiseerib peaaegu kõik DBA toimingud, et saaks hallata suurt hulka andmebaase.
See aruanne ei sisalda:
- “Hõbedad täpid” ja avaldused nagu – määrake 8 GB või 25% jagatud_puhvreid ja kõik on korras. Share_buffers'ist pole palju juttu.
- Kõvad "sisemised".
Mis juhtub?
- Seal on optimeerimispõhimõtted, mida me rakendame ja arendame. Teel tekib igasuguseid ideid ja erinevaid tööriistu, mille loome suures osas avatud lähtekoodiga ehk loome aluse avatud lähtekoodiga. Pealegi on meil piletid, kogu suhtlus on praktiliselt avatud lähtekoodiga. Näete, millega me praegu tegeleme, mis tuleb järgmises väljaandes jne.
- Samuti on nende põhimõtete, tööriistade kasutamise kogemus paljudes ettevõtetes: alates väikestest alustavatest ettevõtetest kuni suurte ettevõteteni.
Kuidas see kõik areneb?
Esiteks on DBA põhiülesanne lisaks eksemplaride loomise, varukoopiate juurutamise jms tagamisele kitsaskohtade leidmine ja jõudluse optimeerimine.
Nüüd on see nii seadistatud. Vaatame monitooringut, midagi näeme, aga mõned detailid on puudu. Hakkame hoolikamalt kaevama, tavaliselt kätega, ja mõistame, mida sellega ühel või teisel viisil peale hakata.
Ja on kaks lähenemist. Pg_stat_statements on vaikelahendus aeglaste päringute tuvastamiseks. Ja Postgresi logide analüüs pgBadgeri abil.
Igal lähenemisviisil on tõsiseid puudusi. Esimesel lähenemisel oleme kõik parameetrid välja visanud. Ja kui näeme rühmi SELECT * FROM, kus veerg on võrdne "?" või "$" alates Postgres 10-st. Me ei tea, kas see on indeks- või järgskannimine. Oleneb väga palju parameetrist. Kui asendate seal harva esineva väärtuse, on tegemist indeksi skannimisega. Kui asendate väärtuse, mis hõlmab 90% tabelist, on seq-skannimine ilmne, sest Postgres teab statistikat. Ja see on pg_stat_statements suur puudus, kuigi töö on pooleli.
Logianalüüsi suurim miinus on see, et te ei saa endale reeglina lubada "log_min_duration_statement = 0". Ja me räägime ka sellest. Sellest tulenevalt ei näe te tervikpilti. Ja mõni päring, mis on väga kiire, võib kulutada tohutult ressursse, kuid te ei näe seda, kuna see on alla teie läve.
Kuidas DBA-d leitud probleeme lahendavad?
Näiteks leidsime mõne probleemi. Mida tavaliselt tehakse? Kui olete arendaja, teete mõnel eksemplaril midagi, mis ei ole sama suur. Kui olete DBA, siis on teil lavastus. Ja neid saab olla ainult üks. Ja ta jäi kuus kuud maha. Ja sa arvad, et lähed tootmisse. Ja isegi kogenud DBA-d registreerivad seejärel tootmist koopias. Ja juhtub, et nad loovad ajutise indeksi, veenduvad, et see aitab, jätavad selle maha ja annavad selle arendajatele, et nad saaksid selle migratsioonifailidesse panna. See on selline jama, mis praegu toimub. Ja see on probleem.
- Häälestage konfiguratsioone.
- Optimeerige indeksite komplekt.
- Muutke SQL-päringut ennast (see on kõige keerulisem meetod).
- Lisage mahtu (enamikul juhtudel lihtsaim viis).
Nende asjadega toimub palju. Postgresis on palju käepidemeid. On palju teada. Postgres on palju indekseid, tänu ka selle konverentsi korraldajatele. Ja seda kõike tuleb teada ning just see paneb mitte-DBA-d tundma, et DBA-d harrastavad musta maagiat. See tähendab, et kõigest sellest normaalselt aru saamiseks peate õppima 10 aastat.
Ja ma olen selle musta maagia vastu võitleja. Ma tahan teha kõik nii, et tehnoloogia oleks olemas ja selles kõiges ei oleks intuitsiooni.
Näited päris elust
Märkasin seda vähemalt kahes projektis, sealhulgas enda omas. Veel üks blogipostitus ütleb meile, et default_statistict_target väärtus 1 on hea. Olgu, proovime seda tootmises.
Ja siin me oleme, kasutades oma tööriista kaks aastat hiljem, täna kõneldavate andmebaaside katsete abil saame võrrelda, mis oli ja mis on saanud.
Ja selleks peame looma katse. See koosneb neljast osast.
- Esimene on keskkond. Vajame riistvara. Ja kui ma tulen mõnda firmasse ja sõlmin lepingu, siis ütlen, et andke mulle sama riistvara, mis tootmises. Iga teie meistri jaoks on mul vaja vähemalt ühte sellist riistvara. Kas see on Amazoni või Google'i virtuaalmasin või vajan täpselt sama riistvara. See tähendab, et ma tahan keskkonda uuesti luua. Ja keskkonna kontseptsiooni hõlmame Postgresi põhiversiooni.
- Teine osa on meie uurimistöö objekt. See on andmebaas. Seda saab luua mitmel viisil. Ma näitan teile, kuidas.
- Kolmas osa on koormus. See on kõige raskem hetk.
- Ja neljas osa on see, mida me kontrollime, st mida me millega võrdleme. Oletame, et saame konfiguratsioonis muuta üht või mitut parameetrit või luua indeksi jne.
Käivitame katse. Siin on pg_stat_statements. Vasakul on see, mis juhtus. Paremal - mis juhtus.
Vasakul vaikimisi_statistika_siht = 100, paremal = 1. Näeme, et see aitas meid. Kokkuvõttes läks kõik 000% paremaks.
Kui aga alla kerida, on pgBadgeri või pg_stat_statementsi päringute rühmad. On kaks võimalust. Näeme, et mõni taotlus on langenud 88%. Ja siit tuleb insenerlik lähenemine. Saame seest edasi kaevata, sest imestame, miks see uppus. Peate mõistma, mis statistikaga juhtus. Miks toob statistika rohkem ämbreid halvemate tulemusteni?
Või me ei saa kaevata, vaid teeme "ALTER TABLE ... ALTER COLUMN" ja tagastame 100 ämbrit selle veeru statistikasse. Ja siis saame teise katsega veenduda, et see plaaster aitas. Kõik. See on insenertehniline lähenemine, mis aitab meil näha üldist pilti ja teha otsuseid pigem andmete kui intuitsiooni põhjal.
Paar näidet teistest piirkondadest. CI-teste on testimisel olnud palju aastaid. Ja ükski täie mõistuse juures projekt ei elaks ilma automaattestideta.
Teistes tööstusharudes: lennunduses, autotööstuses, kui testime aerodünaamikat, on meil võimalus teha ka katseid. Me ei lase midagi jooniselt otse kosmosesse ega vii mõnda autot kohe rajale. Näiteks on seal tuuletunnel.
Järeldusi saame teha teiste tööstusharude vaatlustest.
Esiteks on meil eriline keskkond. See on tootmisele lähedal, kuid mitte lähedal. Selle peamine omadus on see, et see peaks olema odav, korratav ja võimalikult automatiseeritud. Ja üksikasjaliku analüüsi tegemiseks peavad olema ka spetsiaalsed tööriistad.
Tõenäoliselt on meil lennukit lendades ja lennates vähem võimalusi uurida tiiva pinna iga millimeetrit kui tuuletunnelis. Meil on rohkem diagnostikavahendeid. Saame endale lubada raskemate asjade vedamist, mida me ei saa endale lubada õhus lennukisse panna. Sama ka Postgresiga. Mõnel juhul võime katsete ajal lubada päringute täieliku logimise. Ja me ei taha seda tootmises teha. Võime isegi plaanida selle lubada kasutades auto_explain.
Ja nagu ma ütlesin, tähendab kõrge automatiseerituse tase seda, et vajutame nuppu ja kordame. Nii peabki olema, et oleks palju katsetamist, et oleks voolus.
Nancy CLI - "andmebaasilabori" alus
Ja nii me selle asja tegime. See tähendab, et ma rääkisin nendest ideedest juunis, peaaegu aasta tagasi. Ja meil on juba avatud lähtekoodiga nn Nancy CLI. See on andmebaasilabori ehitamise alus.
- See on avatud lähtekoodiga Gitlabis. Võite seda öelda, võite proovida. Panin slaididesse lingi. Võite sellel klõpsata ja see on seal igas suhtes.
Muidugi on palju veel arendamisel. Seal on palju ideid. Kuid me kasutame seda peaaegu iga päev. Ja kui meil on idee – miks on nii, et kui kustutame 40 000 000 rida, taandub see kõik IO-le, siis saame läbi viia katse ja vaadata üksikasjalikumalt, et mõista, mis toimub ja seejärel proovida seda liikvel olles parandada. See tähendab, et teeme katse. Näiteks näpime midagi ja vaatame, mis lõpuks saab. Ja me ei tee seda tootmises. See on idee olemus.
Kus see toimida saab? See võib töötada kohapeal, st saate seda teha kõikjal, saate seda isegi MacBookis käivitada. Meil on dokkerit vaja, lähme. See on kõik. Saate seda mingil juhul käivitada riistvaraosas või virtuaalses masinas, kus iganes.
Ja EC2 eksemplaris on ka võimalus Amazonis kaugjuhtimisega joosta. Ja see on väga lahe võimalus. Näiteks tegime eile i500 instancel üle 3 katse, alustades noorimast ja lõpetades i3-16-xlarge'iga. Ja 500 katset maksid meile 64 dollarit. Kumbki kestis 15 minutit. Ehk tänu sellele, et seal spotte kasutatakse, on see väga odav – 70% allahindlus, Amazoni sekundipõhine arveldus. Saate teha palju. Saate teha tõelisi uuringuid.
Ja toetatud on Postgresi kolm peamist versiooni. Mõne vana ja ka uue 12. versiooni lõpetamine pole nii keeruline.
Objekti saame määratleda kolmel viisil. See:
- Dump/sql fail.
- Peamine viis on PGDATA kataloogi kloonimine. Reeglina võetakse see varuserverist. Kui teil on tavalised binaarsed varukoopiad, saate sealt kloone teha. Kui teil on pilved, teeb seda teie eest pilvekontor nagu Amazon ja Google. See on kõige olulisem viis tegeliku tootmise kloonimiseks. Nii me lahti rullume.
- Ja viimane meetod sobib uurimistööks, kui tahad aru saada, kuidas miski Postgresis töötab. See on pgbench. Saate luua pgbenchi abil. See on vaid üks "db-pgbench" valik. Ütle talle, mis mõõtkavas. Ja kõik genereeritakse pilves, nagu öeldud.
Ja laadige:
- Koormuse saame teostada ühes SQL-lõimes. See on kõige primitiivsem viis.
- Ja me saame koormust jäljendada. Ja me saame seda kõigepealt jäljendada järgmisel viisil. Peame kõik palgid kokku koguma. Ja see on valus. Ma näitan sulle, miks. Ja pgreplay abil mängime, mis on Nancy sisse ehitatud.
- Või mõni muu variant. Nn käsitöökoormus, mida teeme teatud pingutusega. Analüüsides meie praegust koormust lahingusüsteemile, tõmbame välja parimad taotluste rühmad. Ja pgbenchi abil saame seda koormust laboris jäljendada.
- Kas me peame sooritama mingi SQL-i, st kontrollime mingit migratsiooni, loome sinna indeksi, käivitame seal ANALAZE. Ja me vaatame, mis juhtus enne vaakumit ja pärast vaakumit. Üldiselt mis tahes SQL.
- Kas muudame konfiguratsioonis ühte või mitut parameetrit. Võime öelda, et kontrolliksime näiteks 100 väärtust Amazonis oma terabaidise andmebaasi jaoks. Ja mõne tunni pärast on tulemus käes. Reeglina kulub terabaidise andmebaasi juurutamiseks mitu tundi. Kuid arenduses on plaaster, meil on võimalik seeria, st saate järjepidevalt kasutada sama pgdata-d samas serveris ja kontrollida. Postgres taaskäivitub ja vahemälud lähtestatakse. Ja saate koormat juhtida.
- Saabub kataloog koos hulga erinevate failidega, alustades pg-hetktõmmistestriik***. Ja kõige huvitavam on pg_stat_statements, pg_stat_kcacke. Need on kaks laiendust, mis analüüsivad päringuid. Ja pg_stat_bgwriter ei sisalda mitte ainult pgwriteri statistikat, vaid ka kontrollpunkti ja seda, kuidas taustaprogrammid ise määrdunud puhvreid välja tõrjuvad. Ja seda kõike on huvitav vaadata. Näiteks jagatud_puhvrite seadistamisel on väga huvitav näha, kui palju kõik asendasid.
- Saabuvad ka Postgresi palgid. Kaks logi – ettevalmistuspäevik ja koormuse taasesituse logi.
- Suhteliselt uus funktsioon on FlameGraphs.
- Samuti, kui kasutasite koormuse esitamiseks suvandeid pgreplay või pgbench, on nende väljund algne. Ja näete latentsust ja TPS-i. Saab aru, kuidas nad seda nägid.
- Süsteemi info.
- Põhilised CPU ja IO kontrollid. See on rohkem Amazoni EC2 eksemplari jaoks, kui soovite käivitada lõimes 100 identset eksemplari ja käivitada seal 100 erinevat käitamist, siis on teil 10 000 katset. Ja peate veenduma, et te ei puutu kokku vigase eksemplariga, mida keegi juba rõhub. Teised on selle riistvaraga aktiivsed ja teil on jäänud vähe ressursse. Parem on sellised tulemused kõrvale jätta. Ja Alexey Kopytovi sysbenchi abiga teeme mitmeid lühikesi kontrolle, mis tulevad ja mida saab teistega võrrelda, st saate aru, kuidas CPU käitub ja kuidas IO käitub.
Millised on tehnilised raskused erinevate ettevõtete näitel?
Oletame, et tahame logide abil tegelikku koormust korrata. See on suurepärane idee, kui see on kirjutatud avatud lähtekoodiga pgreplay. Me kasutame seda. Kuid selleks, et see hästi töötaks, peate lubama täieliku päringu logimise koos parameetrite ja ajastusega.
Kestuse ja ajatempliga kaasnevad mõned komplikatsioonid. Tühjendame kogu selle köögi. Peamine küsimus on, kas saate seda endale lubada või mitte?
Probleem on selles, et see ei pruugi olla saadaval. Kõigepealt peate mõistma, milline voog logisse kirjutatakse. Kui teil on pg_stat_statements, saate seda päringut kasutada (link on saadaval slaididel), et mõista, mitu baiti sekundis umbes kirjutatakse.
Vaatame taotluse pikkust. Jätame tähelepanuta asjaolu, et parameetreid pole, kuid me teame päringu pikkust ja teame, mitu korda sekundis seda täideti. Nii saame ligikaudselt hinnata, mitu baiti sekundis. Me võime eksida kaks korda rohkem, kuid kindlasti saame niimoodi järjekorrast aru.
Näeme, et seda päringut täidetakse 802 korda sekundis. Ja me näeme, et bytes_per sec – 300 kB/s kirjutatakse pluss või miinus. Ja reeglina saame sellist voolu endale lubada.
Aga! Fakt on see, et logisüsteeme on erinevaid. Ja inimeste vaikimisi on tavaliselt "syslog".
Ja kui teil on syslog, võib teil olla selline pilt. Kasutame pgbenchi, lubame päringu logimise ja vaatame, mis juhtub.
Ilma logimiseta - see on vasakpoolne veerg. Saime 161 000 TPS-i. Syslogiga - see on Amazoni Ubuntu 16.04-s, saame 37 000 TPS-i. Ja kui minna üle kahele muule raiemeetodile, on olukord palju parem. See tähendab, et me eeldasime, et see langeb, kuid mitte samal määral.
Ja CentOS 7-s, milles osaleb ka Journald, muutes logid hõlpsaks otsimiseks binaarvormingusse jne, on see õudusunenägu, langeme TPS-is 44 korda.
Ja sellega inimesed elavadki. Ja sageli ettevõtetes, eriti suurtes, on seda väga raske muuta. Kui saate syslogist eemale, siis palun hoiduge sellest.
- Hinnake IOPS-i ja kirjutage voogu.
- Kontrollige oma logisüsteemi.
- Kui prognoositav koormus on liiga suur, kaaluge proovivõttu.
Meil on pg_stat_statements. Nagu ma ütlesin, peab see seal olema. Ja iga taotluste rühma saame failis erilisel viisil võtta ja kirjeldada. Ja siis saame pgbenchis kasutada väga mugavat funktsiooni - võimalust sisestada mitu faili, kasutades suvandit “-f”.
See mõistab palju "-f". Ja lõpus oleva "@" abil saate öelda, milline jagamine peaks igal failil olema. See tähendab, et võime seda teha 10% juhtudest ja seda 20% juhtudest. Ja see toob meid lähemale sellele, mida me tootmises näeme.
Kuidas mõistame, mis meil tootmises on? Mis osa ja kuidas? See on natuke kõrval. Meil on veel üks toode . Samuti avatud lähtekoodiga baas. Ja nüüd arendame seda aktiivselt.
Ta sündis veidi erinevatel põhjustel. Põhjustel, et jälgimisest ei piisa. See tähendab, et tuled, vaatad baasi, vaatad olemasolevaid probleeme. Ja reeglina teete tervisekontrolli. Kui olete kogenud DBA, siis teete tervisekontrolli. Vaatasime indeksite kasutamist jne. Kui sul on OKmeter, siis suurepärane. See on Postgresi jaoks lahe jälgimine. OKmeter.io – palun installi, seal on kõik väga hästi tehtud. See on tasuline.
Kui sul seda pole, siis tavaliselt pole ka palju. Seires on tavaliselt CPU, IO ja siis reservatsioonidega ja see on kõik. Ja me vajame rohkem. Peame nägema, kuidas autovaakum töötab, kuidas kontrollpunkt töötab, io-s peame eraldama kontrollpunkti bgwriterist ja taustaprogrammidest jne.
Probleem on selles, et kui aitad suurt ettevõtet, ei suuda nad midagi kiiresti ellu viia. Nad ei saa OKmeterit kiiresti osta. Võib-olla ostavad nad selle kuue kuu pärast. Nad ei saa mõnda pakki kiiresti kohale toimetada.
Ja tulime ideele, et vajame spetsiaalset tööriista, mille paigaldamine ei nõua midagi, st te ei pea tootmisel üldse midagi installima. Installige see oma sülearvutisse või vaatlusserverisse, kust seda käivitate. Ja see analüüsib paljusid asju: operatsioonisüsteemi, failisüsteemi ja Postgresi ennast, tehes mõned kerged päringud, mida saab käivitada otse tootmisse ja miski ei ebaõnnestu.
Me nimetasime seda Postgres-checkupiks. Meditsiinilises mõttes on see regulaarne tervisekontroll. Kui see on autoteemaline, siis on see nagu hooldus. Hooldad oma autot olenevalt margist iga kuue kuu või aasta tagant. Kas teete oma baasi hooldust? See tähendab, kas teete regulaarselt põhjalikku uurimistööd? Seda tuleb teha. Kui teete varukoopiaid, siis tehke kontroll, see pole vähem oluline.
Ja meil on selline tööriist. See hakkas aktiivselt esile kerkima alles umbes kolm kuud tagasi. Ta on veel noor, aga seal on palju.
Kõige "mõjukamate" päringurühmade kogumine - aruanne K003 Postgres-checkupis
Ja seal on rühm aruandeid K. Seni kolm aruannet. Ja seal on selline aruanne K003. Ülemine osa on jaotisest pg_stat_statements, mis on sorteeritud kogu_aja järgi.
Kui sorteerime päringurühmi total_time järgi, näeme ülaosas rühma, mis meie süsteemi kõige rohkem laadib, st tarbib rohkem ressursse. Miks ma panen päringurühmadele nimed? Sest me viskasime parameetrid välja. Need ei ole enam päringud, vaid taotluste rühmad, st need on abstraheeritud.
Ja kui optimeerime ülalt alla, vähendame oma ressursse ja viivitame hetke, mil meil on vaja uuendada. See on väga hea viis raha säästmiseks.
Võib-olla pole see väga hea viis kasutajate eest hoolitsemiseks, sest me ei pruugi näha haruldasi, kuid väga tüütuid juhtumeid, kus inimene ootas 15 sekundit. Kokkuvõttes on need nii haruldased, et me neid ei näe, aga tegeleme ressurssidega.
Mis selles tabelis juhtus? Tegime kaks pilti. Postgres_checkup annab teile iga mõõdiku delta: koguaeg, kõned, read, jagatud_blks_lugemine jne. See on kõik, delta on arvutatud. Pg_stat_statementsi suur probleem on see, et see ei mäleta, millal see lähtestati. Kui pg_stat_database mäletab, siis pg_stat_statements ei mäleta. Näete, et seal on arv 1 000 000, kuid me ei tea, kust me lugesime.
Ja siin me teame, siin on meil kaks hetkepilti. Teame, et antud juhul oli delta 56 sekundit. Väga lühike vahe. Sorteeritud summa_aja järgi. Ja siis saame eristada, st jagame kõik mõõdikud kestuse järgi. Kui jagame iga mõõdiku kestusega, saame kõnede arvu sekundis.
Järgmiseks on minu lemmikmõõdik kogu_aeg sekundis. Seda mõõdetakse sekundites sekundis, st mitu sekundit kulus meie süsteemil selle päringurühma täitmiseks sekundis. Kui näete seal rohkem kui sekundit sekundis, tähendab see, et pidite andma rohkem kui ühe tuuma. See on väga hea mõõdik. Saate aru, et see sõber vajab näiteks vähemalt kolme tuuma.
See on meie oskusteave, ma pole kunagi midagi sellist kuskil näinud. Pange tähele – see on väga lihtne asi – sekund sekundis. Mõnikord, kui teie protsessor on 100%, siis pool tundi sekundis, st kulutasite pool tundi just nende taotluste täitmisele.
Järgmisena näeme ridu sekundis. Teame, mitu rida sekundis see tagasi tuli.
Ja siis on ka üks huvitav asi. Mitu jagatud_puhvrit me loeme sekundis jagatud_puhvritest endast. Tabamused olid juba olemas ja võtsime read operatsioonisüsteemi vahemälust või kettalt. Esimene võimalus on kiire ja teine võib olenevalt olukorrast olla kiire või mitte.
Ja teine eristamise viis on selles rühmas taotluste arvu jagamine. Teises veerus on alati üks päring jagatud päringu kohta. Ja siis on huvitav – mitu millisekundit selles taotluses oli. Teame, kuidas see päring keskmiselt käitub. Iga päringu jaoks kulus 101 millisekundit. See on traditsiooniline mõõdik, mida peame mõistma.
Mitu rida iga päring keskmiselt tagastas? Näeme 8, et see grupp naaseb. Keskmiselt kui palju vahemälust võeti ja loeti. Näeme, et kõik on ilusti vahemällu salvestatud. Esimese grupi kindlad tabamused.
Ja iga rea neljas alamstring on mitu protsenti kogusummast. Meil on kõnesid. Oletame, et 1 000 000. Ja me saame aru, millise panuse see grupp annab. Näeme, et sel juhul annab esimene rühm alla 0,01%. See tähendab, et see on nii aeglane, et me ei näe seda üldpildis. Ja teine grupp on 5% kõnedest. See tähendab, et 5% kõigist kõnedest on teine rühm.
Kokku_aeg on samuti huvitav. Esimesele taotluste rühmale kulutasime 14% oma kogu tööajast. Ja teisele - 11% jne.
Ma ei lasku detailidesse, kuid seal on peensusi. Kuvame ülaosas vea, kuna võrdlemisel võivad hetktõmmised hõljuda, see tähendab, et mõned päringud võivad välja kukkuda ja teises ei saa enam olla, samas võib ilmuda mõni uus. Ja seal arvutame vea. Kui näete 0, on see hea. Vigu pole. Kui veamäär on kuni 20%, on kõik korras.
Seejärel pöördume tagasi oma teema juurde. Peame töökoormust kujundama. Me võtame selle ülalt alla ja liigume, kuni jõuame 80% või 90% -ni. Tavaliselt on see 10-20 rühma. Ja me teeme faile pgbenchi jaoks. Me kasutame seal juhuslikult. Mõnikord see kahjuks ei õnnestu. Ja Postgres 12-s on selle lähenemisviisi kasutamiseks rohkem võimalusi.
Ja siis võidame sel viisil koguaega 80-90%. Mida peaksin pärast @-d järgmiseks panema? Vaatame kõnesid, näeme, kui suur on huvi ja mõistame, et oleme siin nii palju intressi võlgu. Nendest protsentidest saame aru, kuidas iga faili tasakaalustada. Peale seda kasutame pgbenchi ja läheme tööle.
Meil on ka K001 ja K002.
K001 on üks suur string nelja alamstringiga. See on kogu meie koormusele iseloomulik. Vaadake teist veergu ja teist alamrida. Näeme, et umbes poolteist sekundit sekundis, st kui on kaks südamikku, siis on hea. Mahutavus on umbes 75%. Ja see toimib nii. Kui meil on 10 tuuma, siis oleme üldiselt rahulikud. Nii saame ressursse hinnata.
K002 on see, mida ma kutsun päringuklassideks, st SELECT, INSERT, UPDATE, DELETE. Ja eraldi SELECT FOR UPDATE, sest see on lukk.
Ja siit võime järeldada, et SELECT on tavalised lugejad - 82% kõigist kõnedest, kuid samal ajal - 74% total_time. See tähendab, et neid nimetatakse palju, kuid nad tarbivad vähem ressursse.
Ja pöördume tagasi küsimuse juurde: "Kuidas me saame valida õiged jagatud puhvrid?" Jälgin, et enamik võrdlusnäitajaid põhinevad ideel – vaatame, milline saab olema läbilaskevõime, st milline on läbilaskevõime. Tavaliselt mõõdetakse seda TPS-is või QPS-is.
Ja proovime tuuningparameetrite abil autost välja pigistada võimalikult palju tehinguid sekundis. Siin on valitud jaoks täpselt 311 sekundis.
Kuid keegi ei sõida täiskiirusel tööle ja koju tagasi. See on rumal. Sama andmebaasidega. Me ei pea sõitma täiskiirusel ja keegi ei tee seda. Keegi ei ela tootmises, millel on 100% protsessor. Kuigi võib-olla keegi elab, aga see pole hea.
Idee seisneb selles, et me sõidame tavaliselt 20 protsendi võimsusega, eelistatavalt mitte üle 50%. Ja ennekõike püüame optimeerida oma kasutajate reageerimisaega. See tähendab, et me peame oma nuppe keerama nii, et 20% kiirusel oleks tingimuslikult minimaalne latentsusaeg. See on idee, mida proovime ka oma katsetes kasutada.
Ja lõpuks soovitused:
- Tehke kindlasti Database Lab.
- Võimalusel tehke seda nõudmisel, et see mõneks ajaks lahti rulluks – mängige ja visake minema. Kui teil on pilvi, siis on see ütlematagi selge, st teil on palju seismist.
- Ole uudishimulik. Ja kui midagi on valesti, siis kontrollige katsetega, kuidas see käitub. Nancy abil saab end treenida, et kontrollida, kuidas baas töötab.
- Ja püüdke saavutada minimaalne reageerimisaeg.
- Ja ärge kartke Postgresi allikaid. Allikatega töötades peate teadma inglise keelt. Seal on palju kommentaare, seal on kõik lahti seletatud.
- Ja kontrollige andmebaasi seisukorda regulaarselt, vähemalt kord kolme kuu jooksul, käsitsi või Postgres-kontrolliga.
küsimused
Tänud! Väga huvitav asi.
Kaks tükki.
Jah, kaks tükki. Ainult ma ei saanud päris hästi aru. Kui me Nancyga töötame, kas me saame muuta ainult ühte parameetrit või tervet rühma?
Meil on delta konfiguratsiooni parameeter. Seal saab korraga keerata nii palju kui tahad. Kuid peate mõistma, et kui muudate paljusid asju, võite teha valesid järeldusi.
Jah. Miks ma küsisin? Sest katseid on raske läbi viia, kui teil on ainult üks parameeter. Pingutage seda, vaadake, kuidas see töötab. Panin ta välja. Seejärel alustate järgmisega.
Võid samal ajal pingutada, aga oleneb muidugi olukorrast. Kuid parem on katsetada ühte ideed. Meil tuli eile idee. Meil oli väga lähedane olukord. Seal oli kaks konfiguratsiooni. Ja me ei saanud aru, miks see suur erinevus oli. Ja tekkis mõte, et tuleb kasutada dihhotoomiat, et järjekindlalt aru saada ja leida, milles vahe on. Saab kohe pooled parameetrid samaks teha, siis veerand jne. Kõik on paindlik.
Ja on veel üks küsimus. Projekt on noor ja arenev. Dokumentatsioon on juba valmis, kas on üksikasjalik kirjeldus?
Tegin sinna konkreetselt lingi parameetrite kirjeldusele. See on seal. Kuid paljud asjad pole veel olemas. Otsin mõttekaaslasi. Ja ma leian need üles, kui esinen. See on väga lahe. Keegi juba töötab minuga, keegi aitas ja tegi seal midagi. Ja kui see teema huvitab, siis andke tagasisidet, mis puudu on.
Kui labori ehitame, siis ehk tuleb ka tagasisidet. Vaatame. Aitäh!
Tere! Täname raporti eest! Nägin, et Amazoni tugi on olemas. Kas GSP-i on plaanis toetada?
Hea küsimus. Hakkasime seda tegema. Ja me külmutasime selle praegu, sest tahame raha säästa. See tähendab, et on olemas tugi kasutades run on localhost. Saate ise eksemplari luua ja kohapeal töötada. Muide, seda me teemegi. Ma teen seda Getlabis, seal GSP-s. Kuid me ei näe veel mõtet sellist orkestreerimist teha, sest Google'il pole odavaid kohti. Seal on ??? juhtudel, kuid neil on piirangud. Esiteks on neil alati ainult 70% allahindlus ja sealse hinnaga ei saa mängida. Kohtadel tõstame hinda 5-10%, et vähendada tõenäosust, et sind lüüakse. See tähendab, et säästate kohti, kuid need võidakse teilt igal ajal ära võtta. Kui pakute natuke kõrgemat pakkumist kui teised, tapetakse teid hiljem. Google'il on täiesti erinevad eripärad. Ja on veel üks väga halb piirang – nad elavad ainult 24 tundi. Ja mõnikord tahame katset läbi viia 5 päeva. Kuid saate seda teha täppide kaupa; laigud kestavad mõnikord kuid.
Tere! Täname raporti eest! Mainisite kontrolli. Kuidas arvutate stat_statements vigu?
Väga hea küsimus. Ma võin teile väga üksikasjalikult näidata ja rääkida. Lühidalt vaatleme, kuidas taotlusgruppide komplekt on ujunud: kui palju on ära kukkunud ja kui palju uusi on tekkinud. Ja siis vaatame kahte mõõdikut: kogu_aeg ja kõned, seega on kaks viga. Ja me vaatame ujuvate rühmade panust. Alagruppe on kaks: lahkujad ja saabujad. Vaatame, milline on nende panus üldpilti.
Kas te ei karda, et see hetktõmmiste vahelise aja jooksul kaks-kolm korda sinna keerab?
See tähendab, kas nad registreerusid uuesti või mis?
Näiteks seda taotlust on juba korra ette võetud, siis tuli ja tehti uuesti, siis tuli uuesti ja tehti uuesti ette. Ja sa arvutasid siin midagi välja ja kus see kõik on?
Hea küsimus, peame vaatama.
Tegin sarnast asja. See oli muidugi lihtsam, tegin seda üksi. Kuid ma pidin lähtestama, lähtestama stat_statements ja hetktõmmise tegemise ajal aru saama, et seal oli vähem kui teatud murd, mis ikkagi ei jõudnud laeni, kui palju stat_statements sinna koguneda võib. Ja ma saan aru, et suure tõenäosusega ei nihutatud midagi.
Jah Jah.
Aga ma ei saa aru, kuidas muidu seda usaldusväärselt teha.
Kahjuks ei mäleta täpselt, kas kasutame seal päringu teksti või queryid koos pg_stat_statements ja keskendume sellele. Kui keskendume päringule, siis teoreetiliselt võrdleme võrreldavaid asju.
Ei, teda võib hetktõmmiste vahel mitu korda välja suruda ja uuesti tulla.
Sama ID-ga?
Jah.
Me uurime seda. Hea küsimus. Peame seda uurima. Kuid praegu on see, mida me näeme, kas kirjutatud 0...
See on muidugi haruldane juhtum, kuid olin šokeeritud, kui sain teada, et stat_statemetns võib sinna nihkuda.
Pg_stat_statementsis võib olla palju asju. Avastasime tõsiasja, et kui teil on track_utility = sees, siis jälgitakse ka teie komplekte.
Jah, muidugi.
Ja kui teil on java hibernate, mis on juhuslik, hakkab räsitabel seal asuma. Ja niipea, kui lülitate väga koormatud rakenduse välja, tekib 50-100 rühma. Ja seal on kõik enam-vähem stabiilne. Üks viis selle vastu võitlemiseks on pg_stat_statements.max suurendamine.
Jah, aga sa pead teadma, kui palju. Ja kuidagi peame tal silma peal hoidma. Seda ma teengi. See tähendab, et mul on pg_stat_statements.max. Ja ma näen, et hetktõmmise tegemise ajal ei olnud ma 70% saavutanud. Olgu, nii et me pole midagi kaotanud. Lähtestame. Ja säästame jälle. Kui järgmine hetktõmmis on alla 70, siis tõenäoliselt pole te enam midagi kaotanud.
Jah. Vaikimisi on nüüd 5. Ja sellest piisab paljudele inimestele.
Tavaliselt jah.
Video:
PS Enda nimel lisan, et kui Postgres sisaldab konfidentsiaalseid andmeid ja neid ei saa testikeskkonda lisada, siis võite kasutada . Skeem on ligikaudu järgmine:
Allikas: www.habr.com