Predlažem da pročitate prijepis izvješća Alexeya Lesovskog iz Data Egreta “Osnove nadzora PostgreSQL-a”
Alexey Lesovsky će u ovom izvješću govoriti o ključnim točkama statistike nakon progresa, što one znače i zašto bi trebale biti prisutne u praćenju; o tome koji bi grafikoni trebali biti u praćenju, kako ih dodati i kako ih interpretirati. Izvješće će biti korisno administratorima baza podataka, administratorima sustava i programerima koji su zainteresirani za rješavanje problema s Postgresom.
Moje ime je Alexey Lesovsky, predstavljam tvrtku Data Egret.
Nekoliko riječi o sebi. Počeo sam davno kao sistemski administrator.
Administrirao sam razne vrste Linux sustava, radio na raznim stvarima vezanim uz Linux, tj. virtualizacija, nadgledanje, radio s proxyjima itd. Ali u nekom sam trenutku počeo više raditi s bazama podataka, PostgreSQL. Jako mi se svidio. I u nekom sam trenutku počeo raditi na PostgreSQL-u većinu svog radnog vremena. I tako sam postupno postao PostgreSQL DBA.
I tijekom moje karijere uvijek su me zanimale teme statistike, praćenja i telemetrije. A kad sam bio sistemski administrator, vrlo sam blisko surađivao sa Zabbixom. I napisao sam mali set scenarija poput . Bio je prilično popularan u svoje vrijeme. I tamo je bilo moguće pratiti vrlo različite važne stvari, ne samo Linux, nego i razne komponente.
Sada radim na PostgreSQL-u. Već pišem još jednu stvar koja vam omogućuje rad s PostgreSQL statistikom. To se zove (članak na Habréu - ).
Mala uvodna napomena. U kakvim se situacijama nalaze naši kupci, naši klijenti? Dogodila se neka nezgoda u vezi s bazom podataka. I kada je baza već vraćena, dolazi šef odjela ili voditelj razvoja i kaže: “Prijatelji, moramo pratiti bazu, jer se nešto loše dogodilo i moramo spriječiti da se to ubuduće događa.” I tu počinje zanimljiv proces odabira sustava za nadzor ili prilagođavanja postojećeg sustava za nadzor kako biste mogli pratiti svoju bazu podataka - PostgreSQL, MySQL ili neke druge. I kolege počinju sugerirati: “Čuo sam da postoji ta i ta baza podataka. Iskoristimo ga." Kolege se počinju međusobno svađati. I na kraju ispadne da odaberemo nekakvu bazu podataka, ali je u njoj PostgreSQL monitoring dosta slabo prikazan i uvijek moramo nešto dodavati. Uzmite neke repozitorije s GitHuba, klonirajte ih, prilagodite skripte i nekako ih prilagodite. I na kraju to ispadne neka vrsta ručnog rada.
Stoga ću vam u ovom govoru pokušati dati neka znanja o tome kako odabrati nadzor ne samo za PostgreSQL, već i za bazu podataka. I dati vam znanje koje će vam omogućiti da dovršite svoj nadzor kako biste od njega imali neke koristi, tako da možete s dobrom nadzirati svoju bazu podataka, kako biste odmah spriječili sve nadolazeće hitne situacije koje se mogu pojaviti.
A ideje koje će biti u ovom izvješću mogu se izravno prilagoditi bilo kojoj bazi podataka, bilo da se radi o DBMS-u ili noSQL-u. Dakle, ne postoji samo PostgreSQL, već će biti mnogo recepata kako to učiniti u PostgreSQL-u. Bit će primjera upita, primjera entiteta koje PostgreSQL ima za praćenje. A ako vaš DBMS ima iste stvari koje vam omogućuju da ih stavite u nadzor, možete ih također prilagoditi, dodati i bit će dobro.
Neću biti u izvješću
govoriti o tome kako isporučiti i pohraniti metriku. Neću reći ništa o naknadnoj obradi podataka i njihovom prezentiranju korisniku. A o uzbunjivanju neću ništa reći.
Ali kako priča bude napredovala, pokazat ću različite snimke zaslona postojećeg nadzora i nekako ih kritizirati. Ali ipak ću pokušati ne imenovati brendove kako ne bih stvarao reklamu ili antireklamu za te proizvode. Stoga su sve slučajnosti slučajne i prepuštene vašoj mašti.
Prvo, shvatimo što je praćenje. Monitoring je vrlo važna stvar. Svi to razumiju. Ali u isto vrijeme, praćenje se ne odnosi na poslovni proizvod i ne utječe izravno na dobit tvrtke, tako da se vrijeme uvijek dodjeljuje za praćenje na rezidualnoj osnovi. Ako imamo vremena, onda radimo monitoring; ako nemamo vremena, onda OK, stavit ćemo to u zaostatke i jednog dana ćemo se vratiti tim zadacima.
Stoga, iz naše prakse, kada dolazimo do klijenata, monitoring je često nepotpun i nema nikakvih zanimljivosti koje bi nam pomogle da bolje radimo s bazom podataka. Stoga je praćenje uvijek potrebno dovršiti.
Baze podataka su tako složene stvari koje također treba nadzirati, jer su baze podataka skladište informacija. A informacija je vrlo važna za tvrtku, ne može se izgubiti ni na koji način. Ali u isto vrijeme baze podataka su vrlo složeni dijelovi softvera. Sastoje se od velikog broja komponenti. A mnoge od tih komponenti treba pratiti.
Ako govorimo konkretno o PostgreSQL-u, onda se može prikazati u obliku sheme koja se sastoji od velikog broja komponenti. Ove komponente međusobno djeluju. A u isto vrijeme, PostgreSQL ima takozvani Stats Collector podsustav, koji vam omogućuje prikupljanje statistike o radu ovih podsustava i pružanje neke vrste sučelja administratoru ili korisniku kako bi on mogao vidjeti te statistike.
Ove statistike prikazane su u obliku određenog skupa funkcija i prikaza. Također se mogu nazvati stolovima. To jest, korištenjem običnog psql klijenta, možete se spojiti na bazu podataka, napraviti odabir na ovim funkcijama i prikazima i dobiti neke specifične brojke o radu PostgreSQL podsustava.
Možete dodati ove brojeve svom omiljenom sustavu praćenja, crtati grafikone, dodavati funkcije i dugoročno dobivati analitiku.
Ali u ovom izvješću neću u potpunosti pokriti sve te funkcije jer bi moglo potrajati cijeli dan. Doslovno ću se osvrnuti na dvije, tri ili četiri stvari i reći vam kako one pomažu poboljšanju praćenja.
A ako govorimo o praćenju baze podataka, što onda treba pratiti? Prije svega, moramo pratiti dostupnost, jer baza je servis koji klijentima omogućuje pristup podacima te moramo pratiti dostupnost, ali i dati neke njezine kvalitativne i kvantitativne karakteristike.
Također moramo pratiti klijente koji se spajaju na našu bazu podataka, jer oni mogu biti i normalni klijenti i štetni klijenti koji mogu oštetiti bazu podataka. Također ih treba nadzirati i pratiti njihove aktivnosti.
Kada se klijenti spoje na bazu, očito je da počinju raditi s našim podacima, pa moramo pratiti kako klijenti rade s podacima: s kojim tablicama, au manjoj mjeri i s kojim indeksima. Odnosno, moramo procijeniti radno opterećenje koje stvaraju naši klijenti.
Ali radno opterećenje također se sastoji, naravno, od zahtjeva. Aplikacije se povezuju s bazom podataka, upitima pristupaju podacima, pa je važno procijeniti koje upite imamo u bazi, pratiti njihovu adekvatnost, da nisu krivo napisani, da neke opcije treba prepisati i napraviti da brže rade i s boljim performansama.
A budući da govorimo o bazi podataka, baza podataka je uvijek pozadinski proces. Pozadinski procesi pomažu u održavanju performansi baze podataka na dobroj razini, pa im je potrebna određena količina resursa za rad. U isto vrijeme, mogu se preklapati s resursima zahtjeva klijenta, tako da pohlepni pozadinski procesi mogu izravno utjecati na performanse zahtjeva klijenta. Stoga ih također treba nadzirati i pratiti kako ne bi došlo do izobličenja u smislu pozadinskih procesa.
I sve to u smislu praćenja baze podataka ostaje u metrici sustava. Ali s obzirom na to da se većina naše infrastrukture seli u oblake, metrika sustava pojedinačnog hosta uvijek nestaje u pozadini. Ali u bazama podataka oni su i dalje relevantni i, naravno, također je potrebno pratiti metriku sustava.
Sve je više-manje u redu s metrikom sustava, svi moderni sustavi za praćenje već podržavaju te metrike, ali općenito, neke komponente još uvijek nisu dovoljne i neke stvari treba dodati. Dotaknut ću se i njih, o njima će biti nekoliko slajdova.
Prva točka plana je pristupačnost. Što je pristupačnost? Dostupnost po mom razumijevanju je sposobnost baze da servisira veze, tj. baza je podignuta, ona, kao usluga, prihvaća veze od klijenata. A ta pristupačnost može se ocijeniti određenim karakteristikama. Vrlo je zgodno prikazati ove karakteristike na nadzornim pločama.
Svi znaju što su nadzorne ploče. To je kada bacite jedan pogled na ekran na kojem su sažete potrebne informacije. I možete odmah utvrditi postoji li problem u bazi podataka ili ne.
Sukladno tome, dostupnost baze podataka i ostale ključne karakteristike trebaju uvijek biti prikazane na nadzornim pločama kako bi ti podaci bili pri ruci i uvijek dostupni. Neki dodatni detalji koji već pomažu u istrazi incidenata, kada se istražuju neke hitne situacije, već ih je potrebno staviti na sekundarne nadzorne ploče ili sakriti u drilldown linkovima koji vode do sustava za nadzor trećih strana.
Primjer jednog dobro poznatog sustava nadzora. Ovo je vrlo cool sustav praćenja. Ona prikuplja mnogo podataka, ali s moje točke gledišta, ima čudan koncept nadzornih ploča. Postoji poveznica za "kreiranje nadzorne ploče". Ali kada izradite nadzornu ploču, stvorite popis od dva stupca, popis grafikona. A kad trebaš nešto pogledati, počneš klikati mišem, skrolati, tražiti željeni grafikon. A za to je potrebno vrijeme, tj. nema nadzornih ploča kao takvih. Postoje samo popisi karata.
Što biste trebali dodati ovim nadzornim pločama? Možete početi s takvom karakteristikom kao što je vrijeme odziva. PostgreSQL ima prikaz pg_stat_statements. Onemogućen je prema zadanim postavkama, ali je jedan od važnih prikaza sustava koji uvijek treba biti omogućen i korišten. Pohranjuje informacije o svim pokrenutim upitima koji su izvršeni u bazi podataka.
U skladu s tim, možemo početi od činjenice da možemo uzeti ukupno vrijeme izvršenja svih zahtjeva i podijeliti ga s brojem zahtjeva pomoću gornjih polja. Ali ovo je prosječna temperatura u bolnici. Možemo krenuti od drugih polja - minimalno vrijeme izvršenja upita, maksimalno i medijan. I možemo čak izgraditi percentile; PostgreSQL ima odgovarajuće funkcije za to. I možemo dobiti neke brojke koje karakteriziraju vrijeme odgovora naše baze podataka za već završene zahtjeve, tj. ne izvršavamo lažni zahtjev 'select 1' i gledamo vrijeme odgovora, već analiziramo vrijeme odgovora za već završene zahtjeve i izvlačimo ili zasebna slika, ili na temelju nje gradimo grafikon.
Također je važno pratiti broj grešaka koje trenutno generira sustav. A za ovo možete koristiti pogled pg_stat_database. Fokusiramo se na polje xact_rollback. Ovo polje pokazuje ne samo broj povrata koji se pojavljuju u bazi podataka, već također uzima u obzir broj pogrešaka. Relativno govoreći, možemo prikazati ovu brojku na našoj nadzornoj ploči i vidjeti koliko grešaka trenutno imamo. Ako ima puno grešaka, onda je to dobar razlog da pogledate u logove i vidite o kakvim se greškama radi i zašto se pojavljuju, a zatim uložite i riješite ih.
Možete dodati nešto poput tahometra. To su broj transakcija u sekundi i broj zahtjeva u sekundi. Relativno govoreći, ove brojke možete koristiti kao trenutnu izvedbu vaše baze podataka i promatrati ima li vršnih zahtjeva, vršnih transakcija ili, obrnuto, je li baza podataka nedovoljno opterećena jer je neki backend zakazao. Važno je uvijek gledati ovu brojku i zapamtiti da je za naš projekt ovakva izvedba normalna, ali vrijednosti iznad i ispod već su nekako problematične i neshvatljive, što znači da moramo pogledati zašto su ovi brojevi tako visoka.
Kako bismo procijenili broj transakcija, ponovno se možemo pozvati na pogled pg_stat_database. Možemo zbrojiti broj obveza i broj vraćanja i dobiti broj transakcija u sekundi.
Razumijete li svi da nekoliko zahtjeva može stati u jednu transakciju? Stoga se TPS i QPS malo razlikuju.
Broj zahtjeva u sekundi može se dobiti iz pg_stat_statements i jednostavno izračunati zbroj svih izvršenih zahtjeva. Jasno je da trenutnu vrijednost uspoređujemo s prethodnom, oduzimamo, dobivamo deltu i dobivamo količinu.
Po želji možete dodati dodatne metrike koje također pomažu u procjeni dostupnosti naše baze podataka i praćenju je li bilo zastoja.
Jedna od tih metrika je vrijeme neprekidnog rada. Ali vrijeme neprekidnog rada u PostgreSQL-u je malo nezgodno. Reći ću ti zašto. Kada se PostgreSQL pokrene, počinje se izvještavati o vremenu neprekidnog rada. Ali ako je u nekom trenutku, na primjer, neki zadatak bio pokrenut noću, OOM-killer je došao i prisilno ukinuo PostgreSQL podređeni proces, tada u ovom slučaju PostgreSQL prekida vezu svih klijenata, resetira dijeljeno memorijsko područje i započinje oporavak od posljednja kontrolna točka. I dok traje taj oporavak od kontrolne točke, baza ne prihvaća veze, odnosno ova situacija se može ocijeniti kao zastoj. Ali brojač vremena neprekidnog rada neće se poništiti jer uzima u obzir vrijeme pokretanja upravitelja pošte od prvog trenutka. Stoga se takve situacije mogu preskočiti.
Također biste trebali pratiti broj usisivača. Znaju li svi što je autovacuum u PostgreSQL-u? Ovo je zanimljiv podsustav u PostgreSQL-u. O njoj je napisano mnogo članaka, napravljeno mnogo reportaža. Puno se raspravlja o vakuumu i kako bi on trebao raditi. Mnogi ga smatraju nužnim zlom. Ali to je tako. Ovo je svojevrsni analog skupljača smeća koji čisti zastarjele verzije redaka koji nisu potrebni nijednoj transakciji i oslobađa prostor u tablicama i indeksima za nove retke.
Zašto ga trebate nadzirati? Jer vakuum ponekad jako boli. Troši veliku količinu resursa i zbog toga počinju trpjeti zahtjevi klijenata.
I treba ga pratiti kroz prikaz pg_stat_activity, o čemu ću govoriti u sljedećem odjeljku. Ovaj pogled prikazuje trenutnu aktivnost u bazi podataka. Kroz ovu aktivnost možemo pratiti broj usisavača koji trenutno rade. Možemo pratiti vakuume i vidjeti da ako smo prekoračili ograničenje, onda je to razlog da pogledamo PostgreSQL postavke i nekako optimiziramo rad vakuuma.
Još jedna stvar u vezi s PostgreSQL-om je da je PostgreSQL jako bolestan od dugih transakcija. Pogotovo od transakcija koje dugo stoje i ne rade ništa. Ovo je takozvani stat idle-in-transaction. Takva transakcija drži brave i sprječava rad vakuuma. Kao rezultat toga, stolovi nabubre i povećaju se u veličini. I upiti koji rade s tim tablicama počinju raditi sporije, jer trebate prebaciti sve stare verzije redaka iz memorije na disk i natrag. Stoga treba pratiti i vrijeme, trajanje najdužih transakcija, najduže zahtjeve za vakuumom. A ako vidimo neke procese koji se izvode jako dugo, već više od 10-20-30 minuta za OLTP učitavanje, tada moramo obratiti pozornost na njih i nasilno ih prekinuti ili optimizirati aplikaciju tako da nisu pozvani i ne vise tako dugo. Za analitičko opterećenje normalno je 10-20-30 minuta, a ima i dužih.
Zatim imamo opciju s povezanim klijentima. Kad smo već izradili nadzornu ploču i na njoj objavili ključne metrike dostupnosti, tamo možemo dodati i dodatne informacije o povezanim klijentima.
Informacije o povezanim klijentima važne su jer su, iz perspektive PostgreSQL-a, klijenti različiti. Postoje dobri klijenti i postoje loši klijenti.
Jednostavan primjer. Pod klijentom razumijem aplikaciju. Aplikacija se spojila na bazu podataka i odmah tamo počinje slati svoje zahtjeve, baza ih obrađuje i izvršava te rezultate vraća klijentu. To su dobri i korektni klijenti.
Postoje situacije kada se klijent spojio, drži vezu, ali ne radi ništa. U stanju mirovanja je.
Ali postoje loši klijenti. Na primjer, isti klijent se spojio, otvorio transakciju, napravio nešto u bazi podataka i zatim ušao u kod, na primjer, da pristupi vanjskom izvoru ili da tamo obradi primljene podatke. Ali nije zaključio transakciju. I transakcija visi u bazi podataka i drži se zaključana na liniji. Ovo je loše stanje. A ako iznenada aplikacija negdje unutar sebe zakaže uz iznimku, tada transakcija može ostati otvorena jako dugo. A to izravno utječe na performanse PostgreSQL-a. PostgreSQL će biti sporiji. Stoga je važno takve klijente pravovremeno pratiti i prisilno prekinuti njihov rad. I morate optimizirati svoju aplikaciju kako se takve situacije ne bi događale.
Ostali loši klijenti su klijenti na čekanju. Ali oni postaju loši zbog okolnosti. Na primjer, jednostavna neaktivna transakcija: može otvoriti transakciju, zaključati neke retke, a zatim negdje u kodu neće uspjeti, ostavljajući transakciju koja visi. Drugi će klijent doći i zatražiti iste podatke, ali će naići na zaključavanje, jer ta viseća transakcija već drži zaključavanje na nekim potrebnim redovima. A druga će transakcija lebdjeti čekajući da prva transakcija dovrši ili je administrator prisilno zatvori. Stoga se transakcije na čekanju mogu akumulirati i ispuniti ograničenje veze s bazom podataka. A kada je ograničenje popunjeno, aplikacija više ne može raditi s bazom podataka. Ovo je već hitna situacija za projekt. Stoga je loše klijente potrebno pratiti i na njih pravovremeno reagirati.
Još jedan primjer praćenja. A ovdje već postoji pristojna nadzorna ploča. Gore su informacije o vezama. DB priključak – 8 kom. I to je sve. Nemamo informacija koji su klijenti aktivni, koji samo miruju, ne rade ništa. Nema informacija o transakcijama na čekanju i vezama na čekanju, odnosno ovo je brojka koja pokazuje broj veza i to je to. A onda pogodite sami.
Sukladno tome, da biste dodali ove informacije u nadgledanje, morate pristupiti pg_stat_activity prikazu sustava. Ako provodite puno vremena u PostgreSQL-u, onda je ovo jako dobar pogled koji bi vam trebao postati prijatelj, jer pokazuje trenutnu aktivnost u PostgreSQL-u, odnosno što se u njemu događa. Za svaki proces postoji posebna linija koja prikazuje informacije o ovom procesu: s kojeg hosta je uspostavljena veza, pod kojim korisnikom, pod kojim imenom, kada je transakcija pokrenuta, koji se zahtjev trenutno izvodi, koji je zahtjev zadnji izvršen. I, sukladno tome, možemo procijeniti stanje klijenta pomoću polja statistike. Relativno govoreći, možemo grupirati prema ovom polju i dobiti one statistike koje su trenutno u bazi podataka i broj veza koje imaju tu statistiku u bazi podataka. A već dobivene brojke možemo poslati u naš monitoring i na temelju njih crtati grafikone.
Također je važno procijeniti trajanje transakcije. Već sam rekao da je važno procijeniti trajanje vakuuma, ali na isti način se ocjenjuju i transakcije. Postoje polja xact_start i query_start. Oni, relativno govoreći, pokazuju vrijeme početka transakcije i vrijeme početka zahtjeva. Uzimamo funkciju now(), koja prikazuje trenutnu vremensku oznaku, i oduzimamo vremensku oznaku transakcije i zahtjeva. I dobivamo trajanje transakcije, trajanje zahtjeva.
Ako vidimo duge transakcije, trebali bismo ih već dovršiti. Za OLTP opterećenje, duge transakcije već traju više od 1-2-3 minute. Za radno opterećenje OLAP-a, duge transakcije su normalne, ali ako im treba više od dva sata da se dovrše, onda je to također znak da negdje imamo zaokret.
Nakon što se klijenti povežu s bazom podataka, počinju raditi s našim podacima. Oni pristupaju tablicama, pristupaju indeksima kako bi dobili podatke iz tablice. I važno je procijeniti kako klijenti stupaju u interakciju s tim podacima.
Ovo je neophodno kako bismo procijenili naše radno opterećenje i otprilike shvatili koje su tablice za nas "najvruće". Na primjer, ovo je potrebno u situacijama kada želimo smjestiti “vruće” tablice na neku vrstu brze SSD memorije. Na primjer, neke arhivske tablice koje dugo nismo koristili možemo premjestiti u neku vrstu “hladne” arhive, na SATA diskove i pustiti ih da tamo žive, pristupat će im se po potrebi.
Ovo je također korisno za otkrivanje anomalija nakon bilo kakvih izdanja i implementacija. Recimo da je projekt izdao neku novu značajku. Na primjer, dodali smo novu funkcionalnost za rad s bazom podataka. A ako iscrtamo grafikone korištenja tablice, možemo lako otkriti te anomalije na tim grafikonima. Na primjer, ažurirajte nizove ili izbrišite nizove. Bit će vrlo vidljivo.
Također možete otkriti anomalije u "plutajućim" statistikama. Što to znači? PostgreSQL ima vrlo jak i vrlo dobar planer upita. A programeri posvećuju puno vremena njegovom razvoju. Kako on radi? Kako bi napravio dobre planove, PostgreSQL prikuplja statistiku o distribuciji podataka u tablicama u određenom vremenskom intervalu i s određenom učestalošću. Ovo su najčešće vrijednosti: broj jedinstvenih vrijednosti, informacije o NULL u tablici, puno informacija.
Na temelju te statistike, planer konstruira nekoliko upita, odabire najoptimalniji i koristi taj plan upita za izvršavanje samog upita i vraćanje podataka.
I događa se da statistika "pluta". Podaci o kvaliteti i kvantiteti su se nekako promijenili u tablici, ali statistika nije prikupljena. A formirani planovi možda nisu optimalni. I ako se naši planovi pokažu neoptimalnim na temelju prikupljenog monitoringa, na temelju tablica, moći ćemo vidjeti te anomalije. Na primjer, negdje su se podaci kvalitativno promijenili i umjesto indeksa počeo se koristiti sekvencijalni prolaz kroz tablicu, tj. ako upit treba vratiti samo 100 redaka (postoji ograničenje od 100), tada će se izvršiti potpuna pretraga za ovaj upit. A to uvijek jako loše utječe na izvedbu.
I to možemo vidjeti u praćenju. I već pogledajte ovaj upit, pokrenite objašnjenje za njega, prikupite statistiku, izgradite novi dodatni indeks. I već odgovorite na ovaj problem. Zato je važno.
Još jedan primjer praćenja. Mislim da su ga mnogi ljudi prepoznali jer je jako popularan. Koji ga koriste u svojim projektima ? Tko koristi ovaj proizvod u kombinaciji s Prometheusom? Činjenica je da u standardnom repozitoriju ovog nadzora postoji nadzorna ploča za rad s PostgreSQL - Prometej. Ali ima jedan loš detalj.
Postoji nekoliko grafikona. A bajtovi su označeni kao jedinica, tj. postoji 5 grafova. To su Umetanje podataka, Ažuriranje podataka, Brisanje podataka, Dohvaćanje podataka i Vraćanje podataka. Mjerna jedinica je bajt. Ali stvar je u tome što statistika u PostgreSQL-u vraća podatke u tuple (retcima). I, sukladno tome, ovi grafikoni su vrlo dobar način da podcijenite svoje radno opterećenje nekoliko puta, desetke puta, jer tuple nije bajt, tuple je niz, ima mnogo bajtova i uvijek je promjenjive duljine. Odnosno, izračunavanje radnog opterećenja u bajtovima pomoću torki je nerealan zadatak ili vrlo težak. Stoga, kada koristite nadzornu ploču ili ugrađeni nadzor, uvijek je važno razumjeti da radi ispravno i da vam vraća ispravno procijenjene podatke.
Kako doći do statistike na ovim tablicama? U tu svrhu PostgreSQL ima određenu obitelj pogleda. A glavni pogled je . User_tables - ovo znači tablice stvorene u ime korisnika. Nasuprot tome, postoje pogledi sustava koje koristi sam PostgreSQL. A tu je i tablica sažetka Alltables, koja uključuje i sistemske i korisničke. Možete početi od bilo kojeg od njih koji vam se najviše sviđa.
Pomoću gornjih polja možete procijeniti broj umetanja, ažuriranja i brisanja. Primjer nadzorne ploče koji sam koristio koristi ova polja za procjenu karakteristika radnog opterećenja. Stoga možemo i graditi na njima. Ali vrijedi zapamtiti da su to torke, a ne bajtovi, tako da ne možemo to učiniti samo u bajtovima.
Na temelju tih podataka možemo izgraditi tzv. TopN tablice. Na primjer, Top-5, Top-10. A možete pratiti one vruće stolove koji se recikliraju više od ostalih. Na primjer, 5 "vrućih" tablica za umetanje. Pomoću ovih TopN tablica procjenjujemo naše radno opterećenje i možemo procijeniti rafalno radno opterećenje nakon bilo kakvih izdanja, ažuriranja i implementacija.
Također je važno procijeniti veličinu tablice, jer ponekad programeri izbace novu značajku, a naše tablice počnu rasti u svojim velikim veličinama, jer su odlučili dodati dodatnu količinu podataka, ali nisu predvidjeli kako će to utjecati na veličinu baze podataka. Takvi slučajevi i nas iznenađuju.
A sada jedno malo pitanje za vas. Koje se pitanje postavlja kada primijetite opterećenje poslužitelja baze podataka? Koje je sljedeće pitanje koje imate?
Ali zapravo se postavlja pitanje kako slijedi. Koje zahtjeve uzrokuje opterećenje? Odnosno, nije zanimljivo gledati procese koji su uzrokovani opterećenjem. Jasno je da ako host ima bazu podataka, onda baza podataka radi tamo i jasno je da će tamo biti raspolagane samo bazama podataka. Ako otvorimo Top, tamo ćemo vidjeti popis procesa u PostgreSQL-u koji nešto rade. Iz Topa neće biti jasno što rade.
Sukladno tome, morate pronaći one upite koji uzrokuju najveće opterećenje, jer ugađanje upita u pravilu daje više profita od podešavanja PostgreSQL-a ili konfiguracije operacijskog sustava, pa čak i podešavanja hardvera. Po mojoj procjeni to je otprilike 80-85-90%. I to se radi mnogo brže. Brže je ispraviti zahtjev nego ispraviti konfiguraciju, zakazati ponovno pokretanje, osobito ako se baza podataka ne može ponovno pokrenuti, ili dodati hardver. Lakše je prepisati upit negdje ili dodati indeks kako biste dobili bolji rezultat iz ovog upita.
Sukladno tome, potrebno je pratiti zahtjeve i njihovu primjerenost. Uzmimo još jedan primjer praćenja. Čini se da i ovdje postoji odličan nadzor. Postoje informacije o replikaciji, postoje informacije o propusnosti, blokiranju, korištenju resursa. Sve je u redu, ali nema informacija o zahtjevima. Nije jasno koji se upiti pokreću u našoj bazi podataka, koliko dugo traju, koliko je tih upita. Ove informacije uvijek moramo imati u našem nadzoru.
A da bismo dobili ove informacije možemo koristiti modul pg_stat_statements. Na temelju toga možete graditi razne grafikone. Na primjer, možete dobiti informacije o najčešćim upitima, odnosno o onim upitima koji se najčešće izvršavaju. Da, nakon implementacija također je vrlo korisno pogledati to i razumjeti postoji li porast zahtjeva.
Možete pratiti najdulje upite, tj. one upite za koje je potrebno najdulje da se izvrše. Rade na procesoru, troše I/O. To također možemo procijeniti pomoću polja total_time, mean_time, blk_write_time i blk_read_time.
Možemo procijeniti i pratiti najteže zahtjeve u smislu korištenja resursa, one koji čitaju s diska, koji rade s memorijom ili, obrnuto, stvaraju neku vrstu opterećenja pisanja.
Možemo procijeniti najvelikodušnije zahtjeve. To su upiti koji vraćaju veliki broj redaka. Na primjer, to može biti neki zahtjev za koji su zaboravili postaviti ograničenje. I jednostavno vraća cijeli sadržaj tablice ili upita preko upitanih tablica.
Također možete nadzirati upite koji koriste privremene datoteke ili privremene tablice.
A još uvijek imamo pozadinske procese. Pozadinski procesi su prvenstveno kontrolne točke ili se još nazivaju i kontrolne točke, to su autovakuum i replikacija.
Još jedan primjer praćenja. Na lijevoj strani nalazi se kartica Održavanje, idite na nju i nadajte se da ćete vidjeti nešto korisno. Ali ovdje je samo vrijeme rada vakuuma i prikupljanje statistike, ništa više. To je vrlo loša informacija, stoga uvijek trebamo imati informaciju o tome kako rade pozadinski procesi u našoj bazi podataka i postoje li problemi u njihovom radu.
Kada gledamo kontrolne točke, trebali bismo imati na umu da kontrolne točke ispiru prljave stranice iz razdijeljenog memorijskog područja na disk, a zatim stvaraju kontrolnu točku. A ova se kontrolna točka može koristiti kao mjesto za oporavak ako je PostgreSQL iznenada prekinut u hitnom slučaju.
Sukladno tome, da biste isprali sve "prljave" stranice na disk, morate napraviti određenu količinu pisanja. I, u pravilu, na sustavima s velikom količinom memorije, to je puno. A ako kontrolne točke radimo vrlo često u kratkom intervalu, performanse diska će značajno pasti. A zahtjevi klijenata će patiti od nedostatka resursa. Natjecat će se za resurse i manjak produktivnosti.
Sukladno tome, kroz pg_stat_bgwriter pomoću navedenih polja možemo pratiti broj kontrolnih točaka koje se pojavljuju. A ako imamo puno kontrolnih točaka u određenom vremenskom razdoblju (u 10-15-20 minuta, u pola sata), npr. 3-4-5, onda to već može biti problem. I već morate pogledati u bazu podataka, pogledati u konfiguraciju, što uzrokuje takvo obilje kontrolnih točaka. Možda je u tijeku neko veliko snimanje. Već možemo procijeniti opterećenje jer smo već dodali grafikone opterećenja. Već možemo podesiti parametre kontrolnih točaka i osigurati da ne utječu uvelike na izvedbu upita.
Opet se vraćam na autovacuum jer je to takva stvar, kao što sam rekao, koja lako može zbrojiti performanse diska i upita, tako da je uvijek važno procijeniti količinu autovacuum-a.
Broj autovakumista u bazi je ograničen. Standardno ih je tri, pa ako uvijek imamo tri radnika koji rade u bazi, to znači da naš autovakuum nije konfiguriran, trebamo podići limite, revidirati postavke autovakuuma i ući u konfiguraciju.
Bitno je procijeniti koje usisivače imamo. Ili je pokrenut od strane korisnika, DBA je došao i ručno pokrenuo neku vrstu vakuuma, i to je stvorilo opterećenje. Imamo nekakav problem. Ili je ovo broj usisavača koji odvrću brojač transakcija. Za neke verzije PostgreSQL-a to su vrlo teški vakuumi. I lako mogu zbrojiti učinak jer čitaju cijelu tablicu, skeniraju sve blokove u toj tablici.
I, naravno, trajanje usisavanja. Ako imamo dugotrajne usisavače koji rade jako dugo, to znači da opet moramo obratiti pozornost na konfiguraciju usisavača i možda preispitati njegove postavke. Jer može doći do situacije da vakuum radi na stolu duže vrijeme (3-4 sata), ali za vrijeme rada vakuuma, velika količina mrtvih redova se ponovno uspjela nakupiti u stolu. I čim se usisavanje završi, mora ponovo usisati ovaj stol. I dolazimo u situaciju – beskrajni vakuum. I u ovom slučaju, vakuum se ne nosi sa svojim radom, a tablice se postupno počinju povećavati, iako količina korisnih podataka u njima ostaje ista. Stoga, tijekom dugih vakuuma, uvijek gledamo konfiguraciju i pokušavamo je optimizirati, ali u isto vrijeme tako da izvedba zahtjeva klijenata ne trpi.
Danas praktički ne postoji PostgreSQL instalacija koja nema replikaciju strujanja. Replikacija je proces premještanja podataka s mastera na repliku.
Replikacija u PostgreSQL-u se vrši kroz dnevnik transakcija. Čarobnjak generira dnevnik transakcija. Dnevnik transakcija putuje preko mrežne veze do replike, a zatim se reproducira na replici. Jednostavno je.
U skladu s tim, pogled pg_stat_replication koristi se za praćenje kašnjenja replikacije. Ali s njom nije sve jednostavno. U verziji 10, pogled je doživio nekoliko promjena. Prvo, neka polja su preimenovana. Dodana su i neka polja. U verziji 10 pojavila su se polja koja vam omogućuju procjenu kašnjenja replikacije u sekundama. Vrlo je udoban. Prije verzije 10 bilo je moguće procijeniti kašnjenje replikacije u bajtovima. Ova opcija ostaje u verziji 10, tj. možete odabrati što vam više odgovara - procijeniti kašnjenje u bajtovima ili procijeniti kašnjenje u sekundama. Mnogi ljudi rade oboje.
No unatoč tome, kako biste procijenili kašnjenje replikacije, morate znati položaj dnevnika u transakciji. I ove pozicije dnevnika transakcija su točno u prikazu pg_stat_replication. Relativno govoreći, pomoću funkcije pg_xlog_location_diff() možemo uzeti dvije točke u dnevniku transakcija. Izračunajte delta između njih i dobijte kašnjenje replikacije u bajtovima. Vrlo je zgodan i jednostavan.
U verziji 10 ova je funkcija preimenovana u pg_wal_lsn_diff(). Općenito, u svim funkcijama, prikazima i uslužnim programima gdje se pojavila riječ "xlog", zamijenjena je vrijednošću "wal". Ovo se odnosi i na prikaze i na funkcije. Ovo je takva inovacija.
Osim toga, u verziji 10 dodani su redovi koji posebno pokazuju kašnjenje. To su kašnjenje pisanja, kašnjenje ispiranja, kašnjenje reprodukcije. Odnosno, važno je pratiti te stvari. Ako vidimo da imamo kašnjenje replikacije, onda moramo istražiti zašto se to pojavilo, odakle je došlo i riješiti problem.
Gotovo je sve u redu s metrikom sustava. Kada bilo kakvo praćenje započne, počinje s metrikom sustava. Ovo je raspolaganje procesorima, memorijom, swapom, mrežom i diskom. Međutim, mnogi parametri nisu tamo prema zadanim postavkama.
Ako je sve u redu s procesom recikliranja, onda postoje problemi s recikliranjem diska. U pravilu, programeri praćenja dodaju informacije o propusnosti. Može biti u iopima ili bajtovima. Ali zaboravljaju na kašnjenje i iskorištenost diskovnih uređaja. Ovo su važniji parametri koji nam omogućuju da procijenimo koliko su naši diskovi opterećeni i koliko su spori. Ako imamo veliku latenciju, onda to znači da postoje problemi s diskovima. Ako imamo visoku iskorištenost, to znači da se diskovi ne snalaze. To su bolje karakteristike od propusnosti.
Štoviše, ove se statistike također mogu dobiti iz datotečnog sustava /proc, kao što je to učinjeno za procesore za recikliranje. Ne znam zašto se ove informacije ne dodaju u praćenje. Ipak, važno je to imati u svom nadzoru.
Isto vrijedi i za mrežna sučelja. Ima informacija o mrežnoj propusnosti u paketima, u bajtovima, ali unatoč tome nema informacija o latenciji i nema informacija o korištenju, iako je i to korisna informacija.
Svako praćenje ima nedostatke. I bez obzira na to kakav monitoring poduzeli, on uvijek neće zadovoljiti neke kriterije. Ali unatoč tome, oni se razvijaju, dodaju se nove značajke i nove stvari, pa odaberite nešto i dovršite to.
I da biste završili, uvijek morate imati ideju o tome što znače navedene statistike i kako ih možete koristiti za rješavanje problema.
I nekoliko ključnih točaka:
- Uvijek trebate pratiti dostupnost i imati nadzorne ploče kako biste mogli brzo procijeniti je li sve u redu s bazom podataka.
- Uvijek morate imati ideju o tome koji klijenti rade s vašom bazom podataka kako biste eliminirali loše klijente i uništili ih.
- Važno je procijeniti kako ti klijenti rade s podacima. Morate imati ideju o svom radnom opterećenju.
- Važno je procijeniti kako se to radno opterećenje formira, uz pomoć kojih upita. Možete procijeniti upite, možete ih optimizirati, refaktorirati, izgraditi indekse za njih. Vrlo je važno.
- Pozadinski procesi mogu negativno utjecati na zahtjeve klijenata, stoga je važno pratiti da ne koriste previše resursa.
- Sustavne metrike omogućuju vam izradu planova za skaliranje i povećanje kapaciteta vaših poslužitelja, stoga je važno pratiti i procijeniti i njih.
Ako vas zanima ova tema, možete slijediti ove poveznice.
- ovo je službena dokumentacija skupljača statistike. Postoji opis svih statističkih prikaza i opis svih polja. Možete ih čitati, razumjeti i analizirati. I na temelju njih izgradite svoje grafikone i dodajte ih svom praćenju.
Primjer zahtjeva:
Ovo je naše korporativno skladište i moje vlastito. Sadrže primjere upita. Tamo nema upita iz serije select* from. Već postoje gotovi upiti sa spojevima, koristeći zanimljive funkcije koje vam omogućuju pretvaranje sirovih brojeva u čitljive, prikladne vrijednosti, tj. to su bajtovi, vrijeme. Možete ih pokupiti, pogledati, analizirati, dodati svom praćenju, izgraditi svoje praćenje na temelju njih.
pitanja
Pitanje: Rekli ste da nećete reklamirati brendove, ali ipak me zanima - kakve nadzorne ploče koristite u svojim projektima?
Odgovor: Razlikuje se. Dogodi se da dođemo kod kupca, a on već ima svoj monitoring. I savjetujemo kupca o tome što treba dodati njihovom praćenju. Najgora situacija je sa Zabbixom. Zato što nema mogućnost izgradnje TopN grafova. Mi sami koristimo , jer smo se konzultirali s tim momcima o praćenju. Pratili su PostgreSQL na temelju naših tehničkih specifikacija. Pišem vlastiti projekt ljubimaca koji prikuplja podatke putem Prometheusa i prikazuje ih u . Moj zadatak je napraviti vlastiti exporter u Prometeju i onda sve renderirati u Grafani.
Pitanje: Postoje li analozi AWR izvješća ili... agregacije? Znate li za ovako nešto?
Odgovor: Da, znam što je AWR, to je cool stvar. Trenutno postoji niz bicikala koji provode otprilike sljedeći model. U nekom vremenskom intervalu, neke osnovne linije se zapisuju u isti PostgreSQL ili u zasebnu pohranu. Možete ih guglati na internetu, tamo su. Jedan od programera takve stvari sjedi na forumu sql.ru u temi PostgreSQL. Možete ga tamo uhvatiti. Da, postoje takve stvari, mogu se koristiti. Plus u svom Također pišem nešto što vam omogućuje da učinite istu stvar.
PS1 Ako koristite postgres_exporter, koju nadzornu ploču koristite? Ima ih nekoliko. Već su zastarjeli. Možda će zajednica izraditi ažurirani predložak?
PS2 Uklonio pganalyze jer je to vlasnička SaaS ponuda koja se fokusira na praćenje performansi i automatske prijedloge za podešavanje.
U anketi mogu sudjelovati samo registrirani korisnici. , molim.
Koji postgresql nadzor s vlastitim hostingom (s nadzornom pločom) smatrate najboljim?
-
30,0%Zabbix + dodaci Alexeya Lesovskog ili zabbix 4.4 ili 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 vlasnički SaaS - ne mogu 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 korisnika. Suzdržano je bilo 26 korisnika.
Izvor: www.habr.com