Predlagam, da preberete prepis poročila Nikolaja Samokhvalova "Industrijski pristop k prilagajanju PostgreSQL: poskusi na bazah podatkov"
Shared_buffers = 25 % – je to veliko ali malo? Ali ravno prav? Kako veste, ali je to - precej zastarelo - priporočilo primerno v vašem primeru?
Čas je, da pristopite k vprašanju izbire parametrov postgresql.conf "kot odrasli." Ne s pomočjo slepih "auto tunerjev" ali zastarelih nasvetov iz člankov in blogov, ampak na podlagi:
- strogo preverjeni poskusi na podatkovnih bazah, ki se izvajajo avtomatsko, v velikih količinah in pod pogoji, ki so čim bližje »bojnim«,
- globoko razumevanje funkcij DBMS in OS.
Uporaba Nancy CLI (), si bomo ogledali poseben primer - zloglasne shared_buffers - v različnih situacijah, v različnih projektih in poskušali ugotoviti, kako izbrati optimalno nastavitev za našo infrastrukturo, bazo podatkov in obremenitev.
Govorili bomo o poskusih z bazami podatkov. To je zgodba, ki traja malo več kot šest mesecev.
Malo o meni. Izkušnje s Postgresom že več kot 14 let. Ustanovljena so bila številna podjetja za socialno mreženje. Postgres je bil in se uporablja povsod.
Tudi skupina RuPostgres na Meetupu, 2. mesto na svetu. Počasi se bližamo 2 ljudem. RuPostgres.org.
In na osebnih računalnikih različnih konferenc, vključno s Highloadom, sem že od vsega začetka odgovoren za podatkovne baze, zlasti za Postgres.
In v zadnjih nekaj letih sem svojo svetovalno prakso Postgres znova začel 11 časovnih pasov od tu.
In ko sem to naredil pred nekaj leti, sem imel nekaj premora v aktivnem ročnem delu s Postgresom, verjetno od leta 2010. Presenečen sem bil, kako malo se je spremenila delovna rutina DBA in koliko ročnega dela je še vedno treba uporabiti. In takoj sem pomislil, da je tu nekaj narobe, vse moram bolj avtomatizirati.
In ker je bilo vse na daljavo, je bila večina strank v oblakih. In očitno je veliko že avtomatiziranega. Več o tem pozneje. Se pravi, vse to je povzročilo idejo, da bi moralo obstajati več orodij, torej nekakšna platforma, ki bo avtomatizirala skoraj vsa dejanja DBA, tako da bo mogoče upravljati veliko število baz podatkov.
To poročilo ne bo vsebovalo:
- "Srebrne krogle" in izjave, kot je - nastavite 8 GB ali 25 % shared_buffers in vse bo v redu. O shared_buffers ne bo veliko.
- Hardcore "notranjost".
Kaj se bo zgodilo?
- Obstajajo načela optimizacije, ki jih uporabljamo in razvijamo. Na poti se bodo pojavljale najrazličnejše ideje in različna orodja, ki jih večinoma ustvarjamo v Open Source, torej naredimo osnovo v Open Source. Poleg tega imamo vstopnice, vsa komunikacija je praktično odprtokodna. Vidite lahko, kaj počnemo zdaj, kaj bo v naslednji izdaji itd.
- Nekaj izkušenj bo tudi z uporabo teh principov, teh orodij v številnih podjetjih: od majhnih startupov do velikih podjetij.
Kako se vse to razvija?
Prvič, glavna naloga DBA je poleg zagotavljanja ustvarjanja primerkov, uvajanja varnostnih kopij itd. najti ozka grla in optimizirati delovanje.
Zdaj je postavljeno takole. Gledamo spremljanje, nekaj vidimo, manjkajo pa nam nekatere podrobnosti. Začnemo bolj previdno kopati, običajno z rokami, in razumemo, kaj storiti s tem tako ali drugače.
In obstajata dva pristopa. Pg_stat_statements je privzeta rešitev za prepoznavanje počasnih poizvedb. In analiza dnevnikov Postgres z uporabo pgBadger.
Vsak pristop ima resne pomanjkljivosti. Pri prvem pristopu smo zavrgli vse parametre. In če vidimo tabelo skupin SELECT * FROM, kjer je stolpec enak "?" ali “$” od Postgres 10. Ne vemo, ali je to skeniranje indeksa ali skeniranje seq. Zelo je odvisno od parametra. Če tam nadomestite vrednost, ki jo redko srečate, bo to skeniranje indeksa. Če tam nadomestite vrednost, ki zaseda 90 % tabele, bo seq skeniranje očitno, ker Postgres pozna statistiko. In to je velika pomanjkljivost pg_stat_statements, čeprav nekaj dela poteka.
Največja pomanjkljivost analize dnevnika je, da si praviloma ne morete privoščiti "log_min_duration_statement = 0". In tudi o tem bomo govorili. V skladu s tem ne vidite celotne slike. Nekatera poizvedba, ki je zelo hitra, lahko porabi ogromno virov, vendar je ne boste videli, ker je pod vašim pragom.
Kako skrbniki baze podatkov rešujejo težave, ki jih najdejo?
Na primer, našli smo nekaj težav. Kaj se običajno naredi? Če ste razvijalec, potem boste delali nekaj na nekem primerku, ki ni enake velikosti. Če ste DBA, potem imate uprizoritev. In lahko je samo eden. In zaostal je šest mesecev. In misliš, da boš šel v proizvodnjo. In celo izkušeni DBA nato preverijo v proizvodnji, na replici. In zgodi se, da ustvarijo začasni indeks, se prepričajo, da pomaga, ga spustijo in dajo razvijalcem, da ga lahko dajo v datoteke za selitev. To so neumnosti, ki se zdaj dogajajo. In to je problem.
- Prilagodite konfiguracije.
- Optimizirajte nabor indeksov.
- Spremenite samo poizvedbo SQL (to je najtežji način).
- Dodajte kapaciteto (v večini primerov najlažji način).
S temi stvarmi se veliko dogaja. V Postgresu je veliko ročajev. Veliko je treba vedeti. V Postgresu je veliko kazal, za kar gre zahvala tudi organizatorjem te konference. In vse to je treba vedeti in to je tisto, zaradi česar se ne-DBA počutijo, kot da se DBA ukvarjajo s črno magijo. Se pravi, da se moraš učiti 10 let, da začneš vse to normalno razumeti.
In jaz sem borec proti tej črni magiji. Želim narediti vse, da obstaja tehnologija in v vsem tem ni intuicije.
Primeri iz življenja
To sem opazil pri vsaj dveh projektih, tudi pri svojem. Druga objava v blogu nam pove, da je vrednost 1 za default_statistict_target dobra. V redu, poskusimo v proizvodnji.
In tukaj smo, z našim orodjem dve leti kasneje, s pomočjo eksperimentov na bazah podatkov, o katerih govorimo danes, lahko primerjamo, kaj je bilo in kaj je postalo.
In za to moramo ustvariti poskus. Sestavljen je iz štirih delov.
- Prvi je okolje. Potrebujemo kos strojne opreme. In ko pridem v neko podjetje in podpišem pogodbo, rečem, naj mi dajo takšno strojno opremo, kot je v proizvodnji. Za vsakega od vaših mojstrov potrebujem vsaj en kos strojne opreme, kot je ta. Bodisi je to primerek virtualnega stroja v Amazonu ali Googlu ali pa potrebujem popolnoma enak kos strojne opreme. Se pravi, želim poustvariti okolje. In v koncept okolja vključujemo glavno različico Postgresa.
- Drugi del je predmet naše raziskave. To je zbirka podatkov. Lahko se ustvari na več načinov. Pokazal vam bom, kako.
- Tretji del je obremenitev. To je najtežji trenutek.
- In četrti del je, kaj preverjamo, torej kaj bomo s čim primerjali. Recimo, da lahko spremenimo enega ali več parametrov v konfiguraciji ali lahko ustvarimo indeks itd.
Začenjamo poskus. Tukaj je pg_stat_statements. Na levi je tisto, kar se je zgodilo. Na desni - kaj se je zgodilo.
Na levi default_statistics_target = 100, na desni = 1. Vidimo, da nam je to pomagalo. Na splošno se je vse izboljšalo za 000 %.
Če pa se pomaknemo navzdol, bodo prikazane skupine zahtev iz pgBadger ali iz pg_stat_statements. Obstajata dve možnosti. Videli bomo, da so se nekatere zahteve zmanjšale za 88%. In tu nastopi inženirski pristop. Lahko še kopljemo noter, ker se sprašujemo, zakaj je potonil. Morate razumeti, kaj se je zgodilo s statistiko. Zakaj več veder v statistiki vodi do slabših rezultatov.
Ali pa ne moremo kopati, ampak naredimo "ALTER TABLE ... ALTER COLUMN" in vrnemo 100 veder nazaj v statistiko tega stolpca. In potem se lahko z drugim poskusom prepričamo, da je ta popravek pomagal. Vse. To je inženirski pristop, ki nam pomaga videti celotno sliko in sprejemati odločitve na podlagi podatkov in ne na podlagi intuicije.
Par primerov iz drugih področij. Testi CI so bili v testiranju že vrsto let. In noben projekt pri zdravi pameti ne bi živel brez avtomatiziranih testov.
V drugih panogah: v letalstvu, v avtomobilski industriji, ko testiramo aerodinamiko, imamo tudi možnost delati eksperimente. Nečesa z risbe ne bomo izstrelili neposredno v vesolje ali pa nekega avtomobila ne bomo takoj peljali na stezo. Na primer, tam je vetrovnik.
Sklepe lahko potegnemo iz opazovanj drugih panog.
Prvič, imamo posebno okolje. Je blizu proizvodnje, ni pa blizu. Njegova glavna značilnost je, da mora biti poceni, ponovljiv in čim bolj avtomatiziran. Obstajati morajo tudi posebna orodja za izvedbo podrobne analize.
Najverjetneje imamo, ko izstrelimo letalo in letimo, manj možnosti za preučevanje vsakega milimetra površine krila kot v vetrovniku. Imamo več diagnostičnih orodij. Lahko si privoščimo, da v zrak nosimo več težkih stvari, ki si jih ne moremo dati na letalo. Enako s Postgresom. V nekaterih primerih lahko med poskusi omogočimo polno beleženje poizvedb. In tega ne želimo početi v proizvodnji. Morda celo nameravamo to omogočiti z uporabo auto_explain.
In kot sem rekel, visoka stopnja avtomatizacije pomeni, da pritisnemo gumb in ponovimo. Tako mora biti, da je veliko eksperimentiranja, da je na toku.
Nancy CLI - temelj "laboratorija za baze podatkov"
In tako smo naredili to stvar. Se pravi, o teh idejah sem govoril junija, pred skoraj enim letom. In že imamo tako imenovani Nancy CLI v odprti kodi. To je osnova za izgradnjo laboratorija podatkovnih baz.
— Je odprtokoden, na Gitlabu. Lahko rečeš, lahko poskusiš. Navedel sem povezavo med diapozitivi. Lahko ga kliknete in tam bo v vseh pogledih.
Seveda je veliko še v razvoju. Tam je veliko idej. Ampak to je nekaj, kar uporabljamo skoraj vsak dan. In ko imamo idejo - zakaj se to, ko izbrišemo 40 vrstic, vse zmanjša na IO, potem lahko izvedemo poskus in pogledamo podrobneje, da razumemo, kaj se dogaja, in nato poskušamo to sproti popraviti. Se pravi, delamo poskus. Na primer, nekaj prilagodimo in vidimo, kaj se zgodi na koncu. In tega ne počnemo v proizvodnji. To je bistvo ideje.
Kje lahko to deluje? To lahko deluje lokalno, kar pomeni, da to lahko storite kjer koli, lahko ga celo izvajate na MacBooku. Potrebujemo dokerja, gremo. To je vse. V nekem primeru ga lahko zaženete na kosu strojne opreme ali v virtualnem stroju kjer koli.
Poleg tega obstaja tudi priložnost za oddaljeno izvajanje v Amazonu v primerku EC2, v točkah. In to je zelo kul priložnost. Na primer, včeraj smo izvedli več kot 500 poskusov na primerku i3, začenši z najmlajšim in konča z i3-16-xlarge. In 500 poskusov nas je stalo 64 dolarjev. Vsak je trajal 15 minut. To pomeni, da je zaradi dejstva, da se tam uporabljajo spotovi, zelo poceni - 70% popust, Amazonovo zaračunavanje na sekundo. Lahko narediš veliko. Lahko naredite pravo raziskavo.
Podprte so tudi tri glavne različice Postgresa. Ni tako težko dokončati nekaj starih in tudi nove 12. različice.
Predmet lahko definiramo na tri načine. to:
- Dump/sql datoteka.
- Glavni način je kloniranje imenika PGDATA. Praviloma se vzame iz rezervnega strežnika. Če imate običajne binarne varnostne kopije, lahko od tam naredite klone. Če imate oblake, bo to namesto vas naredila pisarna v oblaku, kot sta Amazon in Google. To je najpomembnejši način za kloniranje prave proizvodnje. Tako se razpletemo.
- In zadnja metoda je primerna za raziskovanje, ko želite razumeti, kako nekaj deluje v Postgresu. To je pgbench. Ustvarite lahko z uporabo pgbench. To je samo ena možnost "db-pgbench". Povej mu, kakšna lestvica. In vse bo ustvarjeno v oblaku, kot je navedeno.
In naloži:
- Nalaganje lahko izvedemo v eni niti SQL. To je najbolj primitiven način.
- In lahko posnemamo obremenitev. In najprej ga lahko posnemamo na naslednji način. Zbrati moramo vse dnevnike. In to je boleče. Pokazal ti bom zakaj. In uporabljamo pgreplay we play, ki je vgrajen v Nancy.
- Ali druga možnost. Tako imenovana obrtna obremenitev, ki jo opravimo z določenim naporom. Če analiziramo našo trenutno obremenitev bojnega sistema, izvlečemo najvišje skupine zahtev. Z uporabo pgbench lahko posnemamo to obremenitev v laboratoriju.
- Bodisi moramo izvesti nekakšen SQL, tj. preverimo nekakšno migracijo, tam ustvarimo indeks, tam izvedemo ANALAZE. In pogledamo, kaj se je zgodilo pred vakuumom in po vakuumu. Na splošno vsak SQL.
- Bodisi spremenimo enega ali več parametrov v konfiguraciji. Lahko nam rečemo, da preverimo na primer 100 vrednosti v Amazonu za našo terabajtno bazo podatkov. In v nekaj urah boste imeli rezultat. Praviloma boste potrebovali več ur za namestitev terabajtne baze podatkov. Toda v razvoju je popravek, možna je serija, tj. lahko dosledno uporabljate iste pgdata na istem strežniku in preverjate. Postgres se bo znova zagnal in predpomnilniki bodo ponastavljeni. In lahko vozite tovor.
- Prispe imenik s kupom različnih datotek, začenši s posnetki pgstat***. In najbolj zanimiva stvar je pg_stat_statements, pg_stat_kcacke. To sta dve razširitvi, ki analizirata zahteve. In pg_stat_bgwriter ne vsebuje le statističnih podatkov o pgwriterju, ampak tudi o kontrolnih točkah in o tem, kako ozadja sama izpodrivajo umazane medpomnilnike. In vse je zanimivo videti. Na primer, ko nastavimo shared_buffers, je zelo zanimivo videti, koliko so vsi zamenjali.
- Prihajajo tudi dnevniki Postgres. Dva dnevnika – dnevnik priprave in dnevnik predvajanja nalaganja.
- Razmeroma nova funkcija je FlameGraphs.
- Poleg tega, če ste za predvajanje obremenitve uporabili možnosti pgreplay ali pgbench, bo njihov izhod izviren. In videli boste zakasnitev in TPS. Razumeti bo mogoče, kako so to videli.
- Sistemska informacija.
- Osnovna preverjanja procesorja in IO. To velja bolj za primerek EC2 v Amazonu, ko želite zagnati 100 enakih primerkov v niti in tam zagnati 100 različnih izvajanj, potem boste imeli 10 poskusov. In poskrbeti morate, da ne naletite na pomanjkljiv primerek, ki ga nekdo že zatira. Drugi so aktivni na tem delu strojne opreme in vam je ostalo malo virov. Takšne rezultate je bolje zavreči. In s pomočjo sysbench Alexeya Kopytova naredimo več kratkih pregledov, ki bodo prišli in jih je mogoče primerjati z drugimi, tj. razumeli boste, kako se obnaša CPU in kako se obnaša IO.
Kakšne so tehnične težave na podlagi primerov različnih podjetij?
Recimo, da želimo ponoviti dejansko obremenitev z uporabo dnevnikov. Odlična ideja je, če je napisana na Open Source pgreplay. Uporabljamo ga. Da pa bo dobro delovalo, morate omogočiti polno beleženje poizvedb s parametri in časom.
Obstaja nekaj zapletov s trajanjem in časovnim žigom. Celotno kuhinjo bomo izpraznili. Glavno vprašanje je, ali si to lahko privoščite ali ne?
Težava je v tem, da morda ni na voljo. Najprej morate razumeti, kateri tok bo zapisan v dnevnik. Če imate pg_stat_statements, lahko uporabite to poizvedbo (povezava bo na voljo v diapozitivih), da približno razumete, koliko bajtov bo zapisanih na sekundo.
Gledamo dolžino zahteve. Zanemarjamo dejstvo, da parametrov ni, vemo pa dolžino zahteve in vemo, kolikokrat na sekundo je bila izvedena. Tako lahko približno ocenimo, koliko bajtov na sekundo. Morda se dvakrat bolj zmotimo, vendar bomo tako vrstni red zagotovo razumeli.
Vidimo lahko, da se ta zahteva izvrši 802-krat na sekundo. In vidimo, da bo bytes_per sec – 300 kB/s zapisano plus ali minus. In tak pretok si praviloma lahko privoščimo.
Ampak! Dejstvo je, da obstajajo različni sistemi beleženja. Privzeta nastavitev ljudi je običajno "syslog".
In če imate syslog, potem imate morda takšno sliko. Vzeli bomo pgbench, omogočili beleženje poizvedb in videli, kaj se bo zgodilo.
Brez beleženja - to je stolpec na levi. Imamo 161 TPS. S syslogom - to je v Ubuntu 000 na Amazonu, dobimo 16.04 TPS. In če preidemo na dva druga načina beleženja, potem je situacija veliko boljša. Se pravi, pričakovali smo, da bo padel, a ne v tolikšni meri.
In na CentOS 7, v katerem sodeluje tudi journald, spreminjanje dnevnikov v binarni format za enostavno iskanje itd., potem je tam nočna mora, v TPS spustimo 44-krat.
In s tem ljudje živijo. In pogosto je v podjetjih, še posebej velikih, to zelo težko spremeniti. Če lahko pobegnete od syslog-a, se prosim oddaljite od njega.
- Ocenite IOPS in potek pisanja.
- Preverite svoj sistem beleženja.
- Če je predvidena obremenitev prevelika, razmislite o vzorčenju.
Imamo pg_stat_statements. Kot sem rekel, mora biti tam. In vsako skupino zahtev lahko vzamemo in opišemo na poseben način v datoteki. In potem lahko uporabimo zelo priročno funkcijo v pgbench - to je možnost vstavljanja več datotek z možnostjo "-f".
Razume veliko "-f". In s pomočjo “@” na koncu lahko ugotovite, kakšen delež naj ima posamezna datoteka. To pomeni, da lahko rečemo, da to storite v 10% primerov, to pa v 20%. In to nas bo približalo temu, kar vidimo v proizvodnji.
Kako bomo razumeli, kaj imamo v proizvodnji? Kakšen delež in kako? To je malo na stran. Imamo še en izdelek . Tudi baza v odprti kodi. In zdaj ga aktivno razvijamo.
Rodil se je iz nekoliko drugačnih razlogov. Iz razlogov, da spremljanje ni dovolj. Se pravi, prideš, pogledaš bazo, pogledaš probleme, ki obstajajo. In praviloma opravite zdravstveni pregled. Če ste izkušen DBA, naredite health_check. Pogledali smo uporabo indeksov itd. Če imate OKmeter, potem super. To je kul spremljanje za Postgres. OKmeter.io – prosim namestite ga, tam je vse narejeno zelo dobro. To je plačano.
Če ga nimate, potem običajno nimate veliko. Pri spremljanju je običajno CPU, IO in potem z zadržki in to je vse. In potrebujemo več. Videti moramo, kako deluje avtovakuum, kako deluje kontrolna točka, v io moramo ločiti kontrolno točko od bgwriterja in od ozadij itd.
Težava je v tem, da ko pomagaš velikemu podjetju, ne more nečesa hitro izvesti. OKmeterja ne morejo hitro kupiti. Mogoče ga bodo kupili čez šest mesecev. Nekaterih paketov ne morejo hitro dostaviti.
In prišli smo na idejo, da potrebujemo posebno orodje, ki ne zahteva vgradnje ničesar, se pravi, da vam v proizvodnji sploh ni treba vgraditi ničesar. Namestite ga na svoj prenosni računalnik ali na opazovalni strežnik, od koder ga boste izvajali. In analiziral bo veliko stvari: operacijski sistem, datotečni sistem in sam Postgres, naredil nekaj lahkih poizvedb, ki jih je mogoče zagnati neposredno v produkcijo in nič ne bo spodletelo.
Imenovali smo ga Postgres-checkup. V medicinskem smislu je to redni zdravstveni pregled. Če je na temo avtomobilizma, potem je kot vzdrževanje. Vzdrževanje avtomobila opravite vsakih šest mesecev ali leto, odvisno od znamke. Ali vzdržujete svojo bazo? Se pravi, ali redno opravljate poglobljene raziskave? To je treba narediti. Če naredite varnostne kopije, naredite pregled, to ni nič manj pomembno.
In imamo takšno orodje. Aktivno se je začel pojavljati šele pred približno tremi meseci. Še vedno je mlad, a tega je veliko.
Zbiranje najbolj "vplivnih" skupin poizvedb - poročilo K003 v Postgres-checkup
In obstaja skupina poročil K. Doslej tri poročila. In obstaja takšno poročilo K003. Obstaja vrh iz pg_stat_statements, razvrščenih po total_time.
Ko skupine zahtevkov razvrstimo po total_time, vidimo na vrhu skupino, ki najbolj obremenjuje naš sistem, torej porabi več virov. Zakaj poimenujem skupine poizvedb? Ker smo vrgli ven parametre. To niso več zahteve, ampak skupine zahtev, torej so abstrahirane.
In če optimiziramo od zgoraj navzdol, bomo olajšali naše vire in odložili trenutek, ko bomo morali nadgraditi. To je zelo dober način za prihranek denarja.
Morda to ni zelo dober način za skrb za uporabnike, saj morda ne vidimo redkih, a zelo nadležnih primerov, ko je oseba čakala 15 sekund. Skupaj so tako redki, da jih ne vidimo, vendar imamo opravka z viri.
Kaj se je zgodilo v tej tabeli? Naredili smo dva posnetka. Postgres_checkup vam bo dal delto za vsako metriko: skupni čas, klice, vrstice, shared_blks_read itd. To je to, delta je bila izračunana. Velika težava s pg_stat_statements je, da se ne spomni, kdaj je bil ponastavljen. Če si pg_stat_database zapomni, potem si pg_stat_statements ne zapomni. Vidite, da je številka 1, vendar ne vemo, od kod smo šteli.
In tukaj vemo, tukaj imamo dva posnetka. Vemo, da je bila delta v tem primeru 56 sekund. Zelo kratek razmik. Razvrščeno glede na total_time. In potem lahko razlikujemo, tj. vse metrike razdelimo po trajanju. Če vsako metriko razdelimo na trajanje, dobimo število klicev na sekundo.
Nato je total_time per second moja najljubša metrika. Meri se v sekundah na sekundo, tj. koliko sekund je potreboval naš sistem, da je izvršil to skupino zahtev na sekundo. Če tam vidite več kot sekundo na sekundo, to pomeni, da ste morali dati več kot eno jedro. To je zelo dobra metrika. Lahko razumete, da ta prijatelj na primer potrebuje vsaj tri jedra.
To je naše znanje, česa takega še nikjer nisem videl. Upoštevajte - to je zelo preprosta stvar - sekunda na sekundo. Včasih, ko je vaš CPE 100 %, potem pol ure na sekundo, kar pomeni, da ste porabili pol ure za izvajanje samo teh zahtev.
Nato vidimo vrstice na sekundo. Vemo, koliko vrstic na sekundo je vrnil.
In potem je tu tudi zanimiva stvar. Koliko shared_buffers preberemo na sekundo iz samih shared_buffers. Zadetki so že bili, vrstice pa smo jemali iz predpomnilnika operacijskega sistema ali z diska. Prva možnost je hitra, druga pa je lahko hitra ali pa tudi ne, odvisno od situacije.
In drugi način razlikovanja je razdelitev števila zahtevkov v tej skupini. V drugem stolpcu boste vedno imeli eno poizvedbo, razdeljeno na poizvedbo. In potem je zanimivo - koliko milisekund je bilo v tej zahtevi. Vemo, kako se ta poizvedba obnaša v povprečju. Za vsako zahtevo je bila potrebna 101 milisekunda. To je tradicionalna metrika, ki jo moramo razumeti.
Koliko vrstic je v povprečju vrnila posamezna poizvedba? Vidimo 8, da se ta skupina vrača. V povprečju, koliko je bilo vzetih iz predpomnilnika in prebranih. Vidimo, da je vse lepo predpomnjeno. Solidni zadetki prve skupine.
In četrti podniz v vsaki vrstici je odstotek skupnega zneska. Imamo klice. Recimo 1 000 000. In lahko razumemo, kakšen prispevek ima ta skupina. Vidimo, da v tem primeru prva skupina prispeva manj kot 0,01 %. To pomeni, da je tako počasen, da ga ne vidimo v celotni sliki. In druga skupina je 5% na klice. Se pravi 5 % vseh klicev je druga skupina.
Skupni_čas je tudi zanimiv. Za prvo skupino zahtevkov smo porabili 14 % celotnega delovnega časa. In za drugo - 11% itd.
Ne bom se spuščal v podrobnosti, vendar obstajajo podrobnosti. Na vrhu prikažemo napako, ker lahko pri primerjavi posnetki lebdijo, to pomeni, da lahko nekatere zahteve izpadejo in jih v drugi ne morejo biti več, medtem ko se lahko pojavijo nekatere nove. In tam izračunamo napako. Če vidite 0, je to dobro. Ni napak. Če je stopnja napak do 20 %, je v redu.
Potem se vrnemo k naši temi. Delovno obremenitev moramo oblikovati. Gremo od zgoraj navzdol in gremo, dokler ne dosežemo 80% ali 90%. Običajno je to 10-20 skupin. In izdelujemo datoteke za pgbench. Tam uporabljamo naključno. Včasih se to na žalost ne izide. In v Postgresu 12 bo več priložnosti za uporabo tega pristopa.
In potem na ta način pridobimo 80–90 % total_time. Kaj naj dodam za "@"? Pogledamo razpise, pogledamo, koliko je obresti in razumemo, da smo tu dolžni toliko obresti. Iz teh odstotkov lahko razumemo, kako uravnotežiti vsako od datotek. Nato uporabimo pgbench in se lotimo dela.
Imamo tudi K001 in K002.
K001 je en velik niz s štirimi podnizi. To je značilnost našega celotnega bremena. Glej drugi stolpec in drugo podvrstico. Vidimo, da približno eno sekundo in pol na sekundo, tj. če sta dve jedri, potem bo dobro. Kapaciteta bo približno 75 %. In tako bo delovalo. Če imamo 10 jeder, potem bomo na splošno mirni. Tako lahko ovrednotimo vire.
K002 imenujem poizvedbene razrede, tj. IZBERI, VSTAVI, POSODOBI, IZBRIŠI. In posebej IZBERITE ZA POSODOBITEV, ker je ključavnica.
In tukaj lahko sklepamo, da je SELECT navaden bralec - 82% vseh klicev, a hkrati - 74% v skupnem_času. To pomeni, da se imenujejo veliko, vendar porabijo manj virov.
In vrnemo se k vprašanju: "Kako lahko izberemo prave shared_buffers?" Opažam, da večina benchmarkov temelji na ideji - poglejmo, kakšna bo prepustnost, torej kakšna bo prepustnost. Običajno se meri v TPS ali QPS.
In poskušamo iz avtomobila s pomočjo nastavitvenih parametrov iztisniti čim več transakcij na sekundo. Tukaj je točno 311 na sekundo za izbrano.
Nihče pa se v službo in nazaj ne vozi s polno hitrostjo. To je neumno. Enako z bazami podatkov. Ni nam treba voziti s polno hitrostjo in nihče ne. Nihče ne živi v proizvodnji, ki ima 100% CPU. Čeprav morda kdo živi, vendar to ni dobro.
Ideja je, da običajno vozimo z 20 odstotki zmogljivosti, po možnosti ne več kot 50 odstotki. Trudimo se optimizirati odzivni čas predvsem za naše uporabnike. Se pravi, vrteti moramo gumbe tako, da je minimalna zakasnitev pri 20% hitrosti, pogojno. To je ideja, ki jo poskušamo uporabiti tudi v naših poskusih.
In na koncu priporočila:
- Bodite prepričani, da naredite Database Lab.
- Če je mogoče, naredite to na zahtevo, tako da se nekaj časa odvija - igrajte in zavrzite. Če imate oblake, potem je to samoumevno, torej imejte veliko stanja.
- Bodite radovedni. In če je kaj narobe, preverite s poskusi, kako se obnaša. Nancy lahko uporabite, da se naučite, da preverite, kako osnova deluje.
- In si prizadevajte za čim krajši odzivni čas.
- In ne bojte se Postgresovih virov. Ko delate z viri, morate znati angleško. Tam je veliko komentarjev, tam je vse razloženo.
- In redno preverjajte zdravje baze podatkov, vsaj enkrat na tri mesece, ročno ali Postgres-checkup.
vprašanja
Najlepša hvala! Zelo zanimiva stvar.
Dva kosa.
Ja, dva kosa. Samo jaz nisem čisto razumel. Ali lahko, ko delava z Nancy, prilagodiva samo en parameter ali celotno skupino?
Imamo delta konfiguracijski parameter. Tja lahko obračate, kolikor želite naenkrat. Vendar morate razumeti, da ko spremenite veliko stvari, lahko naredite napačne zaključke.
ja Zakaj sem vprašal? Ker je težko izvajati poskuse, če imaš samo en parameter. Zategneš, vidiš, kako deluje. Dala sem ga ven. Nato začnete z naslednjim.
Lahko ga hkrati zategnete, odvisno pa je seveda od situacije. Vendar je bolje preizkusiti eno idejo. Včeraj smo imeli idejo. Imeli smo zelo tesno situacijo. Obstajali sta dve konfiguraciji. In nismo mogli razumeti, zakaj je prišlo do velike razlike. In pojavila se je ideja, da morate uporabiti dihotomijo, da bi dosledno razumeli in ugotovili, v čem je razlika. Takoj lahko narediš enakih polovico parametrov, nato četrtino itd. Vse je prilagodljivo.
In še eno vprašanje je. Projekt je mlad in se razvija. Dokumentacija je že pripravljena, ali obstaja podroben opis?
Posebej sem naredil povezavo do opisa parametrov. Tam je. Marsičesa pa še ni. Iščem enako misleče ljudi. In jih najdem, ko nastopam. To je zelo kul. Nekdo že dela z mano, nekdo je pomagal in naredil nekaj tam. In če vas ta tema zanima, podajte povratne informacije o tem, kaj manjka.
Ko zgradimo laboratorij, bo morda prišlo do povratnih informacij. Pa poglejmo. Hvala vam!
Zdravo! Hvala za poročilo! Videl sem, da obstaja podpora za Amazon. Ali obstajajo načrti za podporo GSP?
Dobro vprašanje. Začeli smo to delati. Za zdaj smo ga zamrznili, ker želimo prihraniti denar. To pomeni, da obstaja podpora za uporabo na lokalnem gostitelju. Primerek lahko ustvarite sami in delate lokalno. Mimogrede, to počnemo. To počnem v Getlabu, tam v GSP. Vendar še ne vidimo smisla v takšni orkestraciji, ker Google nima poceni mest. Tukaj je ??? primeri, vendar imajo omejitve. Prvič, vedno imajo samo 70% popust in tam se ne moreš igrati s ceno. Na spotih zvišamo ceno za 5-10%, da zmanjšamo verjetnost, da vas bodo brcnili. To pomeni, da prihranite mesta, vendar vam jih lahko kadar koli odvzamejo. Če ponudite malo več kot drugi, vas bodo kasneje ubili. Google ima čisto drugačne specifike. In obstaja še ena zelo slaba omejitev - živijo le 24 ur. In včasih želimo izvajati poskus 5 dni. Toda to lahko storite na mestih; madeži včasih trajajo več mesecev.
Zdravo! Hvala za poročilo! Omenili ste pregled. Kako izračunate napake stat_statements?
Zelo dobro vprašanje. Lahko vam pokažem in povem zelo podrobno. Na kratko, pogledamo, kako je nabor skupin zahtev lebdel: koliko jih je odpadlo in koliko novih se je pojavilo. Nato pogledamo dve metriki: total_time in klice, tako da obstajata dve napaki. In pogledamo prispevek lebdečih skupin. Obstajata dve podskupini: tisti, ki so odšli, in tisti, ki so prišli. Poglejmo, kakšen je njihov prispevek k celotni sliki.
Se ne bojite, da se bo v času med posnetki dvakrat ali trikrat obrnilo tam?
Se pravi, so se spet registrirali ali kaj?
Na primer, ta zahteva je bila enkrat že izvzeta, nato je prišla in bila znova izvzeta, nato je znova prišla in je bila znova izvzeta. In tukaj si nekaj izračunal in kje je vse?
Dobro vprašanje, bomo morali pogledati.
Podobno sem naredil. Bilo je seveda preprosteje, naredil sem sam. Vendar sem moral ponastaviti, ponastaviti stat_statements in v času posnetka ugotoviti, da obstaja manj kot določen del, ki še vedno ni dosegel zgornje meje, koliko stat_statements se lahko tam nabere. In kolikor razumem, najverjetneje nič ni bilo premaknjeno.
Da, da.
Vendar ne razumem, kako drugače to narediti zanesljivo.
Na žalost se ne spomnim natančno, ali tam uporabimo besedilo poizvedbe ali queryid s pg_stat_statements in se osredotočimo na to. Če se osredotočimo na queryid, potem teoretično primerjamo primerljive stvari.
Ne, lahko ga večkrat prisilijo ven med posnetki in pride znova.
Z istim ID-jem?
Da.
To bomo preučili. Dobro vprašanje. Moramo ga preučiti. Toda za zdaj je to, kar vidimo, napisano 0 ...
To je seveda redek primer, vendar sem bil šokiran, ko sem izvedel, da lahko stat_statemetns tam izpodrine.
V Pg_stat_statements je lahko veliko stvari. Naleteli smo na dejstvo, da če imate track_utility = on, potem se sledi tudi vašim nizom.
Ja, seveda.
In če imate java hibernate, ki je naključna, se zgoščevalna tabela začne tam nahajati. In takoj, ko izklopite zelo naloženo aplikacijo, imate na koncu 50-100 skupin. In tam je vse bolj ali manj stabilno. Eden od načinov za boj proti temu je povečanje pg_stat_statements.max.
Da, vendar morate vedeti, koliko. In nekako moramo paziti nanj. To počnem. To pomeni, da imam pg_stat_statements.max. In vidim, da v času posnetka nisem dosegel 70%. V redu, torej nismo ničesar izgubili. Ponastavimo. In spet varčujemo. Če je naslednji posnetek manjši od 70, potem najverjetneje spet niste ničesar izgubili.
ja Privzeto je zdaj 5. In to je za marsikoga dovolj.
Običajno da.
Video:
PS V svojem imenu bom dodal, da če Postgres vsebuje zaupne podatke in jih ni mogoče vključiti v testno okolje, potem lahko uporabite . Shema je približno naslednja:
Vir: www.habr.com