Osnove postgreSQL praćenja. Alexey Lesovsky

Predlažem da pročitate transkript izvještaja Alexey Lesovsky iz Data Egret "Osnove PostgreSQL monitoringa"

U ovom izveštaju, Aleksej Lesovski će govoriti o ključnim tačkama postgres statistike, šta one znače i zašto ih treba uključiti u monitoring; o tome šta grafikoni treba da budu u praćenju, kako ih dodati i kako interpretirati. Izvještaj će biti koristan za administratore baza podataka, sistem administratore i programere koji su zainteresirani za rješavanje problema s Postgresom.

Moje ime je Alexey Lesovsky, predstavljam Data Egret.

Par riječi o sebi. Počeo sam davno kao sistem administrator.

Administrirao sam razne vrste Linuxa, radio razne stvari vezane za Linux, tj. virtualizaciju, nadgledanje, radio sa proksijima, itd. Ali u nekom trenutku sam se više uključio u baze podataka, PostgreSQL. Zaista mi se dopao. I u nekom trenutku sam počeo da se bavim PostgreSQL-om većinu svog radnog vremena. I tako sam postepeno postao PostgreSQL DBA.

I kroz svoju karijeru oduvijek su me zanimale teme statistike, monitoringa, telemetrije. A kada sam bio sistem administrator, jako sam radio na Zabbixu. I napisao mali set scenarija kao što je zabbix-extensions. Bio je prilično popularan u svoje vrijeme. I tamo je bilo moguće pratiti vrlo različite važne stvari, ne samo Linux, već i razne komponente.

Sada već radim PostgreSQL. Već pišem još jednu stvar koja vam omogućava da radite sa PostgreSQL statistikom. To se zove pgCenter (članak na Habré-u - Postgres stat bez živaca i napetosti).

Mali uvod. Kakve su situacije sa našim kupcima, sa našim klijentima? Postoji neka vrsta nezgode povezana sa bazom podataka. A kada je baza podataka već restaurirana, dolazi šef odjeljenja ili šef razvoja i kaže: “Prijatelji, treba da pratimo bazu podataka, jer se nešto loše dogodilo i potrebno je da se to ne dešava u budućnosti.” I tu počinje zanimljiv proces odabira nadzornog sistema ili prilagođavanja postojećeg nadzornog sistema tako da možete pratiti svoju bazu podataka - PostgreSQL, MySQL ili neke druge. I kolege počinju da nude: „Čuo sam da postoji takva i takva baza podataka. Hajde da ga iskoristimo." Kolege počinju da se svađaju. I na kraju se ispostavi da biramo neku vrstu baze podataka, ali je PostgreSQL praćenje u njoj prilično slabo zastupljeno i uvijek moramo nešto dovršiti. Uzmite neka spremišta sa GitHuba, klonirajte ih, prilagodite skripte, nekako ih podesite. I na kraju ispadne u neku vrstu ručnog rada.

Stoga ću vam u ovom izvještaju pokušati dati neka znanja o tome kako odabrati praćenje ne samo za PostgreSQL, već i za bazu podataka. I da date znanje koje će vam omogućiti da završite svoje praćenje kako biste izvukli neku korist od toga, tako da možete s koristima pratiti svoju bazu podataka kako biste spriječili bilo kakve nadolazeće vanredne situacije koje se mogu pojaviti na vrijeme.

A te ideje koje će biti u ovom izvještaju, mogu se direktno prilagoditi bilo kojoj bazi podataka, bilo da je to DBMS ili noSQL. Stoga, ne samo PostgreSQL ovdje, već će biti mnogo recepata kako to učiniti u PostgreSQL-u. Biće tu primeri upita, primeri entiteta koje PostgreSQL ima za praćenje. A ako vaš DBMS ima iste stvari koje vam omogućavaju da ih stavite u nadzor, možete ih prilagoditi, dodati i sve će biti u redu.

Neću prijaviti
razgovarajte o tome kako isporučiti i pohraniti metriku. Neću reći ništa o naknadnoj obradi podataka i pružanju istih korisniku. A o uzbunjivanju neću ništa reći.
Ali u toku priče pokazaću različite screenshotove postojećih monitoringa, nekako ću ih kritikovati. Ipak, pokušat ću ne imenovati brendove kako ne bih stvarao reklamiranje ili anti-reklamu za ove proizvode. Stoga su sve slučajnosti slučajne i ostaju na vašoj mašti.

Prvo, hajde da shvatimo šta je nadzor. Monitoring je veoma važna stvar koju treba imati. Svi to razumiju. Ali istovremeno, praćenje nije povezano sa poslovnim proizvodom i ne utiče direktno na profit kompanije, tako da se monitoringu uvek daje vreme na rezidualnoj osnovi. Ako imamo vremena, onda se bavimo praćenjem, ako nema vremena, onda ćemo to staviti u zaostatak i jednog dana ćemo se vratiti ovim zadacima.

Dakle, iz naše prakse, kada dođemo do klijenata, monitoring je često nedovoljno razvijen i nema zanimljivosti koje bi nam pomogle da bolje radimo sa bazom podataka. Stoga praćenje uvijek treba završiti.

Baze podataka su tako složene stvari koje također morate pratiti, jer baze podataka su spremište informacija. A informacije su veoma važne za kompaniju, ne mogu se izgubiti ni na koji način. Ali u isto vrijeme, baze podataka su vrlo složeni komadi softvera. Sastoje se od mnogih komponenti. I mnoge od ovih komponenti treba pratiti.

Ako govorimo konkretno o PostgreSQL-u, onda se može predstaviti kao takva šema, koja se sastoji od velikog broja komponenti. Ove komponente međusobno djeluju. Istovremeno, PostgreSQL ima takozvani podsistem Stats Collector, koji vam omogućava da prikupljate statistiku o radu ovih podsistema i dajete interfejs administratoru ili korisniku kako bi on mogao da vidi ove statistike.

Ova statistika je predstavljena u obliku nekog skupa funkcija i pogleda (pregled). Mogu se nazvati i stolovima. To jest, pomoću običnog psql klijenta, možete se povezati na bazu podataka, odabrati ove funkcije i poglede i dobiti neke specifične brojeve o radu PostgreSQL podsistema.

Možete dodati ove brojeve svom omiljenom sistemu za praćenje, nacrtati grafikone, dodati funkcije i dobiti analitiku na duge staze.

Ali u ovom izvještaju neću pokriti sve ove funkcije bez izuzetka, jer to može potrajati cijeli dan. Ja ću se osvrnuti na doslovno dvije, tri ili četiri stvari i reći ću vam kako one pomažu da praćenje bude bolje.

A ako govorimo o praćenju baze podataka, šta onda treba pratiti? Prije svega, potrebno je pratiti dostupnost, jer je baza podataka servis koji klijentima omogućava pristup podacima i potrebno je da pratimo dostupnost, ali i da pružimo neke od njenih kvalitativnih i kvantitativnih karakteristika.

Također moramo pratiti klijente koji se povezuju na našu bazu podataka, jer oni mogu biti i normalni klijenti i štetni klijenti koji mogu oštetiti bazu podataka. Takođe ih treba pratiti i pratiti.

Kada se klijenti povežu na bazu podataka, očito je da počinju raditi s našim podacima, pa moramo pratiti kako klijenti rade s podacima: s kojim tabelama, u manjoj mjeri s kojim indeksima. Odnosno, moramo procijeniti opterećenje koje stvaraju naši klijenti.

Ali opterećenje se, naravno, sastoji i od zahtjeva. Aplikacije se povezuju na bazu, pristupaju podacima pomoću upita, pa je važno procijeniti koje upite imamo u bazi, pratiti njihovu adekvatnost, da nisu krive, da neke opcije treba prepisati i napraviti tako da rade brže i sa boljim performansama.

A pošto govorimo o bazi podataka, baza podataka je uvijek pozadinski proces. Pozadinski procesi održavaju performanse baze podataka na dobrom nivou, tako da zahtijevaju određenu količinu resursa za sebe da bi pokrenuli. A u isto vrijeme, mogu se preklapati sa resursima zahtjeva klijenta, tako da pohlepni rad pozadinskih procesa može direktno utjecati na performanse zahtjeva klijenta. Stoga ih također treba pratiti i pratiti kako ne bi došlo do izobličenja u pogledu pozadinskih procesa.

I to je sve u smislu da praćenje baze podataka ostaje u sistemskoj metrici. Ali s obzirom da najvećim dijelom čitava naša infrastruktura ide u oblake, sistemske metrike pojedinačnog hosta uvijek blede u pozadinu. Ali u bazama podataka oni su i dalje relevantni i, naravno, potrebno je pratiti i sistemske metrike.

Sa sistemskom metrikom sve je manje-više u redu, svi moderni sistemi za praćenje već podržavaju ove metrike, ali generalno, neke komponente još uvijek nisu dovoljne i neke stvari treba dodati. Dotaknuću se i njih, nekoliko slajdova će biti o njima.

Prva tačka plana je pristupačnost. Šta je pristupačnost? Dostupnost po mom shvatanju je sposobnost baze da opslužuje veze, odnosno baza se podiže, ona kao servis prihvata veze od klijenata. A ova pristupačnost se može ocijeniti po nekim karakteristikama. Ove karakteristike su vrlo zgodne za prikaz na kontrolnoj tabli.

Svi znaju šta su kontrolne table. Tada ste bacili jedan pogled na ekran, koji je rezimirao potrebne informacije. I već možete odmah utvrditi postoji li problem u bazi podataka ili ne.
U skladu s tim, dostupnost baze podataka i druge ključne karakteristike uvijek treba staviti na nadzorne ploče kako bi ove informacije bile pri ruci, uvijek s vama. Neki dodatni detalji koji već pomažu u istrazi incidenata, u istrazi nekih vanrednih situacija, već ih je potrebno postaviti na sekundarne kontrolne table, ili sakriti u drilldown linkovima koji vode do sistema za praćenje treće strane.

Primjer jednog poznatog sistema za praćenje. Ovo je veoma kul sistem za praćenje. Prikuplja mnogo podataka, ali s moje tačke gledišta, ima čudan koncept nadzornih ploča. Postoji veza "Kreiraj kontrolnu tablu". Ali kada kreirate kontrolnu tablu, kreirate listu sa dve kolone, listu grafikona. A kada treba nešto da pogledate, počinjete da klikćete, skrolujete, mišem tražite željeni grafikon. A za to je potrebno vrijeme, tj. ne postoje kontrolne table kao takve. Postoje samo liste grafikona.

Šta treba dodati na ove kontrolne table? Možete početi s takvom karakteristikom kao što je vrijeme odziva. PostgreSQL ima pg_stat_statements pogled. Podrazumevano je onemogućen, ali je jedan od važnih sistemskih pogleda koji uvijek treba omogućiti i koristiti. Pohranjuje informacije o svim pokrenutim upitima koji su izvršeni u bazi podataka.

Shodno tome, možemo poći od činjenice da možemo uzeti ukupno vrijeme izvršenja svih zahtjeva i podijeliti sa brojem zahtjeva koristeći gornja polja. Ali ovo je tako prosječna temperatura u bolnici. Možemo graditi na drugim poljima - minimalno vrijeme izvršenja upita, maksimalno i medijana. Možemo čak i da pravimo 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 'odaberi 1' zahtjev i gledamo vrijeme odgovora, već analiziramo vrijeme odgovora za već završene zahtjeve i izvlačimo bilo zasebna figura, ili na osnovu nje gradimo grafikon.

Takođe je važno pratiti broj grešaka koje sistem trenutno generiše. A za ovo možete koristiti pg_stat_database pogled. Ciljamo polje xact_rollback. Ovo polje ne samo da prikazuje broj poništavanja koji se dešavaju u bazi podataka, već uzima u obzir i broj grešaka. Relativno govoreći, ovu cifru možemo prikazati na našoj kontrolnoj tabli i vidjeti koliko grešaka imamo u ovom trenutku. Ako ima puno grešaka, onda je to već dobar razlog da pogledate u logove i vidite kakve su to greške i zašto nastaju, a zatim ih uložite i riješite.

Možete dodati takvu stvar kao što je tahometar. To su broj transakcija u sekundi i broj zahtjeva u sekundi. Relativno govoreći, možete koristiti ove brojeve kao trenutne performanse vaše baze podataka i promatrati da li postoje vrhovi u zahtjevima, vrhunci u transakcijama, ili, obrnuto, baza podataka je nedovoljno učitana jer je neka vrsta backenda otpala. Važno je uvijek gledati ovu cifru i zapamtiti da je za naš projekat takva izvedba normalna, a vrijednosti ​​​​iznad su već neke problematične i nerazumljive, što znači da trebamo pogledati zašto su takvi brojevi .

Da bismo procijenili broj transakcija, ponovo se možemo obratiti na pg_stat_database prikaz. Možemo dodati broj urezivanja i broj vraćanja da bismo dobili broj transakcija u sekundi.

Svi razumiju 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 zbir svih izvršenih zahtjeva. Jasno je da uporedimo trenutnu vrijednost sa prethodnom, oduzmemo, dobijemo deltu, dobijemo iznos.

Ako želite, možete dodati dodatne metrike, koje također pomažu u procjeni dostupnosti naše baze podataka i praćenju da li je bilo zastoja.

Jedna od ovih metrika je vrijeme rada. Ali produženje rada u PostgreSQL-u je malo nezgodno. Reći ću ti zašto. Kada se PostgreSQL pokrene, on počinje da izveštava o vremenu neprekidnog rada. Ali ako je u nekom trenutku, na primjer, neki zadatak bio pokrenut noću, došao je OOM-ubica i prisilno prekinuo PostgreSQL podređeni proces, tada u ovom slučaju PostgreSQL prekida vezu svih klijenata, resetuje područje podijeljene memorije i započinje oporavak od poslednja kontrolna tačka. I dok traje ovaj oporavak sa kontrolne tačke, baza podataka ne prihvata veze, odnosno ova situacija se može oceniti kao prekid rada. Ali ovo neće resetirati brojač radnog vremena, jer uzima u obzir vrijeme pokretanja postmastera od prvog trenutka. Stoga se takve situacije mogu preskočiti.

Također treba pratiti broj radnika usisivača. Svi znaju šta je autovacuum u PostgreSQL-u? Ovo je zanimljiv podsistem u PostgreSQL-u. O tome je napisano mnogo članaka, mnogo izvještaja. Mnogo diskusija o vakuumu, kako bi trebao funkcionirati. Mnogi to smatraju neophodnim zlom. Ali to je. Ovo je neka vrsta sakupljača smeća koji čisti zastarjele verzije redova koje nisu potrebne nijednoj transakciji i oslobađa prostor u tabelama i indeksima za nove redove.

Zašto ga treba pratiti? Jer vakuum ponekad jako boli. To troši veliku količinu resursa i zahtjevi klijenata počinju da trpe zbog toga.

I to bi trebalo pratiti kroz pg_stat_activity pogled, o čemu ću govoriti u sljedećem odjeljku. Ovaj prikaz prikazuje trenutnu aktivnost u bazi podataka. I kroz ovu aktivnost možemo pratiti broj usisivača koji trenutno rade. Možemo pratiti vakuume i vidjeti da ako smo prekoračili granicu, onda je ovo prilika da pogledamo postavke PostgreSQL-a i nekako optimiziramo rad usisivača.

Još jedna karakteristika PostgreSQL-a je da je PostgreSQL-u veoma muka od dugih transakcija. Pogotovo od transakcija koje dugo stoje i ne rade ništa. To su takozvane stat idle-in-transaction. Takva transakcija zadržava brave, sprečava rad vakuuma. I kao rezultat - stolovi nabubre, povećavaju se u veličini. A upiti koji rade sa ovim tabelama, počinju da rade sporije, jer morate da izbacite sve stare verzije redova iz memorije na disk i nazad. Stoga je potrebno pratiti i vrijeme, trajanje najdužih transakcija, najduže zahtjeve za vakuum. A ako vidimo neke procese koji rade jako dugo, duže od 10-20-30 minuta za OLTP opterećenje, onda trebamo obratiti pažnju na njih i prisiliti ih da završe, ili optimizirati aplikaciju tako da ne zovu se i ne vise tako dugo. Za analitičko opterećenje je normalno 10-20-30 minuta, ima i dužih.

Zatim imamo opciju sa povezanim klijentima. Kada smo već formirali kontrolnu tablu, postavili ključne metrike pristupačnosti na nju, možemo tamo dodati i dodatne informacije o povezanim klijentima.

Informacije o povezanim klijentima su važne jer, sa stanovišta PostgreSQL-a, postoje različite vrste klijenata. Ima dobrih i loših klijenata.

Jednostavan primjer. Pod klijentom mislim na aplikaciju. Aplikacija se spojila na bazu podataka i odmah počinje slati svoje zahtjeve tamo, baza ih obrađuje i izvršava, te vraća rezultate klijentu. To su dobri i pravi klijenti.

Postoje situacije da je klijent povezan, održava vezu, ali ne radi ništa. Nalazi se u stanju mirovanja.

Ali ima loših klijenata. Na primjer, isti klijent se povezao, otvorio transakciju, uradio nešto u bazi podataka, a zatim ušao u kod, na primjer, da pristupi eksternom izvoru ili da tamo obradi primljene podatke. Ali u isto vrijeme nije zaključio transakciju. A transakcija visi u bazi podataka i drži bravu na liniji. Ovo je loše stanje. A ako iznenada aplikacija negdje unutar nje padne zbog izuzetka (Exception), onda transakcija može ostati otvorena jako dugo. A to direktno utiče na performanse PostgreSQL-a. PostgreSQL će raditi sporije. Stoga je važno takve klijente na vrijeme pratiti i prinudno prekinuti njihov rad. I trebate optimizirati svoju aplikaciju kako ne bi bilo takvih situacija.

Drugi loši klijenti su klijenti koji čekaju. Ali zbog okolnosti postaju loši. Na primjer, jednostavna transakcija u stanju mirovanja: može otvoriti transakciju, uzeti brave na nekim linijama, a zatim će pasti negdje u kodu, ostavljajući transakciju koja visi. Doći će drugi klijent, zatražiti iste podatke, ali će naići na zaključavanje, jer ta viseća transakcija već drži brave na nekim potrebnim redovima. A druga transakcija će visjeti u iščekivanju kada se prva transakcija završi ili je njen administrator nasilno zatvori. Dakle, transakcije na čekanju mogu akumulirati i prekoračiti ograničenje veze s bazom podataka. A kada je ograničenje puno, aplikacija više ne može raditi s bazom podataka. Ovo je već hitna situacija za projekat. Stoga, loše kupce treba pratiti i na vrijeme reagirati.

Još jedan primjer praćenja. A evo i pristojne kontrolne table. Postoje informacije o vezama odozgo. DB priključak - 8 komada. I to je sve. Nemamo informacije o tome koji su klijenti aktivni, koji klijenti samo ne rade, ne rade ništa. Nema informacija o visećim transakcijama i vezama na čekanju, odnosno ovo je takva brojka koja pokazuje broj veza i to je to. A onda pogodite sami.

Shodno tome, da biste dodali ove informacije nadzoru, trebate se obratiti na sistemski prikaz pg_stat_activity. Ako provodite dosta vremena u PostgreSQL-u, onda je ovo jako dobar pogled koji bi vam trebao postati prijatelj, jer prikazuje trenutnu aktivnost u PostgreSQL-u, odnosno šta se u njemu dešava. Za svaki proces postoji posebna linija koja prikazuje informacije o ovom procesu: sa kojeg hosta je uspostavljena veza, pod kojim korisnikom, pod kojim imenom, kada je transakcija pokrenuta, koji zahtjev se trenutno izvršava, koji zahtjev je zadnji izvršen. I, shodno tome, možemo procijeniti stanje klijenta pomoću polja stat. Relativno govoreći, možemo grupirati po ovom polju i dobiti one statistike koje su sada u bazi podataka i broj veza koje su sa ovom statistikom u bazi. A već primljene brojeve možemo poslati na naš monitoring i nacrtati grafikone na njima.
Također je važno procijeniti trajanje transakcije. Već sam rekao da je važno procijeniti trajanje vakuuma, ali se i transakcije procjenjuju na isti način. 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 vremenske oznake transakcije i zahtjeva. I dobijamo trajanje transakcije, trajanje zahteva.

Ako vidimo duge transakcije, trebali bismo ih već završiti. Za OLTP opterećenje, duge transakcije već traju više od 1-2-3 minute. Za OLAP opterećenje, duge transakcije su normalne, ali ako traju duže od dva sata, to je također znak da imamo negdje iskrivljenje.

Nakon što se klijenti povežu na bazu podataka, počinju raditi s našim podacima. Oni pristupaju tabelama, pristupaju indeksima da bi dobili podatke iz tabele. I važno je procijeniti kako kupci rade s ovim podacima.

Ovo je neophodno kako bismo procijenili naše opterećenje i otprilike razumjeli koje stolove imamo „najtoplije“. Na primjer, ovo je neophodno u situacijama kada želimo postaviti „vruće“ stolove na neku vrstu brzog SSD memorije. Na primjer, neke arhivske tabele koje nismo dugo koristili možemo prenijeti u neku vrstu “hladne” arhive, na SATA diskove i ostaviti ih tamo da žive, pristupaće im se po potrebi.

Također je koristan za otkrivanje anomalija nakon bilo kojeg izdanja i implementacije. Recimo da je projekat uveo neku novu funkciju. Na primjer, dodali smo novu funkcionalnost za rad sa bazom podataka. A ako napravimo grafikone za korištenje tabela, lako možemo otkriti ove anomalije na tim grafovima. Na primjer, ažurirajte nizove ili izbrišite nizove. To će biti vrlo vidljivo.

Također je moguće otkriti anomalije "plutajuće" statistike. Šta to znači? PostgreSQL ima veoma jak i veoma dobar planer upita. A programeri posvećuju dosta vremena njegovom razvoju. Kako on radi? Da bi napravio dobre planove, PostgreSQL prikuplja statistiku o distribuciji podataka u tabelama sa određenim vremenskim intervalom, sa određenom periodičnošću. Ovo su najčešće vrijednosti: broj jedinstvenih vrijednosti, informacije o NULL u tabeli, puno informacija.

Na osnovu ove statistike, planer gradi nekoliko upita, bira najoptimalniji i koristi ovaj plan upita da izvrši sam upit i vrati podatke.

I dešava se da statistika “pluta”. Podaci o kvaliteti i kvantitetu su se nekako promijenili u tabeli, ali statistika nije prikupljena. A napravljeni planovi možda neće biti optimalni. A ako se naši planovi pokažu neoptimalnim u smislu prikupljanja monitoringa, prema tabelama, moći ćemo vidjeti ove anomalije. Na primjer, negdje su se podaci kvalitativno promijenili i umjesto indeksa počeo se koristiti sekvencijalni prolaz kroz tabelu, tj. ako upit treba da vrati samo 100 redova (postoji ograničenje od 100), tada će se za ovaj upit izvršiti potpuno nabrajanje. A to uvijek ima jako loš učinak na performanse.

I to možemo vidjeti u monitoringu. I već pogledajte ovaj upit, izvršite objašnjenje za njega, prikupite statistiku, napravite novi dodatni indeks. I već odgovorite na ovaj problem. Stoga je važno.

Još jedan primjer praćenja. Mislim da ga mnogi prepoznaju jer je veoma popularan. Ko koristi u svojim projektima Prometej? A tko koristi ovaj proizvod u sprezi s Prometheusom? Činjenica je da u standardnom repozitoriju ovog nadzora postoji kontrolna tabla za rad sa PostgreSQL - postgres_exporter Prometej. Ali ovdje postoji jedan loš detalj.

Postoji nekoliko grafikona. A bajtovi su specificirani kao jedinica, tj. ima 5 grafova. To su Ubaci podatke, Ažuriraj podatke, Izbriši podatke, Dohvati podatke i Vrati podatke. Bajtovi su specificirani kao dimenzija jedinice. Ali činjenica je da statistika u PostgreSQL-u vraća podatke u tuple (redove). I, shodno tome, ovi grafovi su jako dobar način da podcijenite svoje opterećenje nekoliko puta, desetine puta, jer torka nije bajt, torka je niz, ima puno bajtova i uvijek je promjenjive dužine. Odnosno, izračunavanje radnog opterećenja u bajtovima pomoću tuple-a je nerealan ili vrlo težak zadatak. Stoga, kada koristite kontrolnu tablu ili ugrađeni nadzor, uvijek je važno razumjeti da ispravno radi i da vam vraća ispravno procijenjene podatke.

Kako doći do statistike na ovim tabelama? Da biste to učinili, PostgreSQL ima porodicu pogleda. A glavni pogled je pg_stat_user_tables. Korisničke_tabele - to znači da se tabele kreiraju u ime korisnika. Nasuprot tome, postoje sistemski pogledi koje koristi sam PostgreSQL. I postoji sažeta tabela Alltables, koja uključuje i sistem i korisnika. Možete početi od bilo kojeg od njih koji vam se najviše sviđa.

Gornja polja se mogu koristiti za procjenu broja umetanja, ažuriranja i brisanja. Primjer kontrolne 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 tuple, a ne bajtovi, tako da ih ne možemo uzeti i napraviti bajtovima.

Na osnovu ovih podataka možemo napraviti takozvane TopN-tabele. Na primjer, Top-5, Top-10. I možete pratiti one vruće stolove koji se koriste više od drugih. Na primjer, 5 "vrućih" tablica za umetanje. A prema ovim TopN-tabelama, mi procjenjujemo naše radno opterećenje i možemo procijeniti navale opterećenja nakon bilo kakvog izdanja i ažuriranja i implementacije.

Također je važno procijeniti veličinu tabele, jer ponekad programeri uvedu novu funkciju, a naše tabele počinju da se povećavaju u svojim velikim veličinama, jer su odlučili da dodaju dodatnu količinu podataka, ali nisu predvideli kako će to biti utiču na veličinu baze podataka. Takvi slučajevi su i za nas iznenađenje.

A sada malo pitanje za vas. Koje je pitanje kada primijetite opterećenje na serveru baze podataka? Koje je tvoje sljedeće pitanje?

Ali pravo pitanje je sljedeće. Koje zahtjeve uzrokuje opterećenje? Odnosno, nije zanimljivo gledati procese koje opterećenje uzrokuje. Jasno je da ako je host sa bazom podataka, onda je baza podataka tamo pokrenuta i jasno je da će se tamo odlagati samo baze podataka. Ako otvorimo Top, tamo ćemo vidjeti listu PostgreSQL procesa koji nešto rade. Sa vrha neće biti jasno šta rade.

U skladu s tim, morate pronaći one upite koji izazivaju najveće opterećenje, jer podešavanje upita, po pravilu, donosi više profita od postgreSQL konfiguracije ili podešavanja operativnog sistema, ili čak podešavanja hardvera. Po mojoj proceni, to je oko 80-85-90%. I to se radi mnogo brže. Brže je ispraviti zahtjev nego ispraviti konfiguraciju, zakazati ponovno pokretanje, posebno ako se baza podataka ne može ponovo pokrenuti, ili dodati hardver. Lakše je prepisati upit negdje ili dodati indeks da biste dobili bolji rezultat iz ovog upita.

Shodno tome, potrebno je pratiti zahtjeve i njihovu adekvatnost. Uzmimo još jedan primjer praćenja. I ovdje se također čini da je nadzor odličan. 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 se izvode, koliko ovih upita. Ove informacije moramo uvijek imati u nadzoru.

A da bismo dobili ove informacije, možemo koristiti modul pg_stat_statements. Na osnovu njega možete napraviti različite grafike. Na primjer, možete dobiti informacije o najčešćim zahtjevima, odnosno o onim zahtjevima koji se najčešće izvršavaju. Da, nakon implementacije također je vrlo korisno pogledati ga i razumjeti postoji li porast zahtjeva.

Možete pratiti najduže zahtjeve, odnosno one zahtjeve za koje je potrebno najduže da se završe. Oni rade na procesoru, troše I/O. Ovo 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, one koji rade s memorijom, ili, naprotiv, stvoriti neku vrstu opterećenja pisanja.

Možemo procijeniti najizdašnije zahtjeve. Ovo su upiti koji vraćaju veliki broj redova. Na primjer, to može biti neka vrsta zahtjeva gdje su zaboravili postaviti ograničenje. I samo vraća cijeli sadržaj tabele ili upita na traženim tabelama.

Takođe možete pratiti upite koji koriste privremene datoteke ili privremene tabele.

I još uvijek imamo pozadinske procese. Pozadinski procesi su prvenstveno kontrolne tačke ili se još zovu i kontrolne tačke, to su autovakuum i replikacija.

Još jedan primjer praćenja. Na lijevoj strani je kartica Održavanje, idite na nju i nadajte se da ćete vidjeti nešto korisno. Ali ovdje je samo vrijeme vakuuma i prikupljanja statistike, ništa drugo. Ovo je jako loša informacija, tako da uvijek morate imati informaciju o tome kako funkcionišu pozadinski procesi u našoj bazi podataka i da li ima problema u njihovom radu.

Kada gledamo kontrolne tačke, treba imati na umu da naše kontrolne tačke ispuštaju "prljave" stranice iz područja podijeljene memorije na disk, a zatim kreiraju kontrolnu tačku. I ova kontrolna tačka se već može koristiti kao mjesto tokom oporavka, ako je PostgreSQL iznenada prekinut u hitnom slučaju.

U skladu s tim, da biste izbacili sve "prljave" stranice na disk, morate napraviti određenu količinu pisanja. I, u pravilu, na sistemima s velikom količinom memorije, ovo je mnogo. A ako kontrolne tačke pravimo vrlo često u nekom kratkom intervalu, onda će performanse diska jako oslabiti. A zahtjevi klijenata će patiti zbog nedostatka resursa. Oni će se takmičiti za resurse i nedostajaće im produktivnost.

Shodno tome, preko pg_stat_bgwriter na navedenim poljima, možemo pratiti broj kontrolnih tačaka koje se javljaju. A ako imamo puno kontrolnih tačaka na određeno vrijeme (10-15-20 minuta, pola sata), na primjer, 3-4-5, onda to već može biti problem. I već morate pogledati u bazu podataka, pogledati u konfiguraciji, što uzrokuje takvo obilje kontrolnih tačaka. Možda dolazi neki veliki rekord. Već možemo procijeniti opterećenje, jer smo već dodali grafikone opterećenja. Već možemo podesiti parametre tačke prekida i osigurati da oni u velikoj meri ne utiču na performanse upita.

Opet se vraćam na autovakuum jer je to vrsta stvari, kao što sam rekao, koja lako može sabrati performanse diska i upita, tako da je uvijek važno izmjeriti količinu autovakuma.

Broj autovakumaša u bazi podataka je ograničen. Standardno ih ima tri, pa ako imamo tri radnika koji stalno rade u bazi podataka, onda to znači da je naš autovacuum nedovoljno konfiguriran, moramo podići granice, revidirati postavke autovakuma i već se penjati u konfiguraciju.
Važno je procijeniti koji usisivači rade za nas. Ili je pokrenut od korisnika, DBA je ušao i pokrenuo neku vrstu vakuuma svojim rukama, i to je stvorilo opterećenje. Imamo neki problem. Ili je ovo broj vakuuma koji odvrću brojač transakcija. Za neke verzije PostgreSQL-a, ovo su veoma teški usisivači. I lako mogu dodati performanse jer oduzimaju cijelu tablicu, skenirajući sve blokove u ovoj tablici.

I, naravno, trajanje usisavanja. Ako imamo duge usisivače koji rade jako dugo, onda to znači da ponovo trebamo obratiti pažnju na konfiguraciju usisivača i možda preispitati njegove postavke. Jer može nastati situacija kada usisivač radi na stolu dugo (3-4 sata), ali tokom rada usisivača, velika količina mrtvih redova ponovo se akumulira u tabeli. I čim se vakuum završi, treba ponovo da usisa ovaj sto. I dolazimo u situaciju - beskonačan vakuum. I u ovom slučaju, vakuum se ne nosi sa svojim radom, a tablice počinju postepeno povećavati veličinu, iako količina korisnih podataka u njemu ostaje ista. Stoga, u dugim vakuumima, uvijek gledamo konfiguraciju i pokušavamo je optimizirati, ali u isto vrijeme, tako da performanse zahtjeva klijenata ne trpe.

Sada praktički ne postoji instalacija PostgreSQL-a gdje nije bilo streaming replikacije. Replikacija je proces prijenosa podataka sa glavnog na repliku.

Replikacija u PostgreSQL-u je uređena kroz dnevnik transakcija. Master generiše dnevnik transakcija. Dnevnik transakcija na mrežnoj vezi ide na repliku, a zatim se reproducira na replici. Sve je jednostavno.

Shodno tome, pg_stat_replication pogled se koristi za praćenje kašnjenja replikacije. Ali nije joj lako. U verziji 10, pogled je doživio nekoliko promjena. Prvo, neka polja su preimenovana. I neka polja su dodana. U 10. verziji pojavila su se polja koja vam omogućavaju da procijenite kašnjenje replikacije u sekundama. Veoma je udoban. Prije verzije 10, bilo je moguće procijeniti kašnjenje replikacije u bajtovima. Ova funkcija je ostala u 10. verziji, odnosno možete odabrati što vam je zgodnije - procijeniti kašnjenje u bajtovima ili procijeniti kašnjenje u sekundama. Mnogi rade i jedno i drugo.

Međutim, da biste procijenili kašnjenje replikacije, morate znati poziciju dnevnika u transakciji. A ove pozicije dnevnika transakcija su samo u pg_stat_replication prikazu. Relativno govoreći, možemo koristiti funkciju pg_xlog_location_diff() da uzmemo dvije točke u dnevniku transakcija. Izračunajte deltu između njih i dobijte kašnjenje replikacije u bajtovima. Vrlo je zgodan i jednostavan.

U verziji 10 ova funkcija je preimenovana u pg_wal_lsn_diff(). Općenito, u svim funkcijama, pogledima, uslužnim programima, gdje se susrela riječ "xlog", ona je zamijenjena vrijednošću "wal". Ovo je i u pogledima i u funkcijama. Ovo je takva inovacija.

Plus, u 10. verziji dodane su linije koje posebno pokazuju zaostajanje. To su kašnjenje u pisanju, kašnjenje ispiranja, kašnjenje ponovnog reprodukcije. Odnosno, važno je pratiti ove stvari. Ako vidimo da imamo kašnjenje u replikaciji, onda moramo istražiti zašto se pojavio, odakle je došao i riješiti problem.

Sa sistemskim metrikama, skoro sve je u redu. Kada se rodi bilo kakvo praćenje, počinje sa sistemskim metrikama. Ovo je korištenje procesora, memorije, zamjene, mreže i diska. Ali ipak, mnogi parametri nisu tamo po defaultu.

Ako je sve u redu s odlaganjem procesa, onda postoje problemi s odlaganjem diska. Po pravilu, programeri za praćenje dodaju informacije o propusnosti. Može biti u iops ili bajtovima. Ali zaboravljaju na kašnjenje i korištenje disk uređaja. Ovo su važniji parametri koji nam omogućavaju da procijenimo koliko su naši diskovi opterećeni i koliko se usporavaju. Ako imamo veliko kašnjenje, onda to znači da postoje neki problemi sa diskovima. Ako imamo visoku iskorištenost, onda to znači da se diskovi ne mogu nositi. Ovo su više kvalitativne karakteristike nego propusni opseg.

Međutim, ove statistike se takođe mogu dobiti iz /proc sistema datoteka, kao što se radi za recikliranje procesora. Zašto se ova informacija ne dodaje u monitoring, ne znam. Ali još uvijek je važno da ga imate u svom nadzoru.

Isto vrijedi i za mrežna sučelja. Postoje informacije o propusnosti mreže u paketima, u bajtovima, ali ipak nema informacija o kašnjenju niti o korištenju, iako je i ovo korisna informacija.

Svako praćenje ima svoje nedostatke. I bez obzira na vrstu praćenja, ono uvijek neće ispuniti određene kriterije. Ali ipak se razvijaju, dodaju se nove funkcije, nove stvari, pa izaberite nešto i završite.

A da biste završili, uvijek morate imati predstavu šta data statistika znači i kako možete riješiti probleme s njom.

I nekoliko ključnih tačaka:

• Uvijek morate pratiti dostupnost, imati kontrolne table tako da možete brzo procijeniti da je sve u redu sa bazom.
• Uvijek morate imati predstavu o tome koji klijenti rade s vašom bazom podataka kako biste iskorijenili loše klijente i ubili ih.
• Važno je procijeniti kako ovi klijenti rade s podacima. Morate imati ideju o svom poslu.
• Važno je procijeniti kako se formira ovo radno opterećenje, uz pomoć kojih upita. Možete procijeniti upite, možete ih optimizirati, refaktorirati, izgraditi indekse za njih. To je veoma važno.
• Pozadinski procesi mogu negativno utjecati na zahtjeve klijenata, pa je važno osigurati da ne koriste previše resursa.
• Sistemske metrike vam omogućavaju da napravite planove za skaliranje, za povećanje kapaciteta vaših servera, tako da je važno pratiti i procijeniti i njih.

Ako ste zainteresovani za ovu temu, onda možete pratiti ove linkove.
http://bit.do/stats_collector je zvanična dokumentacija sakupljača statistike. Postoji opis svih statističkih pregleda i opis svih polja. Možete ih čitati, razumjeti i analizirati. I na osnovu njih napravite svoje karte, dodajte svoj monitoring.

Primjeri zahtjeva:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Ovo je naše korporativno spremište i moje vlastito. Imaju zahtjeve za uzorke. Nema upita iz odabranih* iz serije, ima nešto. Već postoje gotovi zahtjevi sa spojevima, koristeći zanimljive funkcije koje vam omogućavaju da napravite čitljive, prikladne vrijednosti od sirovih brojeva, odnosno, to su bajtovi, vrijeme. Možete ih odabrati, gledati, analizirati, dodati u svoje monitoringe, izgraditi vlastite monitoringe na osnovu njih.

Vaša pitanja

Pitanje: Rekli ste da nećete reklamirati brendove, ali se još uvijek pitam – kakve dashboarde koristite u svojim projektima?
Odgovor: Na različite načine. Dešava se da dođemo do kupca i on već ima svoj nadzor. I savjetujemo kupca o tome šta treba dodati njegovom praćenju. Najgora situacija je sa Zabbixom. Zato što nema mogućnost izgradnje TopN-grafike. Mi sami koristimo Okmeterjer smo konsultovali ove momke o nadgledanju. Oni su radili PostgreSQL monitoring na osnovu našeg TOR-a. Pišem svoj vlastiti pet-projekat, koji prikuplja podatke preko Prometeja i uvlači ih grafana. Moj zadatak je da napravim svoj izvoznik u Prometeju i onda sve nacrtam u Grafani.

Pitanje: Postoje li analozi AWR izvještaja ili ... agregacija? Da li vam je poznato ovako nešto?
Odgovor: Da, znam šta je AWR, to je kul stvar. Trenutno postoji niz bicikala koji implementiraju otprilike sljedeći model. U nekom vremenskom intervalu, neke osnovne linije se zapisuju u isti PostgreSQL ili u zasebno skladište. Možete ih proguglati na internetu, jesu. Jedan od programera takve stvari sjedi na sql.ru forumu u PostgreSQL temi. Možete ga tamo uhvatiti. Da, postoje takve stvari, mogu se koristiti. plus u svom pgCenter Takođe pišem nešto što vam omogućava da uradite isto.

PS1 Ako koristite postgres_exporter, koju kontrolnu tablu koristite? Ima ih nekoliko. Oni su već zastarjeli. Može li zajednica kreirati ažurirani šablon?

PS2 Uklonjen pganalyze jer je to vlasnička SaaS ponuda koja se fokusira na praćenje performansi i automatske prijedloge za podešavanje.

Samo registrovani korisnici mogu učestvovati u anketi. Prijavite semolim.

Koji samostalno hostovani postgresql monitoring (sa kontrolnom pločom) mislite da je najbolji?

• 30,0%Zabbix + dodaci od Alexey Lesovsky 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 može se 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

Glasalo je 10 korisnika. Uzdržano je bilo 26 korisnika.

izvor: www.habr.com