Predlagam, da preberete prepis poročila Alexeya Lesovskyja iz Data Egret “Osnove spremljanja PostgreSQL”
V tem poročilu bo Alexey Lesovsky govoril o ključnih točkah post-gresivne statistike, kaj pomenijo in zakaj bi morale biti prisotne v spremljanju; o tem, kakšni grafi naj bodo v monitoringu, kako jih dodati in kako jih interpretirati. Poročilo bo koristno skrbnikom baz podatkov, sistemskim skrbnikom in razvijalcem, ki jih zanima odpravljanje težav s Postgresom.
Moje ime je Aleksej Lesovski, zastopam podjetje Data Egret.
Nekaj besed o sebi. Dolgo nazaj sem začel kot sistemski administrator.
Administriral sem najrazličnejše sisteme Linux, delal na različnih stvareh, povezanih z Linuxom, to je virtualizacija, nadzor, delal s proxyji itd. Toda na neki točki sem se začel bolj ukvarjati z bazami podatkov, PostgreSQL. Res mi je bil všeč. In na neki točki sem večino svojega delovnega časa začel delati na PostgreSQL. In tako sem postopoma postal PostgreSQL DBA.
V moji karieri so me vedno zanimale teme statistike, spremljanja in telemetrije. In ko sem bil sistemski skrbnik, sem zelo tesno sodeloval z Zabbixom. In napisal sem majhen niz scenarijev, kot je . V svojem času je bil zelo priljubljen. In tam je bilo mogoče spremljati zelo različne pomembne stvari, ne le Linux, ampak tudi različne komponente.
Zdaj delam na PostgreSQL. Že pišem drugo stvar, ki vam omogoča delo s statistiko PostgreSQL. Se imenuje (članek na Habréju - ).
Malo uvodne opombe. Kakšne situacije imajo naše stranke, naše stranke? Prišlo je do neke vrste nesreče, povezane z bazo podatkov. In ko je baza podatkov že obnovljena, pride vodja oddelka ali vodja razvoja in reče: "Prijatelji, bazo moramo spremljati, ker se je zgodilo nekaj slabega in moramo preprečiti, da se to v prihodnje dogaja." In tu se začne zanimiv proces izbire nadzornega sistema ali prilagajanja obstoječega nadzornega sistema, da lahko spremljate svojo bazo podatkov - PostgreSQL, MySQL ali katero drugo. In kolegi začnejo predlagati: »Slišal sem, da obstaja taka in taka baza podatkov. Uporabimo ga." Kolegi se začnejo prepirati med seboj. In na koncu se izkaže, da izberemo nekakšno bazo podatkov, vendar je spremljanje PostgreSQL v njej predstavljeno precej slabo in moramo vedno nekaj dodati. Vzemite nekaj repozitorijev iz GitHuba, jih klonirajte, prilagodite skripte in jih nekako prilagodite. In na koncu se konča kot nekakšno ročno delo.
Zato vam bom v tem predavanju poskušal dati nekaj znanja o tem, kako izbrati nadzor ne samo za PostgreSQL, ampak tudi za bazo podatkov. In dal vam znanje, ki vam bo omogočilo, da dokončate svoje spremljanje, da boste imeli od njega nekaj koristi, tako da boste lahko s koristjo spremljali svojo bazo podatkov, da bi takoj preprečili morebitne prihajajoče izredne razmere, ki se lahko pojavijo.
In ideje, ki bodo v tem poročilu, je mogoče neposredno prilagoditi kateri koli bazi podatkov, naj bo to DBMS ali noSQL. Zato ne obstaja samo PostgreSQL, ampak bo veliko receptov, kako to narediti v PostgreSQL. Tam bodo primeri poizvedb, primeri entitet, ki jih ima PostgreSQL za spremljanje. In če ima vaš DBMS iste stvari, ki vam omogočajo, da jih postavite v nadzor, jih lahko tudi prilagodite, dodate in dobro bo.
Ne bom v poročilu
govoriti o tem, kako dostaviti in shraniti meritve. O naknadni obdelavi podatkov in njihovi predstavitvi uporabniku ne bom rekel ničesar. In ne bom rekel ničesar o opozarjanju.
Ko pa zgodba napreduje, bom pokazal različne posnetke zaslona obstoječega spremljanja in jih nekako kritiziral. Kljub temu se bom trudil, da ne bom imenoval blagovnih znamk, da ne bi ustvaril reklame ali antireklame za te izdelke. Zato so vsa naključja naključna in prepuščena vaši domišljiji.
Najprej ugotovimo, kaj je spremljanje. Spremljanje je zelo pomembna stvar. Vsi to razumejo. Hkrati pa spremljanje ni povezano s poslovnim produktom in ne vpliva neposredno na dobiček podjetja, zato je čas spremljanju vedno dodeljen na podlagi ostanka. Če imamo čas, potem spremljamo, če nimamo časa, potem OK, damo to v zaostanek in se nekega dne vrnemo k tem nalogam.
Zato iz naše prakse, ko pridemo do strank, je spremljanje velikokrat nepopolno in nima zanimivih stvari, ki bi nam pomagale pri boljšem delu z bazo. In zato mora biti spremljanje vedno dokončano.
Baze podatkov so tako kompleksne stvari, ki jih je treba tudi spremljati, saj so baze podatkov skladišče informacij. In informacije so za podjetje zelo pomembne, nikakor jih ni mogoče izgubiti. Toda hkrati so baze podatkov zelo zapleteni deli programske opreme. Sestavljeni so iz velikega števila komponent. In veliko teh komponent je treba spremljati.
Če govorimo posebej o PostgreSQL, potem ga lahko predstavimo v obliki sheme, ki je sestavljena iz velikega števila komponent. Te komponente medsebojno delujejo. In hkrati ima PostgreSQL tako imenovani podsistem Stats Collector, ki omogoča zbiranje statističnih podatkov o delovanju teh podsistemov in zagotavljanje nekakšnega vmesnika administratorju ali uporabniku, da lahko ta statistiko pregleduje.
Ti statistični podatki so predstavljeni v obliki določenega niza funkcij in pogledov. Lahko jih imenujemo tudi mize. To pomeni, da se lahko z običajnim odjemalcem psql povežete z bazo podatkov, izberete te funkcije in poglede ter dobite nekaj specifičnih številk o delovanju podsistemov PostgreSQL.
Te številke lahko dodate v svoj najljubši nadzorni sistem, narišete grafe, dodate funkcije in dolgoročno pridobite analitiko.
Toda v tem poročilu ne bom v celoti zajel vseh teh funkcij, saj lahko traja cel dan. Dobesedno bom obravnaval dve, tri ali štiri stvari in vam povedal, kako pomagajo izboljšati spremljanje.
In če govorimo o spremljanju baze podatkov, kaj je potem treba spremljati? Najprej moramo spremljati razpoložljivost, saj je baza storitev, ki strankam omogoča dostop do podatkov in moramo spremljati razpoložljivost ter zagotavljati nekatere njene kvalitativne in kvantitativne značilnosti.
Prav tako moramo spremljati odjemalce, ki se povezujejo z našo zbirko podatkov, ker so lahko tako običajni odjemalci kot škodljivi odjemalci, ki lahko škodujejo bazi. Prav tako jih je treba spremljati in spremljati njihove dejavnosti.
Ko se stranke povežejo z bazo, je očitno, da začnejo delati z našimi podatki, zato moramo spremljati, kako stranke delajo s podatki: s katerimi tabelami in v manjši meri s katerimi indeksi. To pomeni, da moramo ovrednotiti delovno obremenitev, ki jo ustvarijo naše stranke.
Delovno obremenitev pa seveda sestavljajo tudi zahteve. Aplikacije se povezujejo z bazo, dostopajo do podatkov s pomočjo poizvedb, zato je pomembno, da ocenimo, katere poizvedbe imamo v bazi, spremljamo njihovo ustreznost, da niso narobe napisane, da je treba nekatere možnosti prepisati in narediti tako, da delujejo hitreje. in z boljšo zmogljivostjo.
In ker govorimo o bazi podatkov, je baza podatkov vedno proces v ozadju. Procesi v ozadju pomagajo vzdrževati zmogljivost baze podatkov na dobri ravni, zato za delovanje potrebujejo določeno količino virov. Hkrati se lahko prekrivajo z viri zahtev odjemalcev, tako da lahko pohlepni procesi v ozadju neposredno vplivajo na delovanje zahtev odjemalcev. Zato jih je treba tudi spremljati in spremljati, da ne pride do izkrivljanj v smislu procesov v ozadju.
In vse to v smislu spremljanja baze podatkov ostaja v sistemski metriki. Toda glede na to, da se večina naše infrastrukture seli v oblake, sistemske metrike posameznega gostitelja vedno zbledijo v ozadje. Toda v podatkovnih bazah so še vedno relevantni in seveda je treba spremljati tudi sistemske metrike.
S sistemskimi metrikami je vse bolj ali manj v redu, vsi sodobni nadzorni sistemi te metrike že podpirajo, a na splošno nekatere komponente še vedno niso dovolj in je treba nekatere stvari dodati. Dotaknil se jih bom tudi, o njih bo več diapozitivov.
Prva točka načrta je dostopnost. Kaj je dostopnost? Razpoložljivost po mojem razumevanju je zmožnost baze za servisiranje povezav, tj. osnova je dvignjena, kot storitev sprejema povezave strank. In to dostopnost je mogoče oceniti z nekaterimi značilnostmi. Te značilnosti je zelo priročno prikazati na nadzornih ploščah.
Vsi vedo, kaj so nadzorne plošče. To je, ko enkrat pogledate zaslon, na katerem so povzete potrebne informacije. In takoj lahko ugotovite, ali je v bazi podatkov težava ali ne.
V skladu s tem naj bodo razpoložljivost baze podatkov in druge ključne značilnosti vedno prikazane na nadzornih ploščah, tako da so ti podatki pri roki in vam vedno na voljo. Nekatere dodatne podrobnosti, ki že pomagajo pri preiskavi incidentov, jih je pri preiskavi nekaterih izrednih situacij že treba postaviti na sekundarne nadzorne plošče ali skriti v drilldown povezave, ki vodijo do nadzornih sistemov tretjih oseb.
Primer enega dobro znanega nadzornega sistema. To je zelo kul nadzorni sistem. Zbira veliko podatkov, a z mojega vidika ima čuden koncept nadzornih plošč. Obstaja povezava za »ustvarjanje nadzorne plošče«. Toda ko ustvarite nadzorno ploščo, ustvarite seznam dveh stolpcev, seznam grafov. In ko morate nekaj pogledati, začnete klikati z miško, listati, iskati želeni grafikon. In to zahteva čas, tj. nadzornih plošč kot takih ni. Obstajajo samo seznami grafikonov.
Kaj bi morali dodati tem nadzornim ploščam? Začnete lahko s tako značilnostjo, kot je odzivni čas. PostgreSQL ima pogled pg_stat_statements. Privzeto je onemogočen, vendar je eden od pomembnih sistemskih pogledov, ki ga morate vedno omogočiti in uporabljati. Shranjuje informacije o vseh tekočih poizvedbah, ki so bile izvedene v bazi podatkov.
V skladu s tem lahko izhajamo iz dejstva, da lahko vzamemo skupni čas izvedbe vseh zahtev in ga delimo s številom zahtevkov z uporabo zgornjih polj. Ampak to je povprečna temperatura v bolnišnici. Izhajamo lahko iz drugih polj – minimalni čas izvajanja poizvedbe, maksimum in mediana. In lahko celo zgradimo percentile; PostgreSQL ima za to ustrezne funkcije. In lahko dobimo nekaj številk, ki označujejo odzivni čas naše baze podatkov za že dokončane zahteve, tj. ne izvajamo lažne zahteve 'izberi 1' in pogledamo odzivni čas, ampak analiziramo odzivni čas za že dokončane zahteve in žrebamo bodisi ločena slika ali pa na njeni podlagi zgradimo graf.
Prav tako je pomembno spremljati število napak, ki jih trenutno generira sistem. In za to lahko uporabite pogled pg_stat_database. Osredotočeni smo na polje xact_rollback. To polje ne prikazuje le števila povrnitev, ki se pojavijo v bazi podatkov, ampak upošteva tudi število napak. Relativno gledano lahko to številko prikažemo na naši nadzorni plošči in vidimo, koliko napak imamo trenutno. Če je napak veliko, potem je to dober razlog, da pogledate v dnevnike in ugotovite, za kakšne napake gre in zakaj se pojavljajo, ter jih nato investirate in rešite.
Dodate lahko tako stvar, kot je tahometer. To sta število transakcij na sekundo in število zahtevkov na sekundo. Relativno gledano, lahko te številke uporabite kot trenutno zmogljivost vaše baze podatkov in opazujete, ali obstajajo konice v zahtevah, konice v transakcijah ali, nasprotno, ali je baza podatkov premalo obremenjena, ker je neko zaledje odpovedalo. Pomembno je, da vedno pogledate to številko in se spomnite, da je za naš projekt takšna uspešnost normalna, vendar so vrednosti zgoraj in spodaj že nekako problematične in nerazumljive, kar pomeni, da moramo pogledati, zakaj so te številke tako visoka.
Za oceno števila transakcij se lahko spet sklicujemo na pogled pg_stat_database. Dodamo lahko število potrditev in število povrnitev nazaj in dobimo število transakcij na sekundo.
Ali vsi razumejo, da se lahko več zahtev prilega eni transakciji? Zato se TPS in QPS nekoliko razlikujeta.
Število zahtev na sekundo lahko pridobite iz pg_stat_statements in preprosto izračunate vsoto vseh opravljenih zahtev. Jasno je, da primerjamo trenutno vrednost s prejšnjo, jo odštejemo, dobimo delto in dobimo količino.
Po želji lahko dodate dodatne meritve, ki prav tako pomagajo oceniti razpoložljivost naše baze podatkov in spremljati, ali je prišlo do izpadov.
Ena od teh meritev je čas delovanja. Toda čas delovanja v PostgreSQL je nekoliko težaven. Povedal ti bom zakaj. Ko se PostgreSQL zažene, se začne poročati o času delovanja. Toda če se je na neki točki, na primer, neka naloga izvajala ponoči, je prišel OOM-killer in na silo prekinil podrejeni proces PostgreSQL, potem v tem primeru PostgreSQL prekine povezavo vseh odjemalcev, ponastavi razdeljeno pomnilniško območje in začne obnovitev iz zadnja kontrolna točka. In medtem ko ta obnovitev s kontrolne točke traja, baza podatkov ne sprejema povezav, kar pomeni, da je to stanje mogoče oceniti kot izpad. Toda števec časa delovanja ne bo ponastavljen, ker upošteva čas zagona postmasterja od prvega trenutka. Zato lahko takšne situacije preskočimo.
Prav tako morate spremljati število vakuumskih delavcev. Ali vsi vedo, kaj je avtovacuum v PostgreSQL? To je zanimiv podsistem v PostgreSQL. O njej je bilo napisanih veliko člankov, narejenih je bilo veliko reportaž. O vakuumu in njegovem delovanju je veliko razprav. Mnogi menijo, da je nujno zlo. Ampak tako pač je. To je nekakšen analog zbiralnika smeti, ki čisti zastarele različice vrstic, ki jih nobena transakcija ne potrebuje, in sprosti prostor v tabelah in indeksih za nove vrstice.
Zakaj ga morate spremljati? Ker vakum včasih zelo boli. Porabi veliko virov in zaradi tega začnejo trpeti zahteve strank.
In spremljati ga je treba prek pogleda pg_stat_activity, o katerem bom govoril v naslednjem razdelku. Ta pogled prikazuje trenutno dejavnost v bazi podatkov. S to dejavnostjo lahko sledimo številu sesalnikov, ki trenutno delujejo. Lahko sledimo vakuumom in vidimo, da če smo presegli omejitev, je to razlog, da pogledamo v nastavitve PostgreSQL in nekako optimiziramo delovanje vakuuma.
Druga stvar pri PostgreSQL je, da je PostgreSQL zelo naveličan dolgih transakcij. Še posebej pri transakcijah, ki dolgo časa visijo in ne naredijo ničesar. To je tako imenovani stat idle-in-transaction. Takšna transakcija zadrži ključavnice in prepreči delovanje vakuuma. In kot rezultat, mize nabreknejo in povečajo velikost. In poizvedbe, ki delujejo s temi tabelami, začnejo delovati počasneje, ker morate prenesti vse stare različice vrstic iz pomnilnika na disk in nazaj. Zato je treba spremljati tudi čas, trajanje najdaljših transakcij, najdaljše vakuumske zahteve. In če opazimo nekatere procese, ki tečejo že zelo dolgo, že več kot 10-20-30 minut za nalaganje OLTP, potem moramo biti pozorni nanje in jih prisilno prekiniti ali optimizirati aplikacijo tako, da niso poklicani in ne visijo tako dolgo. Za analitično obremenitev je normalno 10-20-30 minut, obstajajo tudi daljše.
Nato imamo možnost s povezanimi odjemalci. Ko smo že ustvarili nadzorno ploščo in na njej objavili ključne metrike razpoložljivosti, lahko vanjo dodamo tudi dodatne informacije o povezanih odjemalcih.
Informacije o povezanih odjemalcih so pomembne, ker so z vidika PostgreSQL odjemalci različni. So dobre stranke in obstajajo slabe stranke.
Preprost primer. Pod stranko razumem aplikacijo. Aplikacija se je povezala z bazo podatkov in tja takoj začne pošiljati svoje zahteve, baza jih obdela in izvede ter rezultate vrne odjemalcu. To so dobre in korektne stranke.
Obstajajo situacije, ko se odjemalec poveže, zadrži povezavo, vendar ne naredi ničesar. Je v stanju mirovanja.
Toda obstajajo slabe stranke. Isti odjemalec se je na primer povezal, odprl transakcijo, naredil nekaj v bazi podatkov in nato šel v kodo, na primer za dostop do zunanjega vira ali za obdelavo prejetih podatkov tam. A transakcije ni sklenil. In transakcija visi v bazi podatkov in je zadržana v ključavnici na liniji. To je slabo stanje. In če nenadoma aplikacija nekje v sebi z izjemo odpove, potem lahko transakcija ostane odprta zelo dolgo. In to neposredno vpliva na zmogljivost PostgreSQL. PostgreSQL bo počasnejši. Zato je pomembno, da takšne stranke pravočasno izsledimo in njihovo delo prisilno prekinemo. In svojo aplikacijo morate optimizirati, da do takšnih situacij ne pride.
Druge slabe stranke so čakajoče stranke. Vendar postanejo slabi zaradi okoliščin. Na primer preprosta nedejavna transakcija: lahko odpre transakcijo, zaklene nekatere vrstice, nato pa nekje v kodi ne bo uspela, zaradi česar bo transakcija visela. Prišel bo drug odjemalec in zahteval iste podatke, vendar bo naletel na zaklepanje, ker ta viseča transakcija že drži ključavnice na nekaterih zahtevanih vrsticah. In druga transakcija bo visela naokoli in čakala, da prva transakcija dokonča ali pa jo skrbnik prisilno zapre. Zato se lahko čakajoče transakcije kopičijo in zapolnijo omejitev povezave z bazo podatkov. In ko je limit poln, aplikacija ne more več delati z bazo podatkov. To je že izredna situacija za projekt. Zato je treba slabim strankam slediti in se nanje pravočasno odzvati.
Še en primer spremljanja. In tukaj je že spodobna armaturna plošča. Zgoraj so informacije o povezavah. DB priključek – 8 kosov. In to je vse. Nimamo podatkov o tem, kateri odjemalci so aktivni, kateri odjemalci samo mirujejo in ne delajo ničesar. Ni informacij o čakajočih transakcijah in čakajočih povezavah, to je številka, ki prikazuje število povezav in to je to. In potem ugibajte sami.
V skladu s tem morate za dodajanje teh informacij spremljanju dostopati do sistemskega pogleda pg_stat_activity. Če veliko časa preživite v PostgreSQL, potem je to zelo dober pogled, ki naj postane vaš prijatelj, saj prikazuje trenutno aktivnost v PostgreSQL, torej kaj se v njem dogaja. Za vsak proces je ločena vrstica, ki prikazuje informacije o tem procesu: iz katerega gostitelja je bila vzpostavljena povezava, pod katerim uporabnikom, pod katerim imenom, kdaj se je transakcija začela, katera zahteva se trenutno izvaja, katera zahteva je bila nazadnje izvedena. In v skladu s tem lahko ocenimo stanje stranke s pomočjo polja stat. Relativno gledano lahko združimo po tem polju in pridobimo tiste statistike, ki so trenutno v bazi podatkov, in število povezav, ki imajo to statistiko v bazi podatkov. In že prejete številke lahko pošljemo v naš monitoring in na podlagi njih izrišemo grafe.
Prav tako je pomembno oceniti trajanje transakcije. Rekel sem že, da je pomembno oceniti trajanje vakuumov, vendar se transakcije ocenjujejo na enak način. Obstajata polji xact_start in query_start. Relativno gledano prikazujejo začetni čas transakcije in začetni čas zahteve. Vzamemo funkcijo now(), ki prikazuje trenutni časovni žig, in odštejemo časovni žig transakcije in zahteve. In dobimo trajanje transakcije, trajanje zahteve.
Če vidimo dolge transakcije, bi jih morali že dokončati. Za obremenitev OLTP so dolge transakcije že več kot 1-2-3 minute. Za delovno obremenitev OLAP so dolge transakcije normalne, a če trajajo več kot dve uri, da se dokončajo, je to tudi znak, da imamo nekje zaostanek.
Ko se stranke povežejo z bazo podatkov, začnejo delati z našimi podatki. Dostopajo do tabel, dostopajo do indeksov, da dobijo podatke iz tabele. In pomembno je oceniti, kako stranke komunicirajo s temi podatki.
To je potrebno, da ocenimo našo delovno obremenitev in približno razumemo, katere tabele so za nas "najbolj vroče". To je na primer potrebno v situacijah, ko želimo "vroče" mize postaviti na nekakšen hitri SSD pomnilnik. Na primer, nekatere arhivske tabele, ki jih že dolgo nismo uporabljali, lahko premaknemo v nekakšen "hladen" arhiv, na pogone SATA in jih pustimo živeti tam, do njih bomo dostopali po potrebi.
To je uporabno tudi za odkrivanje nepravilnosti po kakršnih koli izdajah in uvedbah. Recimo, da je projekt izdal kakšno novo funkcijo. Dodali smo na primer nove funkcionalnosti za delo z bazo podatkov. In če izrišemo grafe uporabe tabele, lahko zlahka zaznamo te anomalije na teh grafih. Na primer, posodobite rafale ali izbrišite rafale. Zelo bo vidno.
Odkrijete lahko tudi anomalije v "lebdeči" statistiki. Kaj to pomeni? PostgreSQL ima zelo močan in zelo dober razporejevalnik poizvedb. In razvijalci posvečajo veliko časa njegovemu razvoju. Kako deluje? Za izdelavo dobrih načrtov PostgreSQL zbira statistiko o porazdelitvi podatkov v tabelah v določenem časovnem intervalu in z določeno frekvenco. To so najpogostejše vrednosti: število edinstvenih vrednosti, informacije o NULL v tabeli, veliko informacij.
Na podlagi te statistike načrtovalec sestavi več poizvedb, izbere najbolj optimalno in na podlagi tega načrta poizvedbe izvede samo poizvedbo in vrne podatke.
In zgodi se, da statistika "plava". Podatki o kvaliteti in količini so se v tabeli nekako spremenili, statistika pa se ni zbirala. In oblikovani načrti morda niso optimalni. In če se bodo naši načrti na podlagi zbranega monitoringa izkazali za neoptimalne, bomo na podlagi tabel lahko videli te anomalije. Na primer, nekje so se podatki kvalitativno spremenili in namesto indeksa se je začel uporabljati zaporedni prehod skozi tabelo, tj. če mora poizvedba vrniti le 100 vrstic (obstaja omejitev 100), bo za to poizvedbo izvedeno celotno iskanje. In to vedno zelo slabo vpliva na uspešnost.
In to lahko vidimo pri spremljanju. In že si oglejte to poizvedbo, zaženite razlago zanjo, zberite statistiko, zgradite nov dodatni indeks. In se že odzvati na ta problem. Zato je pomembno.
Še en primer spremljanja. Mislim, da ga je veliko ljudi prepoznalo, ker je zelo priljubljen. Ki ga uporabljajo v svojih projektih ? Kdo uporablja ta izdelek v povezavi s Prometheusom? Dejstvo je, da v standardnem repozitoriju tega spremljanja obstaja nadzorna plošča za delo s PostgreSQL - Prometej. Vendar obstaja ena slaba podrobnost.
Obstaja več grafov. In bajti so označeni kot enota, tj. obstaja 5 grafov. To so Vstavi podatke, Posodobi podatke, Izbriši podatke, Pridobi podatke in Vrni podatke. Merska enota je bajt. Toda stvar je v tem, da statistika v PostgreSQL vrne podatke v tuple (vrstice). In zato so ti grafi zelo dober način, da večkrat, desetkrat podcenite svojo delovno obremenitev, ker tuple ni bajt, torka je niz, je veliko bajtov in je vedno spremenljive dolžine. To pomeni, da je izračun delovne obremenitve v bajtih z uporabo tupl nerealistična ali zelo težka naloga. Zato je pri uporabi nadzorne plošče ali vgrajenega nadzora vedno pomembno razumeti, da deluje pravilno in vam vrača pravilno ocenjene podatke.
Kako do statistike na teh tabelah? V ta namen ima PostgreSQL določeno družino pogledov. In glavni pogled je . Uporabniške_tabele - to pomeni tabele, ustvarjene v imenu uporabnika. Nasprotno pa obstajajo sistemski pogledi, ki jih uporablja sam PostgreSQL. In obstaja zbirna tabela Alltables, ki vključuje sistemske in uporabniške. Začnete lahko s katerim koli od njih, ki vam je najbolj všeč.
Z uporabo zgornjih polj lahko ocenite število vstavkov, posodobitev in izbrisov. Primer nadzorne plošče, ki sem ga uporabil, uporablja ta polja za ovrednotenje značilnosti delovne obremenitve. Zato lahko na njih tudi gradimo. Vendar si velja zapomniti, da so to tuple in ne bajti, zato tega ne moremo narediti samo v bajtih.
Na podlagi teh podatkov lahko sestavimo tako imenovane TopN tabele. Na primer Top-5, Top-10. Sledite lahko tistim vročim mizam, ki se reciklirajo več kot druge. Na primer, 5 "vročih" tabel za vstavljanje. Z uporabo teh tabel TopN ocenjujemo svojo delovno obremenitev in lahko ocenimo izbruhe delovne obremenitve po kakršnih koli izdajah, posodobitvah in uvedbah.
Prav tako je pomembno oceniti velikost tabele, ker včasih razvijalci uvedejo novo funkcijo in naše tabele začnejo naraščati v svojih velikih velikostih, ker so se odločili dodati dodatno količino podatkov, vendar niso predvideli, kako bo to vplivajo na velikost baze podatkov. Taki primeri so tudi za nas presenečenje.
In zdaj majhno vprašanje za vas. Kakšno vprašanje se pojavi, ko opazite obremenitev strežnika baze podatkov? Katero je vaše naslednje vprašanje?
Toda v resnici se vprašanje postavlja na naslednji način. Kakšne zahteve povzroča obremenitev? To pomeni, da ni zanimivo gledati na procese, ki jih povzroča obremenitev. Jasno je, da če ima gostitelj bazo podatkov, se ta tam izvaja in jasno je, da bodo tam odstranjene samo baze podatkov. Če odpremo Top, bomo tam videli seznam procesov v PostgreSQL, ki nekaj delajo. Iz vrha ne bo jasno, kaj počnejo.
V skladu s tem morate poiskati tiste poizvedbe, ki povzročajo največjo obremenitev, saj nastavitev poizvedb praviloma prinaša več dobička kot nastavitev PostgreSQL ali konfiguracije operacijskega sistema ali celo nastavitev strojne opreme. Po moji oceni je to približno 80-85-90%. In to se naredi veliko hitreje. Hitreje je popraviti zahtevo kot popraviti konfiguracijo, načrtovati ponovni zagon, zlasti če baze podatkov ni mogoče znova zagnati, ali dodati strojno opremo. Lažje je poizvedbo nekam prepisati ali dodati indeks, da dobite boljši rezultat te poizvedbe.
V skladu s tem je potrebno spremljati zahteve in njihovo ustreznost. Vzemimo še en primer spremljanja. In tudi tukaj se zdi, da je spremljanje odlično. Obstajajo informacije o replikaciji, obstajajo informacije o prepustnosti, blokiranju, uporabi virov. Vse je v redu, vendar ni informacij o zahtevah. Ni jasno, katere poizvedbe se izvajajo v naši bazi podatkov, kako dolgo se izvajajo, koliko je teh poizvedb. Te informacije moramo vedno imeti pri spremljanju.
Za pridobitev teh informacij lahko uporabimo modul pg_stat_statements. Na njegovi podlagi lahko sestavite različne grafe. Tako lahko na primer pridobite informacije o najpogostejših poizvedbah, torej o tistih poizvedbah, ki se najpogosteje izvajajo. Da, po uvedbah je prav tako zelo koristno, da si ga ogledate in ugotovite, ali je prišlo do povečanja zahtev.
Spremljate lahko najdaljše poizvedbe, to je tiste poizvedbe, ki trajajo najdlje. Delujejo na procesorju, porabljajo I/O. To lahko ovrednotimo tudi z uporabo polj total_time, mean_time, blk_write_time in blk_read_time.
Ocenjujemo in spremljamo lahko najtežje zahteve glede porabe virov, tiste, ki berejo z diska, ki delajo s pomnilnikom ali, nasprotno, ustvarjajo nekakšno pisalno obremenitev.
Ocenimo lahko najbolj velikodušne zahteve. To so poizvedbe, ki vrnejo veliko število vrstic. Na primer, to je lahko neka zahteva, pri kateri so pozabili nastaviti omejitev. In preprosto vrne celotno vsebino tabele ali poizvedbe v poizvedovanih tabelah.
Prav tako lahko spremljate poizvedbe, ki uporabljajo začasne datoteke ali začasne tabele.
In še vedno imamo procese v ozadju. Procesi v ozadju so predvsem kontrolne točke ali jih imenujemo tudi kontrolne točke, to sta avtovakuum in replikacija.
Še en primer spremljanja. Na levi je zavihek Vzdrževanje, pojdite nanj in upajte, da boste videli kaj koristnega. Ampak tukaj je samo čas delovanja vakuuma in zbiranje statistike, nič več. To je zelo slaba informacija, zato moramo vedno imeti informacije o tem, kako procesi v ozadju delujejo v naši bazi podatkov in ali obstajajo težave pri njihovem delu.
Ko gledamo kontrolne točke, ne smemo pozabiti, da kontrolne točke splaknejo umazane strani iz razdeljenega pomnilniškega območja na disk, nato pa ustvarijo kontrolno točko. In to kontrolno točko lahko nato uporabite kot prostor za obnovitev, če je bil PostgreSQL nenadoma prekinjen v sili.
V skladu s tem morate za izpiranje vseh "umazanih" strani na disk opraviti določeno količino pisanja. In praviloma je v sistemih z veliko količino pomnilnika to veliko. In če izvajamo kontrolne točke zelo pogosto v kratkem intervalu, bo zmogljivost diska zelo padla. In zahteve strank bodo trpele zaradi pomanjkanja virov. Tekmovali bodo za vire in premalo produktivnosti.
V skladu s tem lahko prek pg_stat_bgwriter z uporabo navedenih polj spremljamo število kontrolnih točk, ki se pojavijo. In če imamo v določenem času veliko kontrolnih točk (v 10-15-20 minutah, v pol ure), na primer 3-4-5, potem je to že lahko problem. In že morate pogledati v bazo podatkov, pogledati v konfiguracijo, kaj povzroča tako obilico kontrolnih točk. Mogoče se dogaja kakšno veliko snemanje. Obremenitev že lahko ocenimo, saj smo že dodali grafe obremenitev. Parametre kontrolne točke lahko že prilagodimo in poskrbimo, da ne bodo močno vplivali na zmogljivost poizvedbe.
Ponovno se vračam k samodejnemu vakuumu, ker je to taka stvar, kot sem rekel, ki zlahka sešteje zmogljivost diska in poizvedbe, zato je vedno pomembno oceniti količino samodejnega vakuuma.
Število avtovakuumskih delavcev v bazi je omejeno. Privzeto so trije, tako da če imamo vedno tri delavce, ki delajo v bazi, to pomeni, da naš avtovakuum ni konfiguriran, moramo dvigniti omejitve, pregledati nastavitve avtovakuuma in vstopiti v konfiguracijo.
Pomembno je oceniti, katere vakuumske delavce imamo. Bodisi ga je zagnal uporabnik, prišel je DBA in ročno sprožil nekakšen vakuum, kar je povzročilo obremenitev. Imamo nekakšen problem. Ali pa je to število vakuumov, ki odvijejo števec transakcij. Za nekatere različice PostgreSQL so to zelo veliki vakuumi. Z lahkoto lahko seštejejo uspešnost, ker preberejo celotno tabelo, pregledajo vse bloke v tej tabeli.
In seveda trajanje vakuumov. Če imamo dolgotrajne vakuume, ki delujejo zelo dolgo, potem to pomeni, da moramo ponovno paziti na konfiguracijo vakuuma in morda ponovno razmisliti o njegovih nastavitvah. Ker lahko pride do situacije, ko vakuum deluje na mizi dlje časa (3-4 ure), vendar se je v času delovanja vakuuma v tabeli spet uspelo nabrati veliko mrtvih vrstic. In takoj ko je vakuum končan, mora to mizo ponovno posesati. In pridemo do situacije – neskončnega vakuuma. In v tem primeru se vakuum ne spopade s svojim delom in tabele se postopoma začnejo povečevati, čeprav količina uporabnih podatkov v njem ostaja enaka. Zato med dolgimi vakuumi vedno pogledamo konfiguracijo in jo poskušamo optimizirati, a hkrati tako, da ne trpi delovanje zahtev strank.
Dandanes praktično ni namestitve PostgreSQL, ki ne bi imela pretočne replikacije. Replikacija je postopek premikanja podatkov iz glavnega v repliko.
Replikacija v PostgreSQL poteka prek dnevnika transakcij. Čarovnik ustvari dnevnik transakcij. Dnevnik transakcij potuje prek omrežne povezave do replike, nato pa je reproduciran na replici. Enostavno je.
V skladu s tem se pogled pg_stat_replication uporablja za spremljanje zamika podvajanja. A z njo ni vse preprosto. V različici 10 je pogled doživel več sprememb. Prvič, nekatera polja so bila preimenovana. In nekaj polj je bilo dodanih. V različici 10 so se pojavila polja, ki vam omogočajo, da ocenite zamik replikacije v sekundah. Je zelo udobno. Pred različico 10 je bilo mogoče oceniti zamik podvajanja v bajtih. Ta možnost ostaja v različici 10, kar pomeni, da lahko izberete, kaj vam bolj ustreza - ocenite zamik v bajtih ali ocenite zamik v sekundah. Veliko ljudi počne oboje.
Toda kljub temu morate za oceno zamika replikacije poznati položaj dnevnika v transakciji. In ti položaji dnevnika transakcij so točno v pogledu pg_stat_replication. Relativno gledano lahko s funkcijo pg_xlog_location_diff() vzamemo dve točki v dnevniku transakcij. Izračunajte delto med njima in dobite zamik replikacije v bajtih. Je zelo priročno in preprosto.
V različici 10 je bila ta funkcija preimenovana v pg_wal_lsn_diff(). Na splošno je bila v vseh funkcijah, pogledih in pripomočkih, kjer se je pojavila beseda "xlog", zamenjana z vrednostjo "wal". To velja tako za poglede kot za funkcije. To je taka inovacija.
Poleg tega so bile v različici 10 dodane vrstice, ki posebej prikazujejo zamik. To so zakasnitev pri zapisovanju, zakasnitev pri splakovanju, zakasnitev pri ponovnem predvajanju. To pomeni, da je pomembno spremljati te stvari. Če opazimo, da imamo zaostanek replikacije, moramo raziskati, zakaj se je pojavil, od kod je prišel in odpraviti težavo.
S sistemskimi meritvami je skoraj vse v redu. Ko se začne spremljanje, se začne s sistemskimi meritvami. To je odstranitev procesorjev, pomnilnika, swapa, omrežja in diska. Vendar veliko parametrov ni privzetih.
Če je s postopkom recikliranja vse v redu, potem obstajajo težave z recikliranjem diska. Praviloma razvijalci spremljanja dodajo informacije o prepustnosti. Lahko je v iopih ali bajtih. Pozabljajo pa na zakasnitev in izkoriščenost diskovnih naprav. To so pomembnejši parametri, ki nam omogočajo, da ocenimo, kako obremenjeni so naši diski in kako počasni so. Če imamo visoko zakasnitev, potem to pomeni, da so težave z diski. Če imamo visoko izkoriščenost, pomeni, da diski ne zmorejo. To so boljše lastnosti kot prepustnost.
Poleg tega je to statistiko mogoče pridobiti tudi iz datotečnega sistema /proc, kot je storjeno za procesorje za recikliranje. Ne vem, zakaj te informacije niso dodane spremljanju. Kljub temu je pomembno, da to spremljate.
Enako velja za omrežne vmesnike. Obstaja podatek o prepustnosti omrežja v paketih, v bajtih, vendar kljub temu ni podatka o zakasnitvi in ni podatka o izkoriščenosti, čeprav je tudi to koristen podatek.
Vsako spremljanje ima slabosti. In ne glede na vrsto spremljanja, ki ga vzamete, vedno ne bo izpolnjevalo nekaterih meril. Toda kljub temu se razvijajo, dodajajo se nove funkcije in nove stvari, zato izberite nekaj in dokončajte.
In če želite končati, morate vedno imeti predstavo o tem, kaj pomenijo navedeni statistični podatki in kako jih lahko uporabite za reševanje težav.
In nekaj ključnih točk:
- Vedno morate spremljati razpoložljivost in imeti nadzorne plošče, da lahko hitro ocenite, ali je z bazo podatkov vse v redu.
- Vedno morate imeti predstavo o tem, katere stranke delajo z vašo bazo podatkov, da izločite slabe stranke in jih uničite.
- Pomembno je oceniti, kako te stranke delajo s podatki. Imeti morate predstavo o svoji delovni obremenitvi.
- Pomembno je oceniti, kako se ta delovna obremenitev oblikuje, s pomočjo katerih poizvedb. Lahko ocenite poizvedbe, jih lahko optimizirate, preuredite, zgradite indekse zanje. Je zelo pomembno.
- Procesi v ozadju lahko negativno vplivajo na zahteve strank, zato je pomembno spremljati, da ne uporabljajo preveč virov.
- Sistemske metrike vam omogočajo, da naredite načrte za skaliranje in povečanje zmogljivosti vaših strežnikov, zato je pomembno, da jim tudi sledite in ocenjujete.
Če vas ta tema zanima, lahko sledite tem povezavam.
- to je uradna dokumentacija zbiralnika statistik. Obstaja opis vseh statističnih pogledov in opis vseh polj. Lahko jih berete, razumete in analizirate. Na njihovi podlagi zgradite svoje grafe in jih dodajte svojemu spremljanju.
Primeri zahtev:
To je naše korporativno skladišče in moje lastno. Vsebujejo primere poizvedb. Tam ni nobenih poizvedb iz serije select* from. Obstajajo že pripravljene poizvedbe z združitvami, ki uporabljajo zanimive funkcije, ki vam omogočajo, da neobdelana števila pretvorite v berljive, priročne vrednosti, to so bajti, čas. Lahko jih poberete, si jih ogledate, analizirate, dodate svojemu spremljanju in na njih zgradite svoje spremljanje.
vprašanja
Vprašanje: Rekli ste, da ne boste oglaševali blagovnih znamk, vendar me vseeno zanima - kakšne nadzorne plošče uporabljate v svojih projektih?
Odgovor: Razlikuje se. Zgodi se, da pridemo do stranke in ta že ima svoj monitoring. Stranki pa svetujemo, kaj naj doda k spremljanju. Najhuje je z Zabbixom. Ker nima zmožnosti gradnje grafov TopN. Sami uporabljamo , ker smo se s temi fanti posvetovali o spremljanju. Spremljali so PostgreSQL na podlagi naših tehničnih specifikacij. Pišem svoj hišni projekt, ki zbira podatke prek Prometheusa in jih upodablja v . Moja naloga je ustvariti svoj izvoznik v Prometheusu in nato vse upodobiti v Grafani.
Vprašanje: Ali obstajajo analogi poročil AWR ali ... združevanja? Veš za kaj takega?
Odgovor: Da, vem, kaj je AWR, to je kul stvar. Trenutno obstaja vrsta koles, ki izvajajo približno naslednji model. V določenem časovnem intervalu se nekatere osnovne črte zapišejo v isti PostgreSQL ali v ločeno shrambo. Lahko jih poguglaš na internetu, tam so. Eden od razvijalcev takšne stvari sedi na forumu sql.ru v temi PostgreSQL. Lahko ga ujamete tam. Da, obstajajo takšne stvari, jih je mogoče uporabiti. Plus v svojem Pišem tudi stvar, ki vam omogoča, da naredite isto.
PS1 Če uporabljate postgres_exporter, katero nadzorno ploščo uporabljate? Več jih je. So že zastareli. Morda bo skupnost ustvarila posodobljeno predlogo?
PS2 Odstranjen pganalyze, ker gre za lastniško ponudbo SaaS, ki se osredotoča na spremljanje zmogljivosti in predloge za samodejno uravnavanje.
V anketi lahko sodelujejo samo registrirani uporabniki. , prosim.
Katero samostojno spremljanje postgresql (z nadzorno ploščo) se vam zdi najboljše?
-
30,0%Zabbix + dodatki Alekseja Lesovskega ali zabbix 4.4 ali libzbxpgsql + zabbix libzbxpgsql + zabbix3
-
0,0%https://github.com/lesovsky/pgcenter0
-
0,0%https://github.com/pg-monz/pg_monz0
-
20,0%https://github.com/cybertec-postgresql/pgwatch22
-
20,0%https://github.com/postgrespro/mamonsu2
-
0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
-
10,0%pganalyze je lastniški SaaS - ne morem ga izbrisati1
-
10,0%https://github.com/powa-team/powa1
-
0,0%https://github.com/darold/pgbadger0
-
0,0%https://github.com/darold/pgcluu0
-
0,0%https://github.com/zalando/PGObserver0
-
10,0%https://github.com/spotify/postgresql-metrics1
Glasovalo je 10 uporabnikov. 26 uporabnikov se je vzdržalo.
Vir: www.habr.com