Siūlau perskaityti Aleksejaus Lesovskio pranešimo iš Data Egret „PostgreSQL stebėjimo pagrindai“ stenogramą.
Šioje ataskaitoje Aleksejus Lesovskis kalbės apie pagrindinius statistikos post-gress punktus, ką jie reiškia ir kodėl jie turėtų būti stebimi; apie tai, kokie grafikai turėtų būti stebėjime, kaip juos pridėti ir kaip juos interpretuoti. Ataskaita bus naudinga duomenų bazių administratoriams, sistemų administratoriams ir kūrėjams, kurie domisi Postgres trikčių šalinimu.
Mano vardas Aleksejus Lesovskis, atstovauju įmonei Data Egret.
Keletas žodžių apie save. Seniai pradėjau dirbti sistemos administratoriumi.
Administravau įvairiausias Linux sistemas, dirbau su įvairiais su Linux susijusiais dalykais, t.y. virtualizavimu, stebėjimu, dirbau su tarpiniais serveriais ir pan. Bet kažkuriuo metu pradėjau daugiau dirbti su duomenų bazėmis, PostgreSQL. Jis man labai patiko. Ir tam tikru momentu pradėjau dirbti su PostgreSQL didžiąją savo darbo laiko dalį. Ir taip palaipsniui tapau PostgreSQL DBA.
Ir visą savo karjerą mane visada domino statistikos, stebėjimo ir telemetrijos temos. O kai buvau sistemos administratorius, labai glaudžiai dirbau su „Zabbix“. Ir aš parašiau nedidelį scenarijų rinkinį, pvz . Savo laiku jis buvo gana populiarus. O ten buvo galima stebėti labai skirtingus svarbius dalykus, ne tik Linux, bet ir įvairius komponentus.
Dabar dirbu su PostgreSQL. Jau rašau kitą dalyką, leidžiantį dirbti su PostgreSQL statistika. Tai vadinama (straipsnis apie Habré - ).
Maža įžanginė pastaba. Kokias situacijas patiria mūsų klientai, mūsų klientai? Įvyko kažkokia su duomenų baze susijusi nelaimė. O kai duomenų bazė jau atkurta, ateina skyriaus vedėjas ar plėtros vadovas ir sako: „Draugai, reikia stebėti duomenų bazę, nes atsitiko kažkas blogo ir reikia, kad taip nenutiktų ateityje“. Ir čia prasideda įdomus stebėjimo sistemos pasirinkimo arba esamos stebėjimo sistemos pritaikymo procesas, kad galėtumėte stebėti savo duomenų bazę – PostgreSQL, MySQL ar kai kurias kitas. Ir kolegos ima siūlyti: „Girdėjau, kad yra tokia ir tokia duomenų bazė. Naudokimės“. Kolegos pradeda ginčytis tarpusavyje. Ir galiausiai pasirodo, kad mes pasirenkame kažkokią duomenų bazę, bet joje gana prastai pateikiamas PostgreSQL monitoringas ir vis tenka ką nors pridėti. Paimkite keletą saugyklų iš „GitHub“, klonuokite jas, pritaikykite scenarijus ir kažkaip tinkinkite. Ir galiausiai tai yra kažkoks rankų darbas.
Todėl šiame pokalbyje pabandysiu suteikti jums žinių, kaip pasirinkti stebėjimą ne tik PostgreSQL, bet ir duomenų bazei. Suteikite jums žinių, kurios leis jums užbaigti stebėjimą, kad iš to gautumėte tam tikros naudos, kad galėtumėte stebėti savo duomenų bazę, kad galėtumėte greitai užkirsti kelią bet kokioms avarinėms situacijoms, kurios gali kilti.
Ir idėjos, kurios bus šioje ataskaitoje, gali būti tiesiogiai pritaikytos bet kuriai duomenų bazei, nesvarbu, ar tai būtų DBVS, ar noSQL. Todėl yra ne tik PostgreSQL, bet bus daug receptų, kaip tai padaryti naudojant PostgreSQL. Bus užklausų pavyzdžių, objektų, kuriuos PostgreSQL turi stebėjimui, pavyzdžiai. Ir jei jūsų DBVS turi tuos pačius dalykus, kurie leidžia juos įdėti į stebėjimą, galite juos pritaikyti, pridėti ir bus gerai.
Aš nedalyvausiu reportaže
kalbėti apie tai, kaip pateikti ir saugoti metrikas. Apie duomenų apdorojimą ir pateikimą vartotojui nieko nesakysiu. O apie perspėjimą nieko nesakysiu.
Tačiau istorijai įsibėgėjus parodysiu skirtingus esamo stebėjimo ekrano vaizdus ir kažkaip juos kritikuosiu. Bet nepaisant to, prekių ženklų stengsiuosi nevardinti, kad šiems produktams nekurtų reklamos ar antireklamos. Todėl visi sutapimai yra atsitiktiniai ir paliekami jūsų vaizduotei.
Pirmiausia išsiaiškinkime, kas yra stebėjimas. Stebėjimas yra labai svarbus dalykas. Visi tai supranta. Tačiau tuo pat metu stebėjimas nesusijęs su verslo produktu ir neturi tiesioginės įtakos įmonės pelnui, todėl laikas stebėjimui visada skiriamas likutiniu pagrindu. Jei turime laiko, tada stebime; jei neturime laiko, tada gerai, įtrauksime jį į atsilikimą ir kada nors grįšime prie šių užduočių.
Todėl iš mūsų praktikos, kai ateiname pas klientus, stebėjimas dažnai būna neišsamus ir neturi jokių įdomių dalykų, kurie padėtų mums geriau dirbti su duomenų baze. Todėl stebėjimas visada turi būti baigtas.
Duomenų bazės yra tokie sudėtingi dalykai, kuriuos taip pat reikia stebėti, nes duomenų bazės yra informacijos saugykla. O informacija įmonei labai svarbi, jos jokiu būdu negalima prarasti. Tačiau tuo pat metu duomenų bazės yra labai sudėtingos programinės įrangos dalys. Jie susideda iš daugybės komponentų. Ir daugelį šių komponentų reikia stebėti.
Jei mes kalbame konkrečiai apie PostgreSQL, tada jis gali būti pavaizduotas schemos, kurią sudaro daugybė komponentų, forma. Šie komponentai sąveikauja vienas su kitu. O tuo pačiu PostgreSQL turi taip vadinamą Stats Collector posistemę, kuri leidžia rinkti statistiką apie šių posistemių veikimą ir pateikti kažkokią sąsają administratoriui ar vartotojui, kad jis galėtų peržiūrėti šią statistiką.
Ši statistika pateikiama tam tikro funkcijų ir vaizdų rinkinio pavidalu. Jie taip pat gali būti vadinami lentelėmis. Tai yra, naudodami įprastą psql klientą, galite prisijungti prie duomenų bazės, pasirinkti šias funkcijas ir rodinius ir gauti konkrečius skaičius apie PostgreSQL posistemių veikimą.
Šiuos skaičius galite įtraukti į savo mėgstamą stebėjimo sistemą, braižyti grafikus, pridėti funkcijų ir gauti ilgalaikės analizės.
Tačiau šiame pranešime neaprašysiu visų šių funkcijų iki galo, nes tai gali užtrukti visą dieną. Pažodžiui aptarsiu du, tris ar keturis dalykus ir pasakysiu, kaip jie padeda pagerinti stebėjimą.
O jei kalbame apie duomenų bazių stebėjimą, tai ką tuomet reikia stebėti? Visų pirma, turime stebėti prieinamumą, nes duomenų bazė yra paslauga, suteikianti klientams prieigą prie duomenų, o mes turime stebėti prieinamumą, taip pat pateikti kai kurias kokybines ir kiekybines jos charakteristikas.
Taip pat turime stebėti klientus, kurie prisijungia prie mūsų duomenų bazės, nes jie gali būti ir įprasti klientai, ir žalingi klientai, galintys pakenkti duomenų bazei. Juos taip pat reikia stebėti ir sekti jų veiklą.
Kai klientai prisijungia prie duomenų bazės, akivaizdu, kad jie pradeda dirbti su mūsų duomenimis, todėl turime stebėti, kaip klientai dirba su duomenimis: su kokiomis lentelėmis ir kiek mažiau – su kokiais indeksais. Tai yra, turime įvertinti darbo krūvį, kurį sukuria mūsų klientai.
Tačiau darbo krūvį, žinoma, sudaro ir prašymai. Programos jungiasi prie duomenų bazės, pasiekia duomenis naudodami užklausas, todėl svarbu įvertinti, kokias užklausas turime duomenų bazėje, stebėti jų tinkamumą, kad nebūtų kreivai parašytos, kad kai kurias parinktis reikia perrašyti ir padaryti taip, kad jos veiktų greičiau ir su geresniu našumu.
Ir kadangi mes kalbame apie duomenų bazę, duomenų bazė visada yra foniniai procesai. Fono procesai padeda palaikyti gerą duomenų bazės našumą, todėl jiems reikia tam tikro išteklių, kad galėtų veikti. Ir tuo pat metu jie gali sutapti su klientų užklausų ištekliais, todėl gobšūs foniniai procesai gali tiesiogiai paveikti klientų užklausų vykdymą. Todėl juos taip pat reikia stebėti ir sekti, kad nebūtų iškraipymų, susijusių su foniniais procesais.
Ir visa tai duomenų bazės stebėjimo požiūriu lieka sistemos metrikoje. Tačiau atsižvelgiant į tai, kad didžioji mūsų infrastruktūros dalis pereina į debesis, atskiro pagrindinio kompiuterio sistemos metrika visada išnyksta į foną. Bet duomenų bazėse jie vis dar aktualūs ir, žinoma, taip pat būtina stebėti sistemos metrikas.
Su sistemos metrika viskas daugmaž gerai, visos šiuolaikinės stebėjimo sistemos jau palaiko šiuos rodiklius, bet apskritai kai kurių komponentų vis tiek neužtenka ir kai kuriuos dalykus reikia papildyti. Paliesiu ir juos, apie juos bus kelios skaidrės.
Pirmasis plano punktas yra prieinamumas. Kas yra prieinamumas? Prieinamumas, mano supratimu, yra bazės galimybė aptarnauti ryšius, t.y. bazė yra pakelta, ji, kaip paslauga, priima prisijungimus iš klientų. Ir šį prieinamumą galima įvertinti pagal tam tikras savybes. Labai patogu šias charakteristikas rodyti prietaisų skydeliuose.
Visi žino, kas yra prietaisų skydeliai. Tai yra tada, kai vieną kartą pažvelgėte į ekraną, kuriame apibendrinama reikalinga informacija. Ir jūs galite iš karto nustatyti, ar duomenų bazėje yra problemų, ar ne.
Atitinkamai duomenų bazės prieinamumas ir kitos pagrindinės charakteristikos visada turėtų būti rodomos prietaisų skydeliuose, kad ši informacija būtų po ranka ir visada pasiekiama. Kai kurios papildomos detalės, kurios jau padeda tiriant incidentus, tiriant kai kurias avarines situacijas, jas jau reikia patalpinti antriniuose prietaisų skydeliuose arba paslėpti nuorodose, kurios veda į trečiųjų šalių stebėjimo sistemas.
Vienos gerai žinomos stebėjimo sistemos pavyzdys. Tai labai šauni stebėjimo sistema. Ji renka daug duomenų, bet, mano požiūriu, ji turi keistą prietaisų skydelių koncepciją. Yra nuoroda „sukurti prietaisų skydelį“. Tačiau kai kuriate prietaisų skydelį, sukuriate dviejų stulpelių sąrašą, grafikų sąrašą. O kai reikia ką nors pažiūrėti, imi spustelėti pele, slinkti, ieškoti norimos diagramos. Ir tai užtrunka, t. y. nėra prietaisų skydelių. Yra tik diagramų sąrašai.
Ką turėtumėte pridėti prie šių prietaisų skydelių? Galite pradėti nuo tokios charakteristikos kaip atsako laikas. PostgreSQL turi pg_stat_statements rodinį. Pagal numatytuosius nustatymus jis išjungtas, tačiau tai yra vienas iš svarbių sistemos rodinių, kurį visada reikia įjungti ir naudoti. Jis saugo informaciją apie visas vykdomas užklausas, kurios buvo įvykdytos duomenų bazėje.
Atitinkamai, galime pradėti nuo to, kad galime paimti bendrą visų užklausų vykdymo laiką ir padalyti jį iš užklausų skaičiaus naudodami aukščiau nurodytus laukus. Bet tai yra vidutinė temperatūra ligoninėje. Galime pradėti nuo kitų laukų – minimalaus užklausos vykdymo laiko, maksimumo ir medianos. Ir netgi galime sukurti procentilius; PostgreSQL tam turi atitinkamas funkcijas. Ir mes galime gauti keletą skaičių, kurie apibūdina mūsų duomenų bazės reagavimo laiką į jau įvykdytas užklausas, t.y. mes nevykdome netikros užklausos 'select 1' ir žiūrime į atsakymo laiką, o analizuojame atsakymo laiką į jau įvykdytas užklausas ir piešiame. arba atskira figūra, arba pagal ją sukuriame grafiką.
Taip pat svarbu stebėti klaidų, kurias šiuo metu sukuria sistema, skaičių. Ir tam galite naudoti pg_stat_database rodinį. Mes sutelkiame dėmesį į lauką xact_rollback. Šiame lauke rodomas ne tik duomenų bazėje įvykusių atšaukimų skaičius, bet ir atsižvelgiama į klaidų skaičių. Santykinai kalbant, šį skaičių galime parodyti savo prietaisų skydelyje ir pamatyti, kiek klaidų šiuo metu turime. Jei klaidų yra daug, tai yra gera priežastis pažvelgti į žurnalus ir išsiaiškinti, kokios tai klaidos ir kodėl jos atsiranda, tada investuoti ir jas išspręsti.
Galite pridėti tokį dalyką kaip tachometras. Tai yra operacijų skaičius per sekundę ir užklausų skaičius per sekundę. Santykinai kalbant, galite naudoti šiuos skaičius kaip dabartinį savo duomenų bazės našumą ir stebėti, ar nėra užklausų, operacijų piko, ar, priešingai, ar duomenų bazė nėra apkrauta, nes sugedo kuri nors užpakalinė programa. Svarbu visada žiūrėti į šį skaičių ir atsiminti, kad mūsų projektui toks našumas yra normalus, tačiau aukščiau ir žemiau pateiktos reikšmės jau yra tam tikros problemos ir nesuprantamos, o tai reiškia, kad turime pažvelgti, kodėl šie skaičiai yra taip aukštai.
Norėdami įvertinti operacijų skaičių, vėl galime kreiptis į pg_stat_database rodinį. Galime pridėti įsipareigojimų skaičių ir atšaukimų skaičių ir gauti operacijų skaičių per sekundę.
Ar visi supranta, kad viename sandoryje gali tilpti keli prašymai? Todėl TPS ir QPS šiek tiek skiriasi.
Užklausų skaičių per sekundę galima gauti iš pg_stat_statements ir tiesiog apskaičiuoti visų įvykdytų užklausų sumą. Aišku, kad lyginame esamą vertę su ankstesne, ją atimame, gauname delta ir gauname kiekį.
Jei pageidaujate, galite pridėti papildomų metrikų, kurios taip pat padės įvertinti mūsų duomenų bazės prieinamumą ir stebėti, ar nebuvo prastovų.
Viena iš šių metrikų yra veikimo laikas. Tačiau „PostgreSQL“ veikimo laikas yra šiek tiek sudėtingas. Pasakysiu kodėl. Kai PostgreSQL paleidžiama, veiksnumo laikas pradeda teikti ataskaitas. Bet jei tam tikru momentu, pavyzdžiui, kokia nors užduotis buvo vykdoma naktį, atėjo OOM žudikas ir priverstinai nutraukė PostgreSQL antrinį procesą, tada šiuo atveju PostgreSQL nutraukia visų klientų ryšį, iš naujo nustato suskeltos atminties sritį ir pradeda atkūrimą paskutinis patikros punktas. Ir kol šis atkūrimas iš patikros punkto tęsiasi, duomenų bazė jungčių nepriima, t.y. šią situaciją galima vertinti kaip prastovą. Tačiau veikimo laiko skaitiklis nebus nustatytas iš naujo, nes jis atsižvelgia į postmaster paleidimo laiką nuo pat pirmos akimirkos. Todėl tokias situacijas galima praleisti.
Taip pat turėtumėte stebėti vakuuminių darbuotojų skaičių. Ar visi žino, kas yra automatinis vakuumas PostgreSQL? Tai įdomi PostgreSQL posistemė. Apie ją parašyta daug straipsnių, daug pranešimų. Yra daug diskusijų apie vakuumą ir kaip jis turėtų veikti. Daugelis mano, kad tai būtina blogybė. Bet taip yra. Tai savotiškas šiukšlių rinktuvo analogas, kuris išvalo pasenusias jokiai operacijai nereikalingas eilučių versijas ir atlaisvina vietos lentelėse bei indeksuose naujoms eilutėms.
Kodėl reikia tai stebėti? Nes vakuumas kartais labai skauda. Tai sunaudoja daug išteklių ir dėl to pradeda nukentėti klientų užklausos.
Ir tai turėtų būti stebima per pg_stat_activity rodinį, apie kurį kalbėsiu kitame skyriuje. Šiame rodinyje rodoma dabartinė veikla duomenų bazėje. Ir per šią veiklą galime sekti šiuo metu veikiančių dulkių siurblių skaičių. Galime stebėti vakuumą ir pamatyti, kad jei viršijome ribą, tai yra priežastis pažvelgti į PostgreSQL nustatymus ir kažkaip optimizuoti vakuumo veikimą.
Kitas dalykas, susijęs su PostgreSQL, yra tas, kad PostgreSQL labai kenčia nuo ilgų operacijų. Ypač iš sandorių, kurie ilgai kabo ir nieko nedaro. Tai yra vadinamoji „stat idle-in-transaction“. Toks sandoris sulaiko užraktus ir neleidžia vakuumui veikti. Dėl to lentelės išsipučia ir didėja. Ir užklausos, veikiančios su šiomis lentelėmis, pradeda veikti lėčiau, nes reikia perkelti visas senas eilučių versijas iš atminties į diską ir atgal. Todėl reikia stebėti ir laiką, ilgiausių operacijų trukmę, ilgiausių vakuuminių užklausų. Ir jei matome kai kuriuos procesus, kurie veikia labai ilgai, jau daugiau nei 10-20-30 minučių OLTP įkėlimui, tada turime į juos atkreipti dėmesį ir priverstinai juos nutraukti arba optimizuoti programą taip, kad jie neskambina ir taip ilgai nekabo. Analitiniam krūviui 10-20-30 minučių yra normalu, būna ir ilgesnių.
Toliau turime galimybę su prijungtais klientais. Kai jau sukūrėme prietaisų skydelį ir paskelbėme joje pagrindinę pasiekiamumo metriką, taip pat galime pridėti papildomos informacijos apie prijungtus klientus.
Informacija apie prijungtus klientus yra svarbi, nes iš PostgreSQL perspektyvos klientai yra skirtingi. Yra gerų klientų ir yra blogų klientų.
Paprastas pavyzdys. Iš kliento suprantu paraišką. Programėlė prisijungė prie duomenų bazės ir iš karto pradeda ten siųsti savo užklausas, duomenų bazė jas apdoroja ir vykdo, o rezultatus grąžina klientui. Tai geri ir teisingi klientai.
Būna situacijų, kai klientas prisijungė, palaiko ryšį, bet nieko nedaro. Jis yra tuščiosios eigos būsenoje.
Tačiau yra blogų klientų. Pavyzdžiui, tas pats klientas prisijungė, atidarė operaciją, ką nors padarė duomenų bazėje ir tada įėjo į kodą, pavyzdžiui, norėdamas pasiekti išorinį šaltinį arba apdoroti ten gautus duomenis. Tačiau jis sandorio neuždarė. O sandoris kabo duomenų bazėje ir laikomas linijos užraktu. Tai bloga būklė. Ir jei staiga kažkurioje savo viduje esanti programa sugenda su išimtimi, tada sandoris gali likti atidarytas labai ilgai. Ir tai tiesiogiai veikia PostgreSQL našumą. PostgreSQL bus lėtesnis. Todėl svarbu laiku susekti tokius klientus ir priverstinai nutraukti jų darbą. Ir jūs turite optimizuoti savo programą, kad tokių situacijų nebūtų.
Kiti blogi klientai laukia klientų. Bet jie tampa blogi dėl aplinkybių. Pavyzdžiui, paprastas tuščiosios eigos sandoris: jis gali atidaryti operaciją, užrakinti kai kurias eilutes, tada kažkur kode jis nepavyks, palikdamas kabančią operaciją. Kitas klientas ateis ir paprašys tų pačių duomenų, tačiau jis susidurs su užraktu, nes ta pakabinama operacija jau turi užraktus kai kuriose reikalingose eilutėse. O antrasis sandoris kabos laukdamas, kol pirmasis sandoris bus baigtas arba jį priverstinai uždarys administratorius. Todėl laukiančios operacijos gali kauptis ir užpildyti duomenų bazės ryšio limitą. O kai limitas pilnas, programa nebegali dirbti su duomenų baze. Tai jau yra ekstremali situacija projektui. Todėl blogus klientus reikia sekti ir į juos reaguoti laiku.
Kitas stebėjimo pavyzdys. Ir čia jau yra tinkamas prietaisų skydelis. Informacija apie jungtis yra aukščiau. DB jungtis – 8 vnt. Ir viskas. Neturime informacijos apie tai, kurie klientai yra aktyvūs, kurie tiesiog dyksta, nieko nedaro. Nėra informacijos apie laukiančias operacijas ir laukiančius ryšius, t. y. tai yra skaičius, rodantis prisijungimų skaičių ir viskas. Ir tada atspėk patys.
Atitinkamai, norėdami pridėti šią informaciją prie stebėjimo, turite pasiekti pg_stat_activity sistemos rodinį. Jei daug laiko praleidžiate PostgreSQL, tai yra labai geras vaizdas, kuris turėtų tapti jūsų draugu, nes jis parodo dabartinę veiklą PostgreSQL, t.y. kas jame vyksta. Kiekvienam procesui yra atskira eilutė, kurioje rodoma informacija apie šį procesą: iš kurio kompiuterio buvo užmegztas ryšys, su kokiu vartotoju, kokiu vardu, kada buvo pradėta operacija, kokia užklausa šiuo metu vykdoma, kokia užklausa buvo įvykdyta paskutinį kartą. Ir atitinkamai galime įvertinti kliento būseną naudodami statistikos lauką. Santykinai kalbant, galime sugrupuoti pagal šį lauką ir gauti tuos statistinius duomenis, kurie šiuo metu yra duomenų bazėje, ir jungčių, turinčių šią statistiką duomenų bazėje, skaičių. O jau gautus skaičius galime siųsti į savo stebėjimą ir pagal juos braižyti grafikus.
Taip pat svarbu įvertinti sandorio trukmę. Jau sakiau, kad svarbu įvertinti vakuumų trukmę, bet sandoriai vertinami taip pat. Yra laukai xact_start ir query_start. Jie, palyginti, rodo operacijos pradžios laiką ir užklausos pradžios laiką. Paimame funkciją now(), kuri rodo esamą laiko žymą, ir atimame operaciją bei užklausos laiko žymą. Ir gauname sandorio trukmę, užklausos trukmę.
Jei matome ilgas operacijas, turėtume jas jau užbaigti. OLTP apkrovos atveju ilgos operacijos jau trunka ilgiau nei 1–2–3 minutes. Esant OLAP darbo krūviui, ilgos operacijos yra normalu, bet jei jos užtrunka ilgiau nei dvi valandas, tai taip pat yra ženklas, kad kažkur turime nuokrypį.
Prisijungę prie duomenų bazės klientai pradeda dirbti su mūsų duomenimis. Jie pasiekia lenteles, jie pasiekia indeksus, kad gautų duomenis iš lentelės. Ir svarbu įvertinti, kaip klientai sąveikauja su šiais duomenimis.
Tai būtina norint įvertinti savo darbo krūvį ir apytiksliai suprasti, kurios lentelės mums yra „karščiausios“. Pavyzdžiui, to reikia tais atvejais, kai norime pastatyti „karštas“ lenteles ant kokios nors greitos SSD atminties. Pavyzdžiui, kai kurias seniai nenaudojamas archyvines lenteles galima perkelti į kažkokį „šaltą“ archyvą, į SATA diskus ir leisti ten gyventi, bus prieita pagal poreikį.
Tai taip pat naudinga norint aptikti anomalijas po bet kokių leidimų ir diegimų. Tarkime, kad projektas išleido keletą naujų funkcijų. Pavyzdžiui, pridėjome naujų funkcijų, skirtų darbui su duomenų baze. Ir jei nubraižysime lentelės naudojimo grafikus, šiuose grafikuose nesunkiai aptiksime šias anomalijas. Pavyzdžiui, atnaujinti serijas arba ištrinti serijas. Tai bus labai matoma.
Taip pat galite aptikti „plaukiojančios“ statistikos anomalijas. Ką tai reiškia? PostgreSQL turi labai stiprų ir labai gerą užklausų planuoklį. Ir kūrėjai jos kūrimui skiria daug laiko. Kaip jis dirba? Siekdama sudaryti gerus planus, PostgreSQL renka statistiką apie duomenų pasiskirstymą lentelėse tam tikru laiko intervalu ir tam tikru dažnumu. Tai dažniausiai pasitaikančios reikšmės: unikalių reikšmių skaičius, informacija apie NULL lentelėje, daug informacijos.
Remdamasis šia statistika, planuotojas sukonstruoja kelias užklausas, parenka optimaliausią ir pagal šį užklausos planą atlieka pačią užklausą bei grąžina duomenis.
O būna, kad statistika „plaukia“. Lentelėje kažkaip pasikeitė kokybės ir kiekybės duomenys, tačiau statistika nebuvo renkama. O susidarę planai gali būti ne optimalūs. Ir jei mūsų planai pasirodys neoptimalūs, remiantis surinkta stebėsena, remiantis lentelėmis, mes galėsime pamatyti šias anomalijas. Pavyzdžiui, kai kur duomenys pasikeitė kokybiškai ir vietoj indekso pradėtas naudoti nuoseklus perėjimas per lentelę, t.y. jei užklausa turi pateikti tik 100 eilučių (yra 100 limitas), tada bus atlikta visa šios užklausos paieška. Ir tai visada labai blogai veikia našumą.
Ir tai matome stebėdami. Ir jau pažiūrėkite į šią užklausą, paleiskite jos paaiškinimą, rinkkite statistiką, sukurkite naują papildomą indeksą. Ir jau atsakyti į šią problemą. Štai kodėl tai svarbu.
Kitas stebėjimo pavyzdys. Manau, kad daugelis jį atpažino, nes jis labai populiarus. Kas tai naudoja savo projektuose ? Kas naudoja šį produktą kartu su Prometheus? Faktas yra tas, kad standartinėje šio stebėjimo saugykloje yra prietaisų skydelis, skirtas darbui su PostgreSQL - Prometėjas. Tačiau yra viena bloga detalė.
Yra keletas grafikų. O baitai nurodomi kaip vienetas, ty yra 5 grafikai. Tai yra Įterpti duomenis, Atnaujinti duomenis, Ištrinti duomenis, Gauti duomenis ir Grąžinti duomenis. Matavimo vienetas yra baitai. Bet reikalas yra tas, kad „PostgreSQL“ statistika pateikia duomenis eilutėje (eilutėse). Ir, atitinkamai, šie grafikai yra labai geras būdas kelis kartus, dešimtis kartų neįvertinti savo darbo krūvio, nes korta yra ne baitas, o korta yra eilutė, tai daug baitų ir visada kintamo ilgio. Tai yra, darbo krūvio skaičiavimas baitais naudojant eilutes yra nereali arba labai sudėtinga užduotis. Todėl, kai naudojate prietaisų skydelį arba įmontuotą stebėjimą, visada svarbu suprasti, kad jis veikia tinkamai ir grąžina jums teisingai įvertintus duomenis.
Kaip gauti statistiką šiose lentelėse? Šiuo tikslu PostgreSQL turi tam tikrą požiūrių šeimą. Ir pagrindinis vaizdas yra . User_tables – tai reiškia lenteles, sukurtas vartotojo vardu. Priešingai, yra sistemos rodinių, kuriuos naudoja pats PostgreSQL. Ir yra suvestinė lentelė Alltables, kurioje yra ir sistemos, ir vartotojo. Galite pradėti nuo bet kurio iš jų, kuris jums labiausiai patinka.
Naudodami aukščiau pateiktus laukus galite įvertinti įterpimų, atnaujinimų ir ištrynimų skaičių. Naudojamo prietaisų skydelio pavyzdyje šie laukai naudojami darbo krūvio ypatybėms įvertinti. Todėl galime remtis ir jais. Tačiau verta atsiminti, kad tai yra kortelės, o ne baitai, todėl negalime to daryti tik baitais.
Remdamiesi šiais duomenimis galime sukurti vadinamąsias TopN lenteles. Pavyzdžiui, Top-5, Top-10. Ir jūs galite stebėti tuos karštus stalus, kurie yra perdirbami daugiau nei kiti. Pavyzdžiui, 5 „karštosios“ lentelės įterpimui. Naudodami šias TopN lenteles įvertiname savo darbo krūvį ir galime įvertinti darbo krūvio eigą po bet kokių leidimų, atnaujinimų ir diegimų.
Taip pat svarbu įvertinti lentelės dydį, nes kartais kūrėjai išleidžia naują funkciją, o mūsų lentelės pradeda išsipūsti dideliais dydžiais, nes nusprendė pridėti papildomą duomenų kiekį, bet nenumatė, kaip tai atsitiks. įtakos duomenų bazės dydžiui. Tokie atvejai mums taip pat būna netikėti.
O dabar mažas klausimas jums. Koks klausimas kyla pastebėjus duomenų bazės serverio apkrovą? Kokį kitą klausimą turite?
Tačiau iš tikrųjų klausimas kyla taip. Kokius prašymus sukelia apkrova? Tai yra, neįdomu žiūrėti į procesus, kuriuos sukelia apkrova. Aišku, jei kompiuteris turi duomenų bazę, vadinasi, duomenų bazė ten veikia ir aišku, kad ten bus disponuojamos tik duomenų bazės. Jei atidarysime „Top“, pamatysime PostgreSQL procesų, kurie kažką daro, sąrašą. Iš viršaus nebus aišku, ką jie daro.
Atitinkamai, reikia rasti tas užklausas, kurios sukelia didžiausią apkrovą, nes derinimo užklausos, kaip taisyklė, duoda daugiau pelno nei PostgreSQL ar operacinės sistemos konfigūracijos derinimas ar net aparatinės įrangos derinimas. Mano vertinimu, tai yra maždaug 80–85–90%. Ir tai daroma daug greičiau. Greičiau pataisyti užklausą nei taisyti konfigūraciją, suplanuoti pakartotinį paleidimą, ypač jei duomenų bazės negalima paleisti iš naujo, arba pridėti aparatinę įrangą. Paprasčiau kur nors perrašyti užklausą arba pridėti indeksą, kad gautumėte geresnį šios užklausos rezultatą.
Atitinkamai būtina stebėti prašymus ir jų tinkamumą. Paimkime dar vieną stebėjimo pavyzdį. Ir čia taip pat atrodo puikus stebėjimas. Yra informacijos apie replikaciją, yra informacijos apie pralaidumą, blokavimą, išteklių panaudojimą. Viskas gerai, bet informacijos apie prašymus nėra. Neaišku, kokios užklausos veikia mūsų duomenų bazėje, kiek laiko jos vykdomos, kiek tokių užklausų yra. Šią informaciją visada turime turėti stebėjimo sistemoje.
Norėdami gauti šią informaciją, galime naudoti pg_stat_statements modulį. Remdamiesi juo galite sudaryti įvairius grafikus. Pavyzdžiui, galite gauti informacijos apie dažniausiai atliekamas užklausas, ty apie tas užklausas, kurios vykdomos dažniausiai. Taip, po diegimo taip pat labai naudinga pažvelgti į tai ir suprasti, ar nėra užklausų antplūdžio.
Galite stebėti ilgiausias užklausas, ty tas užklausas, kurių pildymas užtrunka ilgiausiai. Jie veikia su procesoriumi, jie naudoja I/O. Taip pat galime tai įvertinti naudodami laukus total_time, mean_time, blk_write_time ir blk_read_time.
Galime įvertinti ir stebėti sunkiausias resursų naudojimo užklausas, tas, kurios skaito iš disko, kurios dirba su atmintimi arba, atvirkščiai, sukuria tam tikrą rašymo apkrovą.
Galime įvertinti dosniausius prašymus. Tai yra užklausos, kurios pateikia daug eilučių. Pavyzdžiui, tai gali būti užklausa, kai jie pamiršo nustatyti ribą. Ir jis tiesiog grąžina visą lentelės ar užklausos turinį visose užklausose pateiktose lentelėse.
Taip pat galite stebėti užklausas, kuriose naudojami laikinieji failai arba laikinosios lentelės.
Ir mes vis dar turime foninius procesus. Fono procesai pirmiausia yra kontroliniai taškai arba jie taip pat vadinami kontroliniais taškais, tai yra autovakuumas ir replikacija.
Kitas stebėjimo pavyzdys. Kairėje yra priežiūros skirtukas, eikite į jį ir tikėkitės pamatyti ką nors naudingo. Bet čia tik vakuuminio veikimo ir statistikos rinkimo laikas, nieko daugiau. Tai labai prasta informacija, todėl visada turime turėti informacijos apie tai, kaip mūsų duomenų bazėje veikia foniniai procesai ir ar nėra problemų dėl jų darbo.
Kai žiūrime į kontrolinius taškus, turėtume prisiminti, kad kontroliniai taškai nuplauna nešvarius puslapius iš susmulkintos atminties srities į diską, tada sukuria kontrolinį tašką. Ir šis kontrolinis taškas gali būti naudojamas kaip atkūrimo vieta, jei „PostgreSQL“ staiga buvo nutraukta kritiniu atveju.
Atitinkamai, norėdami išplauti visus „nešvarius“ puslapius į diską, turite parašyti tam tikrą kiekį. Ir, kaip taisyklė, sistemose, kuriose yra daug atminties, tai yra daug. Ir jei labai dažnai atliksime patikros taškus per trumpą intervalą, disko našumas labai sumažės. O klientų prašymai nukentės dėl išteklių trūkumo. Jie konkuruos dėl išteklių ir trūks produktyvumo.
Atitinkamai, naudodami pg_stat_bgwriter, naudodami nurodytus laukus, galime stebėti įvykusių kontrolinių taškų skaičių. O jei per tam tikrą laiką (per 10-15-20 minučių, per pusvalandį) turime daug kontrolinių punktų, pavyzdžiui, 3-4-5, tai jau gali būti problema. Ir jau reikia žiūrėti į duomenų bazę, pažiūrėti konfigūracijoje, kas lemia tokią kontrolinių punktų gausą. Galbūt vyksta koks nors didelis įrašymas. Jau galime įvertinti darbo krūvį, nes jau pridėjome krūvio grafikus. Jau galime pakoreguoti kontrolinio taško parametrus ir įsitikinti, kad jie neturi didelės įtakos užklausos našumui.
Aš vėl grįžtu prie automatinio vakuumo, nes tai yra toks dalykas, kaip jau sakiau, kuris gali lengvai pridėti tiek disko, tiek užklausos našumą, todėl visada svarbu įvertinti automatinio vakuumo kiekį.
Autovakuuminių darbuotojų skaičius duomenų bazėje ribotas. Pagal numatytuosius nustatymus jų yra trys, taigi, jei duomenų bazėje visada dirba trys darbuotojai, tai reiškia, kad mūsų autovakuumas nesukonfigūruotas, turime pakelti limitus, peržiūrėti autovakuumo nustatymus ir patekti į konfigūraciją.
Svarbu įvertinti, kokius vakuuminius darbuotojus turime. Arba jis buvo paleistas iš vartotojo, atėjo DBA ir rankiniu būdu paleido kažkokį vakuumą, ir tai sukūrė apkrovą. Turime kažkokią problemą. Arba tai yra dulkių siurblių, atsukančių operacijų skaitiklį, skaičius. Kai kurioms PostgreSQL versijoms tai yra labai sunkūs vakuumai. Ir jie gali lengvai susumuoti našumą, nes perskaito visą lentelę, nuskaito visus tos lentelės blokus.
Ir, žinoma, vakuumavimo trukmė. Jei turime ilgalaikius dulkių siurblius, kurie veikia labai ilgai, tai reiškia, kad vėl turime atkreipti dėmesį į vakuumo konfigūraciją ir galbūt persvarstyti jo nustatymus. Mat gali susiklostyti situacija, kai ant stalo veikia vakuumas ilgai (3-4 val.), tačiau per tą laiką, kai veikė vakuumas, lentelėje vėl pavyko susikaupti didelis kiekis negyvų eilių. Ir kai tik bus baigtas siurbimas, jam reikia vėl išsiurbti šią lentelę. Ir mes pasiekiame situaciją – begalinį vakuumą. Ir šiuo atveju vakuumas nesusidoroja su savo darbu, o lentelės palaipsniui pradeda išsipūsti, nors naudingų duomenų kiekis jame išlieka toks pat. Todėl ilgų vakuumų metu visada žiūrime į konfigūraciją ir stengiamės ją optimizuoti, bet kartu taip, kad nenukentėtų kliento užklausų atlikimas.
Šiuo metu praktiškai nėra „PostgreSQL“ diegimo, kuriame nebūtų transliacijos replikacijos. Replikacija yra duomenų perkėlimo iš pagrindinio įrenginio į kopiją procesas.
Replikacija PostgreSQL atliekama per operacijų žurnalą. Vedlys sukuria operacijų žurnalą. Operacijų žurnalas per tinklo ryšį keliauja į repliką, o tada jis atkuriamas kopijoje. Tai paprasta.
Atitinkamai, pg_stat_replication rodinys naudojamas replikacijos delsai stebėti. Tačiau su ja ne viskas paprasta. 10 versijoje vaizdas buvo kelis kartus pakeistas. Pirma, kai kurie laukai buvo pervadinti. Ir kai kurie laukai buvo pridėti. 10 versijoje pasirodė laukai, leidžiantys įvertinti replikacijos delsą per sekundes. Tai labai patogu. Prieš 10 versiją buvo galima įvertinti replikacijos vėlavimą baitais. Ši parinktis išlieka 10 versijoje, t.y. galite pasirinkti, kas jums patogiau – įvertinti vėlavimą baitais arba įvertinti vėlavimą sekundėmis. Daugelis žmonių daro abu.
Vis dėlto, norėdami įvertinti replikacijos vėlavimą, turite žinoti žurnalo padėtį operacijoje. Ir šios operacijų žurnalo pozicijos yra tiksliai pg_stat_replication rodinyje. Santykinai kalbant, operacijų žurnale galime paimti du taškus naudodami pg_xlog_location_diff() funkciją. Apskaičiuokite delta tarp jų ir gaukite replikacijos delsą baitais. Tai labai patogu ir paprasta.
10 versijoje ši funkcija buvo pervadinta į pg_wal_lsn_diff(). Apskritai visose funkcijose, rodiniuose ir paslaugų programose, kuriose buvo rastas žodis „xlog“, jis buvo pakeistas reikšme „wal“. Tai taikoma ir rodiniams, ir funkcijoms. Tai tokia naujovė.
Be to, 10 versijoje buvo pridėtos eilutės, kuriose konkrečiai rodomas atsilikimas. Tai yra rašymo delsa, praplovimo delsa, pakartojimo delsa. Tai yra, svarbu stebėti šiuos dalykus. Jei matome, kad turime replikacijos delsą, turime ištirti, kodėl jis atsirado, iš kur jis atsirado ir išspręsti problemą.
Su sistemos metrika beveik viskas tvarkoje. Kai prasideda stebėjimas, jis pradedamas nuo sistemos metrikos. Tai yra procesorių, atminties, apsikeitimo, tinklo ir disko pašalinimas. Tačiau daugelis parametrų ten nėra pagal numatytuosius nustatymus.
Jei perdirbimo procese viskas tvarkoje, kyla problemų dėl disko perdirbimo. Paprastai stebėjimo kūrėjai prideda informaciją apie pralaidumą. Tai gali būti iops arba baitais. Tačiau jie pamiršta apie delsą ir disko įrenginių naudojimą. Tai yra svarbesni parametrai, leidžiantys įvertinti, kiek mūsų diskai yra apkrauti ir kaip jie lėtai veikia. Jei turime didelę delsą, tai reiškia, kad yra problemų su diskais. Jei turime didelį išnaudojimą, tai reiškia, kad diskai nesusitvarko. Tai geresnės charakteristikos nei pralaidumas.
Be to, šią statistiką taip pat galima gauti iš /proc failų sistemos, kaip tai daroma perdirbant procesorius. Nežinau, kodėl ši informacija nėra įtraukta į stebėjimą. Tačiau vis dėlto svarbu, kad tai būtų jūsų stebėjime.
Tas pats pasakytina ir apie tinklo sąsajas. Informacija apie tinklo pralaidumą yra paketais, baitais, bet vis dėlto nėra informacijos apie delsą ir informacijos apie panaudojimą, nors tai irgi naudinga informacija.
Bet koks stebėjimas turi trūkumų. Ir nesvarbu, kokio stebėjimo imsitės, jis visada neatitiks kai kurių kriterijų. Tačiau vis dėlto jie tobulėja, pridedamos naujos funkcijos ir nauji dalykai, todėl pasirinkite ką nors ir užbaikite.
O norėdami užbaigti, visada turite žinoti, ką reiškia pateikta statistika ir kaip galite ją panaudoti sprendžiant problemas.
Ir keli pagrindiniai punktai:
- Visada turėtumėte stebėti pasiekiamumą ir turėti informacijos suvestines, kad galėtumėte greitai įvertinti, ar viskas tvarkoje su duomenų baze.
- Jūs visada turite žinoti, kokie klientai dirba su jūsų duomenų baze, kad pašalintumėte blogus klientus ir juos numuštumėte.
- Svarbu įvertinti, kaip šie klientai dirba su duomenimis. Turite turėti idėją apie savo darbo krūvį.
- Svarbu įvertinti, kaip susidaro šis darbo krūvis, kokių užklausų pagalba. Galite įvertinti užklausas, galite jas optimizuoti, pertvarkyti, kurti joms indeksus. Tai labai svarbu.
- Fono procesai gali neigiamai paveikti klientų užklausas, todėl svarbu stebėti, ar jie nenaudoja per daug išteklių.
- Sistemos metrika leidžia planuoti serverių mastelio keitimo ir pajėgumo didinimą, todėl svarbu juos stebėti ir įvertinti.
Jei jus domina ši tema, galite sekti šias nuorodas.
– tai oficialus statistikos rinkėjo dokumentas. Yra visų statistinių rodinių aprašymas ir visų laukų aprašymas. Galite juos skaityti, suprasti ir analizuoti. Remdamiesi jais sukurkite savo grafikus ir pridėkite juos prie stebėjimo.
Prašymo pavyzdžiai:
Tai yra mūsų ir mano įmonės saugykla. Juose yra užklausų pavyzdžiai. Ten nėra užklausų iš pasirinkimo* iš serijų. Jau yra paruoštų užklausų su sujungimais, naudojant įdomias funkcijas, kurios leidžia neapdorotus skaičius paversti skaitomomis, patogiomis reikšmėmis, ty tai yra baitai, laikas. Galite juos pasiimti, žiūrėti, analizuoti, įtraukti į stebėjimą, remdamiesi jais kurti stebėjimą.
Klausimai
Klausimas: Sakėte, kad prekių ženklų nereklamuosite, bet man vis tiek įdomu – kokias prietaisų skydelius naudojate savo projektuose?
Atsakymas: Tai skiriasi. Būna, kad ateiname pas klientą ir jis jau turi savo stebėjimą. Ir mes patariame klientui, ką reikia pridėti prie jo stebėjimo. Blogiausia situacija yra su Zabbix. Nes ji neturi galimybės sudaryti TopN grafikų. Mes patys naudojame , nes konsultavomės su šiais vaikinais dėl stebėjimo. Jie stebėjo PostgreSQL pagal mūsų technines specifikacijas. Rašau savo augintinio projektą, kuris renka duomenis per „Prometheus“ ir pateikia juos . Mano užduotis yra sukurti savo eksportuotoją „Prometheus“, o tada viską pateikti „Grafana“.
Klausimas: Ar yra AWR ataskaitų analogų ar... sumavimo? Ar žinote apie kažką panašaus?
Atsakymas: Taip, aš žinau, kas yra AWR, tai šaunus dalykas. Šiuo metu yra įvairių dviračių, kurie įgyvendina maždaug tokį modelį. Tam tikru laiko intervalu kai kurios pagrindinės linijos įrašomos į tą patį PostgreSQL arba į atskirą saugyklą. Galite juos paieškoti internete internete, jie yra. Vienas iš tokio dalyko kūrėjų sėdi sql.ru forume PostgreSQL gijoje. Ten galite jį sugauti. Taip, tokių dalykų yra, juos galima panaudoti. Pliusas jame Taip pat rašau dalyką, kuris leidžia jums padaryti tą patį.
PS1 Jei naudojate postgres_exporter, kokią prietaisų skydelį naudojate? Jų yra keletas. Jie jau pasenę. Gal bendruomenė sukurs atnaujintą šabloną?
PS2 pašalintas pganalyze, nes tai yra patentuotas SaaS pasiūlymas, kuriame pagrindinis dėmesys skiriamas našumo stebėjimui ir automatiniams derinimo pasiūlymams.
Apklausoje gali dalyvauti tik registruoti vartotojai. , Prašau.
Kuris savarankiškai priglobtas postgresql stebėjimas (su prietaisų skydeliu), jūsų nuomone, yra geriausias?
-
30,0%Zabbix + papildymai iš Aleksejaus Lesovskio arba zabbix 4.4 arba 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 yra patentuota SaaS – negaliu jos ištrinti1
-
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
Balsavo 10 vartotojų. 26 vartotojai susilaikė.
Šaltinis: www.habr.com