Suosittelen, että tutustut Data Egretin Alexey Lesovskyn raportin "PostgreSQL-valvonnan perusteet" transkriptioon.
Tässä raportissa Aleksei Lesovski puhuu postgres-tilastojen avainkohdista, mitä ne tarkoittavat ja miksi ne pitäisi sisällyttää seurantaan; siitä, mitä kaavioita pitäisi olla seurannassa, miten niitä lisätään ja miten niitä tulkitaan. Raportti on hyödyllinen tietokannan ylläpitäjille, järjestelmänvalvojille ja kehittäjille, jotka ovat kiinnostuneita Postgres-vianmäärityksestä.
Nimeni on Alexey Lesovsky, edustan Data Egretiä.
Muutama sana itsestäni. Aloitin kauan sitten järjestelmänvalvojana.
Hallinnoin kaikenlaista Linuxia, tein erilaisia Linuxiin liittyviä asioita, eli virtualisointia, valvontaa, työskentelin välityspalvelinten kanssa jne. Mutta jossain vaiheessa tulin enemmän mukaan tietokantoihin, PostgreSQL:ään. Pidin hänestä todella. Ja jossain vaiheessa aloin käsitellä PostgreSQL:ää suurimman osan työajastani. Ja niin vähitellen minusta tuli PostgreSQL DBA.
Ja koko urani ajan olen aina ollut kiinnostunut tilastoista, seurannasta ja telemetriasta. Ja kun olin järjestelmänvalvoja, työskentelin kovasti Zabbixin parissa. Ja kirjoitti pienen joukon käsikirjoituksia, kuten . Hän oli aikansa suosittu. Ja siellä oli mahdollista seurata hyvin erilaisia tärkeitä asioita, ei vain Linuxia, vaan myös erilaisia komponentteja.
Nyt teen jo PostgreSQL:ää. Kirjoitan jo toista asiaa, jonka avulla voit työskennellä PostgreSQL-tilastojen kanssa. Sitä kutsutaan (artikkeli Habrésta - ).
Pieni johdanto. Mitkä ovat tilanteet asiakkaidemme, asiakkaidemme kanssa? Tietokantaan liittyy jonkinlainen onnettomuus. Ja kun tietokanta on jo palautettu, tulee osastopäällikkö tai kehityspäällikkö ja sanoo: "Ystävät, meidän pitäisi valvoa tietokantaa, koska jotain pahaa tapahtui ja on välttämätöntä, että näin ei tapahdu jatkossa." Ja tästä alkaa mielenkiintoinen prosessi, jossa valitaan valvontajärjestelmä tai mukautetaan olemassa oleva valvontajärjestelmä niin, että voit valvoa tietokantaasi - PostgreSQL, MySQL tai joitain muita. Ja kollegat alkavat tarjota: "Kuulin, että on olemassa sellainen ja sellainen tietokanta. Käytetään sitä." Kollegat alkavat riidellä keskenään. Ja lopulta käy ilmi, että valitsemme jonkinlaisen tietokannan, mutta PostgreSQL-seuranta on siinä melko huonosti edustettuna ja meidän on aina tehtävä jotain loppuun. Ota arkistot GitHubista, kloonaa ne, mukauta komentosarjoja, viritä niitä jotenkin. Ja lopulta se putoaa jonkinlaiseen manuaaliseen työhön.
Siksi yritän tässä raportissa antaa sinulle tietoa siitä, kuinka valita seuranta ei vain PostgreSQL:lle vaan myös tietokannalle. Ja antaa tietoa, jonka avulla voit lopettaa seurantasi saadaksesi siitä jonkin verran hyötyä, jotta voit seurata tietokantaasi hyödyllisesti, jotta vältytään ajoissa mahdollisesti syntyviltä hätätilanteilta.
Ja ne ideat, jotka ovat tässä raportissa, ne voidaan mukauttaa suoraan mihin tahansa tietokantaan, oli se sitten DBMS tai noSQL. Siksi ei vain PostgreSQL täällä, vaan siellä on monia reseptejä kuinka tämä tehdään PostgreSQL:ssä. Siellä on esimerkkejä kyselyistä, esimerkkejä entiteeteistä, joita PostgreSQL voi valvoa. Ja jos DBMS-järjestelmässäsi on samat asiat, joiden avulla voit laittaa ne valvontaan, voit myös muokata niitä, lisätä ne ja se on hyvä.
En raportoi
puhua mittareiden toimittamisesta ja tallentamisesta. En sano mitään tietojen jälkikäsittelystä ja niiden toimittamisesta käyttäjälle. Enkä sano mitään hälytyksestä.
Mutta tarinan aikana näytän erilaisia kuvakaappauksia olemassa olevista monitoroinneista, jotenkin kritisoin niitä. Yritän kuitenkin olla nimeämättä brändejä, jotta en luo mainoksia tai anti-mainoksia näille tuotteille. Siksi kaikki sattumat ovat satunnaisia ja jäävät mielikuvituksesi varaan.
Ensin on ymmärrettävä, mitä valvonta on. Seuranta on erittäin tärkeä asia. Jokainen ymmärtää tämän. Mutta samalla seuranta ei liity yritystuotteeseen eikä vaikuta suoraan yrityksen tulokseen, joten seurantaan annetaan aina aikaa jäännöspohjalta. Jos meillä on aikaa, olemme mukana seurannassa, jos ei ole aikaa, niin OK, laitamme sen ruuhkaan ja joskus palaamme näihin tehtäviin.
Siksi käytäntömme mukaan, kun tulemme asiakkaisiin, seuranta on usein alikehittynyttä eikä siinä ole mitään mielenkiintoista, mikä auttaisi meitä tekemään parempaa työtä tietokannan kanssa. Ja siksi seuranta on aina lopetettava.
Tietokannat ovat niin monimutkaisia asioita, joita sinun on myös seurattava, koska tietokannat ovat tietovarasto. Ja tieto on yritykselle erittäin tärkeää, sitä ei voi hukata millään tavalla. Mutta samalla tietokannat ovat hyvin monimutkaisia ohjelmistoja. Ne koostuvat monista komponenteista. Ja monia näistä komponenteista on seurattava.
Jos puhumme nimenomaan PostgreSQL:stä, se voidaan esittää sellaisena järjestelmänä, joka koostuu suuresta määrästä komponentteja. Nämä komponentit ovat vuorovaikutuksessa toistensa kanssa. Ja samaan aikaan PostgreSQL:ssä on ns. Stats Collector -alijärjestelmä, jonka avulla voit kerätä tilastoja näiden alijärjestelmien toiminnasta ja tarjota käyttöliittymän ylläpitäjälle tai käyttäjälle, jotta hän voi tarkastella näitä tilastoja.
Nämä tilastot esitetään joidenkin funktioiden ja näkymien muodossa (näkymä). Niitä voidaan kutsua myös pöydiksi. Toisin sanoen tavallisella psql-asiakasohjelmalla voit muodostaa yhteyden tietokantaan, valita nämä toiminnot ja näkymät sekä saada tiettyjä numeroita PostgreSQL-alijärjestelmien toiminnasta.
Voit lisätä nämä numerot suosikkiseurantajärjestelmääsi, piirtää kaavioita, lisätä ominaisuuksia ja saada analytiikkaa pitkällä aikavälillä.
Mutta tässä raportissa en käsittele kaikkia näitä toimintoja poikkeuksetta, koska siihen voi mennä koko päivä. Viittaan kirjaimellisesti kahteen, kolmeen tai neljään asiaan ja kerron, kuinka ne auttavat parantamaan seurantaa.
Ja jos puhumme tietokannan valvonnasta, mitä on seurattava? Ensinnäkin meidän on valvottava saatavuutta, koska tietokanta on palvelu, joka tarjoaa asiakkaille pääsyn tietoihin, ja meidän on valvottava saatavuutta ja annettava myös joitakin sen laadullisia ja määrällisiä ominaisuuksia.
Meidän on myös valvottava tietokantaamme yhdistäviä asiakkaita, koska ne voivat olla sekä tavallisia asiakkaita että haitallisia asiakkaita, jotka voivat vahingoittaa tietokantaa. Niitä on myös seurattava ja seurattava.
Kun asiakkaat muodostavat yhteyden tietokantaan, on selvää, että he alkavat työskennellä tietojemme kanssa, joten meidän on seurattava, kuinka asiakkaat työskentelevät tietojen kanssa: millä taulukoilla, vähemmässä määrin millä indekseillä. Eli meidän on arvioitava asiakkaidemme luoma työmäärä.
Mutta työtaakka koostuu tietysti myös pyynnöistä. Sovellukset muodostavat yhteyden tietokantaan, pääsevät tietoihin kyselyjen avulla, joten on tärkeää arvioida, mitä kyselyitä meillä on tietokannassa, valvoa niiden riittävyyttä, että ne eivät ole vääristyneitä, että jotkut vaihtoehdot on kirjoitettava uudelleen ja tehtävä niin, että ne toimivat nopeammin ja paremmalla suorituskyvyllä.
Ja koska puhumme tietokannasta, tietokanta on aina taustaprosesseja. Taustaprosessit pitävät tietokannan suorituskyvyn hyvällä tasolla, joten ne vaativat tietyn määrän resursseja toimiakseen. Ja samalla ne voivat olla päällekkäisiä asiakaspyyntöresurssien kanssa, joten taustaprosessien ahne työ voi vaikuttaa suoraan asiakaspyyntöjen suorituskykyyn. Siksi niitä on myös seurattava ja seurattava, jotta taustaprosessit eivät vääristy.
Ja siinä kaikki tietokannan valvonnan kannalta, joka pysyy järjestelmämetriikassa. Mutta koska suurin osa koko infrastruktuuristamme menee pilviin, yksittäisen isännän järjestelmämittarit häipyvät aina taustalle. Mutta tietokannoissa ne ovat edelleen relevantteja, ja tietysti on myös tarpeen seurata järjestelmän mittareita.
Järjestelmämittareilla kaikki on enemmän tai vähemmän hyvin, kaikki nykyaikaiset valvontajärjestelmät tukevat jo näitä mittareita, mutta yleisesti ottaen jotkut komponentit eivät vielä riitä ja joitain asioita on lisättävä. Kosketan myös niitä, niistä tulee useita dioja.
Suunnitelman ensimmäinen kohta on saavutettavuus. Mitä saavutettavuus on? Käytettävyys käsittääkseni tukikohdan kykyä palvella yhteyksiä, eli kantaa nostetaan, se ottaa palveluna vastaan yhteyksiä asiakkailta. Ja tätä saavutettavuutta voidaan arvioida joidenkin ominaisuuksien perusteella. Nämä ominaisuudet on erittäin kätevä näyttää kojelaudoissa.
Kaikki tietävät, mitä kojelaudat ovat. Tällä kertaa katsoit näyttöä, joka tiivisti tarvittavat tiedot. Ja voit jo heti määrittää, onko tietokannassa ongelma vai ei.
Näin ollen tietokannan saatavuus ja muut keskeiset ominaisuudet tulisi aina laittaa kojetauluille, jotta nämä tiedot ovat käsillä, aina mukanasi. Joitakin lisäyksityiskohtia, jotka auttavat jo tapausten tutkinnassa, joidenkin hätätilanteiden tutkinnassa, ne täytyy jo sijoittaa toissijaisille kojelaudoille tai piilottaa porauslinkkeihin, jotka johtavat kolmannen osapuolen valvontajärjestelmiin.
Esimerkki yhdestä tunnetusta valvontajärjestelmästä. Tämä on erittäin siisti valvontajärjestelmä. Se kerää paljon tietoa, mutta minun näkökulmastani sillä on outo käsite kojelaudoista. Siellä on linkki "Luo hallintapaneeli". Mutta kun luot kojelaudan, luot kaksisarakkeen luettelon, luettelon kaavioista. Ja kun sinun täytyy katsoa jotain, alat klikata, rullata ja etsiä haluttua kaaviota hiirellä. Ja tämä vie aikaa, eli kojelautaa ei ole sellaisenaan. On vain luetteloita kaavioista.
Mitä näihin kojetauluihin pitäisi lisätä? Voit aloittaa sellaisella ominaisuudella kuin vasteaika. PostgreSQL:llä on pg_stat_statements-näkymä. Se on oletuksena pois käytöstä, mutta se on yksi tärkeimmistä järjestelmänäkymistä, joka tulee aina olla käytössä ja käyttää. Se tallentaa tiedot kaikista käynnissä olevista kyselyistä, jotka suoritettiin tietokantaan.
Vastaavasti voimme aloittaa siitä, että voimme ottaa kaikkien pyyntöjen kokonaissuoritusajan ja jakaa pyyntöjen lukumäärällä yllä olevia kenttiä käyttämällä. Mutta tämä on niin keskilämpötila sairaalassa. Voimme rakentaa muille kentälle - minimikyselyn suoritusaika, maksimi ja mediaani. Ja voimme jopa rakentaa prosenttipisteitä, PostgreSQL:llä on vastaavat toiminnot tätä varten. Ja voimme saada joitain numeroita, jotka kuvaavat tietokantaamme vastausaikaa jo suoritetuille pyynnöille, eli emme suorita väärennettyä 'select 1' -pyyntöä ja seuraa vastausaikaa, vaan analysoimme jo suoritettujen pyyntöjen vastausajan ja arvomme jommankumman erillinen kuvio tai rakennamme sen perusteella graafin.
On myös tärkeää seurata järjestelmän parhaillaan aiheuttamien virheiden määrää. Ja tähän voit käyttää pg_stat_tietokantanäkymää. Kohdistamme xact_rollback-kenttään. Tämä kenttä ei ainoastaan näytä tietokannassa tapahtuvien palautusten määrää, vaan se ottaa huomioon myös virheiden määrän. Suhteellisesti sanottuna voimme näyttää tämän luvun kojelaudassamme ja nähdä kuinka monta virhettä meillä on tällä hetkellä. Jos virheitä on paljon, niin tämä on jo hyvä syy tutkia lokeja ja katsoa, millaisia virheitä ne ovat ja miksi niitä esiintyy, ja sitten investoida ja ratkaista ne.
Voit lisätä sellaisen asian kuin kierroslukumittari. Nämä ovat tapahtumien määrä sekunnissa ja pyyntöjen määrä sekunnissa. Suhteellisesti sanottuna voit käyttää näitä lukuja tietokantasi nykyisenä suorituskyvynä ja tarkkailla, onko pyyntöissä huippuja, tapahtumissa huippuja tai päinvastoin, tietokanta on alikuormitettu, koska jonkinlainen taustaohjelma on katkennut. On tärkeää katsoa aina tätä lukua ja muistaa, että meidän projektissamme tällainen suorituskyky on normaali, ja ylä- ja alapuolella olevat arvot ovat jo jotenkin ongelmallisia ja käsittämättömiä, mikä tarkoittaa, että meidän on tarkasteltava, miksi tällaiset luvut .
Tapahtumien määrän arvioimiseksi voimme jälleen viitata pg_stat_tietokantanäkymään. Voimme lisätä toimitusten määrän ja palautusten määrän saadaksemme tapahtumien määrän sekunnissa.
Kaikki ymmärtävät, että yhteen tapahtumaan mahtuu useita pyyntöjä? Siksi TPS ja QPS ovat hieman erilaisia.
Pyyntöjen määrä sekunnissa voidaan saada osoitteesta pg_stat_statements ja yksinkertaisesti laskea kaikkien suoritettujen pyyntöjen summa. On selvää, että verrataan nykyistä arvoa edelliseen, vähennetään, saadaan delta, saadaan summa.
Voit halutessasi lisätä lisämittareita, jotka auttavat myös arvioimaan tietokantaamme saatavuutta ja seuraamaan mahdollisia seisokkeja.
Yksi näistä mittareista on käytettävyys. Mutta käytettävyys PostgreSQL:ssä on hieman hankalaa. Kerron sinulle miksi. Kun PostgreSQL käynnistyy, se alkaa raportoida käyttöaikaa. Mutta jos jossain vaiheessa esimerkiksi jokin tehtävä oli käynnissä yöllä, OOM-killer tuli ja väkisin katkaisi PostgreSQL-lapsiprosessin, niin tässä tapauksessa PostgreSQL katkaisee kaikkien asiakkaiden yhteyden, nollaa sirpaloidun muistialueen ja aloittaa palautuksen viimeinen tarkistuspiste. Ja vaikka tämä tarkistuspisteestä palautuminen kestää, tietokanta ei hyväksy yhteyksiä, eli tämä tilanne voidaan arvioida seisokkiksi. Mutta tämä ei nollaa käyttöaikalaskuria, koska se ottaa huomioon postmasterin käynnistysajan ensimmäisestä hetkestä lähtien. Siksi tällaiset tilanteet voidaan ohittaa.
Sinun tulee myös seurata tyhjiötyöntekijöiden määrää. Kaikki tietävät, mikä on Autovacuum PostgreSQL:ssä? Tämä on mielenkiintoinen PostgreSQL-alijärjestelmä. Siitä on kirjoitettu monia artikkeleita, monia raportteja on tehty. Paljon keskustelua tyhjiöstä, miten sen pitäisi toimia. Monet pitävät sitä välttämättömänä pahana. Mutta se on. Tämä on jonkinlainen roskakeräin, joka puhdistaa vanhentuneet versiot riveistä, joita mikään tapahtuma ei tarvitse, ja vapauttaa tilaa taulukoissa ja indekseissä uusille riveille.
Miksi sitä pitäisi valvoa? Koska tyhjiö sattuu joskus paljon. Se kuluttaa paljon resursseja ja asiakkaiden pyynnöt alkavat kärsiä tästä.
Ja sitä tulisi seurata pg_stat_activity-näkymän kautta, josta puhun seuraavassa osiossa. Tämä näkymä näyttää nykyisen toiminnan tietokannassa. Ja tämän toiminnan avulla voimme seurata tällä hetkellä toimivien imurien määrää. Voimme valvoa tyhjiöitä ja nähdä, että jos olemme ylittäneet rajan, niin tämä on tilaisuus tarkastella PostgreSQL-asetuksia ja jotenkin optimoida tyhjiön toimintaa.
Toinen PostgreSQL:n ominaisuus on, että PostgreSQL on kyllästynyt pitkiin tapahtumiin. Varsinkin liiketoimista, jotka viipyvät pitkään ja eivät tee mitään. Nämä ovat ns. stat idle-in-transaction. Tällainen tapahtuma pitää lukot, se estää tyhjiön toiminnan. Ja seurauksena - pöydät turpoavat, niiden koko kasvaa. Ja kyselyt, jotka toimivat näiden taulukoiden kanssa, ne alkavat toimia hitaammin, koska sinun on lapioittava kaikki rivien vanhat versiot muistista levylle ja takaisin. Siksi myös pisimpien tapahtumien aikaa, kestoa ja pisimpiä tyhjiöpyyntöjä on myös seurattava. Ja jos näemme joitain prosesseja, jotka ovat olleet käynnissä hyvin pitkään, yli 10-20-30 minuuttia OLTP-kuormalla, meidän on kiinnitettävä niihin huomiota ja pakotettava ne lopettamaan tai optimoitava sovellus niin, että niitä ei kutsuta, eivätkä ne roiku niin kauan. Analyyttiselle kuormitukselle 10-20-30 minuuttia on normaalia, on myös pidempiä.
Seuraavaksi meillä on vaihtoehto yhdistettyjen asiakkaiden kanssa. Kun olemme jo muodostaneet kojelaudan ja lisänneet siihen keskeiset esteettömyysmittarit, voimme lisätä sinne myös lisätietoja yhdistetyistä asiakkaista.
Tieto yhdistetyistä asiakkaista on tärkeää, koska PostgreSQL:n näkökulmasta asiakkaita on erilaisia. On hyviä asiakkaita ja on huonoja asiakkaita.
Yksinkertainen esimerkki. Asiakkaalla tarkoitan sovellusta. Sovellus on muodostanut yhteyden tietokantaan ja alkaa välittömästi lähettää sinne pyyntöjään, tietokanta käsittelee ja suorittaa ne ja palauttaa tulokset asiakkaalle. Nämä ovat hyviä ja oikeita asiakkaita.
On tilanteita, joissa asiakas on yhteydessä, se säilyttää yhteyden, mutta ei tee mitään. Se on lepotilassa.
Mutta huonoja asiakkaita on. Esimerkiksi sama asiakas liittyi, avasi tapahtuman, teki jotain tietokannassa ja meni sitten koodiin esimerkiksi päästäkseen ulkoiseen lähteeseen tai käsitelläkseen siellä vastaanotettuja tietoja. Mutta samaan aikaan hän ei päättänyt kauppaa. Ja tapahtuma roikkuu tietokannassa ja pitää lukon linjassa. Tämä on huono tila. Ja jos sovellus jossain sen sisällä yhtäkkiä putoaa poikkeuksen (Poikkeus) takia, tapahtuma voi pysyä auki erittäin pitkään. Ja tämä vaikuttaa suoraan PostgreSQL:n suorituskykyyn. PostgreSQL toimii hitaammin. Siksi on tärkeää seurata tällaisia asiakkaita ajoissa ja lopettaa heidän työnsä väkisin. Ja sinun on optimoitava sovelluksesi niin, ettei tällaisia tilanteita esiinny.
Muut huonot asiakkaat odottavat asiakkaita. Mutta niistä tulee huonoja olosuhteiden vuoksi. Esimerkiksi yksinkertainen tyhjäkäyntitapahtuma: se voi avata tapahtuman, ottaa lukot joillekin riveille, sitten se putoaa jonnekin koodiin jättäen roikkuvan tapahtuman. Tulee toinen asiakas, joka pyytää samoja tietoja, mutta kohtaa lukon, koska siinä roikkuvassa tapahtumassa on jo lukkoja joillakin tarvittavilla riveillä. Ja toinen tapahtuma jää odottamaan, kun ensimmäinen tapahtuma on suoritettu tai sen ylläpitäjä sulkee sen väkisin. Siten odottavat tapahtumat voivat kerääntyä ja ylittää tietokantayhteysrajan. Ja kun raja on täynnä, sovellus ei voi enää toimia tietokannan kanssa. Tämä on jo hankkeen hätätilanne. Siksi huonoja asiakkaita on seurattava ja niihin on vastattava ajoissa.
Toinen esimerkki valvonnasta. Ja tässä on kunnollinen kojelauta. Ylhäältä löytyy tietoa kytkennöistä. DB-liitäntä - 8 kpl. Ja se on kaikki. Meillä ei ole tietoa siitä, mitkä asiakkaat ovat aktiivisia, mitkä asiakkaat ovat vain toimettomia tekemättä mitään. Riippuvista tapahtumista ja vireillä olevista yhteyksistä ei ole tietoa, eli tämä on sellainen luku, joka näyttää yhteyksien määrän ja siinä se. Ja sitten arvaa itse.
Näin ollen, jotta voit lisätä nämä tiedot valvontaan, sinun on viitattava pg_stat_activity-järjestelmänäkymään. Jos vietät paljon aikaa PostgreSQL:ssä, tämä on erittäin hyvä näkymä, josta pitäisi tulla ystäväsi, koska se näyttää senhetkisen toiminnan PostgreSQL:ssä, eli mitä siinä tapahtuu. Jokaiselle prosessille on erillinen rivi, joka näyttää tiedot tästä prosessista: mistä isännästä yhteys muodostettiin, millä käyttäjällä, millä nimellä, milloin tapahtuma aloitettiin, mitä pyyntöä parhaillaan suoritetaan, mikä pyyntö suoritettiin viimeksi. Ja vastaavasti voimme arvioida asiakkaan tilan tilastokentän perusteella. Suhteellisesti sanottuna voimme ryhmitellä tämän kentän mukaan ja saada ne tilastot, jotka ovat nyt tietokannassa, ja yhteyksien lukumäärä, jotka ovat tämän tilaston kanssa tietokannassa. Ja voimme lähettää jo vastaanotetut numerot valvontaomme ja piirtää niihin kaavioita.
On myös tärkeää arvioida kaupan kesto. Olen jo sanonut, että on tärkeää arvioida tyhjiöiden kestoa, mutta myös transaktiot arvioidaan samalla tavalla. On xact_start- ja query_start-kentät. Ne osoittavat suhteellisesti tapahtuman alkamisajan ja pyynnön alkamisajan. Otamme nyt()-funktion, joka näyttää nykyisen aikaleiman, ja vähennämme tapahtuman ja pyynnön aikaleimat. Ja saamme tapahtuman keston, pyynnön keston.
Jos näemme pitkiä liiketoimia, meidän pitäisi tehdä ne jo valmiiksi. OLTP-kuormalla pitkät tapahtumat ovat jo yli 1-2-3 minuuttia. OLAP-kuormalla pitkät tapahtumat ovat normaaleja, mutta jos ne jatkuvat yli kaksi tuntia, se on myös merkki siitä, että meillä on jossain vinossa.
Kun asiakkaat ovat muodostaneet yhteyden tietokantaan, he alkavat työskennellä tietojemme kanssa. He käyttävät taulukoita ja indeksejä saadakseen tietoja taulukosta. Ja on tärkeää arvioida, kuinka asiakkaat työskentelevät näiden tietojen kanssa.
Tämä on tarpeen, jotta voimme arvioida työtaakkaamme ja karkeasti ymmärtää, mitkä taulukot meillä on "kuumeimmin". Tämä on tarpeen esimerkiksi tilanteissa, joissa haluamme sijoittaa "kuumia" pöytiä jonkinlaiselle nopealle SSD-tallennuslevylle. Esimerkiksi jotkut arkistotaulukot, joita emme ole käyttäneet pitkään aikaan, voidaan siirtää johonkin "kylmään" arkistoon, SATA-levyille ja antaa niiden asua siellä, niihin päästään tarvittaessa käsiksi.
Se on hyödyllinen myös poikkeamien havaitsemiseen julkaisujen ja käyttöönottojen jälkeen. Oletetaan, että projekti otti käyttöön uuden ominaisuuden. Lisäsimme esimerkiksi uusia toimintoja tietokannan kanssa työskentelemiseen. Ja jos rakennamme kaavioita taulukoiden käyttöä varten, voimme helposti havaita nämä poikkeamat näistä kaavioista. Voit esimerkiksi päivittää purskeita tai poistaa purskeita. Se tulee olemaan hyvin näkyvää.
On myös mahdollista havaita "kelluvien" tilastojen poikkeavuuksia. Mitä se tarkoittaa? PostgreSQL:llä on erittäin vahva ja erittäin hyvä kyselysuunnittelija. Ja kehittäjät omistavat paljon aikaa sen kehittämiseen. Miten hän toimii? Hyvien suunnitelmien rakentamiseksi PostgreSQL kerää tilastoja tietojen jakautumisesta taulukoihin tietyllä aikavälillä, tietyin väliajoin. Nämä ovat yleisimmät arvot: yksilöllisten arvojen määrä, tiedot taulukon NULL-arvosta, paljon tietoa.
Näiden tilastojen perusteella suunnittelija rakentaa useita kyselyjä, valitsee niistä optimaalisimman ja käyttää tätä kyselysuunnitelmaa kyselyn suorittamiseen ja tietojen palauttamiseen.
Ja tapahtuu, että tilastot "kelluu". Laatu- ja määrätiedot muuttuivat jotenkin taulukossa, mutta tilastoja ei kerätty. Ja laaditut suunnitelmat eivät välttämättä ole optimaalisia. Ja jos suunnitelmamme osoittautuvat kerättävän seurannan kannalta epäoptimaaliseksi, taulukoiden mukaan voimme nähdä nämä poikkeamat. Esimerkiksi jossain data muuttui laadullisesti ja indeksin sijaan alettiin käyttää peräkkäistä taulukon läpikulkua, ts. jos kyselyn on palautettava vain 100 riviä (raja on 100), tälle kyselylle suoritetaan täydellinen luettelointi. Ja tällä on aina erittäin huono vaikutus suorituskykyyn.
Ja sen näemme seurannassa. Ja katso jo tätä kyselyä, suorita selitys sille, kerää tilastoja, rakenna uusi lisäindeksi. Ja vastata jo tähän ongelmaan. Siksi se on tärkeää.
Toinen esimerkki valvonnasta. Luulen, että monet ihmiset tunnistavat hänet, koska hän on erittäin suosittu. Kuka käyttää projekteissaan ? Ja kuka käyttää tätä tuotetta yhdessä Prometheuksen kanssa? Tosiasia on, että tämän seurannan vakiovarastossa on kojelauta PostgreSQL:n kanssa työskentelemiseen - Prometheus. Mutta tässä on yksi huono yksityiskohta.
Kaavioita on useita. Ja tavut määritellään yksikkönä, eli kaavioita on 5. Nämä ovat Lisää tiedot, Päivitä tiedot, Poista tiedot, Hae tiedot ja Palauta tiedot. Tavut määritetään yksikön dimensioksi. Mutta tosiasia on, että PostgreSQL:n tilastot palauttavat tiedot monikkona (riveinä). Ja vastaavasti nämä kaaviot ovat erittäin hyvä tapa aliarvioida työmääräsi useita kertoja, kymmeniä kertoja, koska monikko ei ole tavu, monikko on merkkijono, siinä on paljon tavuja ja sen pituus on aina muuttuva. Toisin sanoen työkuorman laskeminen tavuina monikoiden avulla on epärealistinen tai erittäin vaikea tehtävä. Siksi, kun käytät kojelautaa tai sisäänrakennettua valvontaa, on aina tärkeää ymmärtää, että se toimii oikein ja palauttaa sinulle oikein arvioidut tiedot.
Kuinka saada tilastoja näistä taulukoista? Tätä varten PostgreSQL:llä on näkemysperhe. Ja päänäkymä on . User_tables - tämä tarkoittaa, että taulukot luodaan käyttäjän puolesta. Sitä vastoin on järjestelmänäkymiä, joita PostgreSQL itse käyttää. Ja siellä on yhteenvetotaulukko Alltables, joka sisältää sekä järjestelmän että käyttäjän. Voit aloittaa mistä tahansa niistä, joista pidät eniten.
Yllä olevia kenttiä voidaan käyttää lisäysten, päivitysten ja poistojen määrän arvioimiseen. Käyttämäni esimerkkimittaristo käyttää näitä kenttiä työtaakan ominaisuuksien arvioimiseen. Siksi voimme myös rakentaa niiden varaan. Mutta on syytä muistaa, että nämä ovat monikoita, eivät tavuja, joten emme voi ottaa sitä tavuiksi.
Näiden tietojen perusteella voimme rakentaa ns. TopN-taulukot. Esimerkiksi Top-5, Top-10. Ja voit seurata niitä kuumia pöytiä, joita käytetään muita enemmän. Esimerkiksi 5 "kuumaa" taulukkoa lisättäväksi. Ja näiden TopN-taulukoiden mukaan arvioimme työkuormitamme ja voimme arvioida työkuormituspurskeita julkaisujen ja päivitysten sekä käyttöönottojen jälkeen.
On myös tärkeää arvioida taulukon kokoa, koska joskus kehittäjät ottavat käyttöön uuden ominaisuuden ja taulukomme alkavat turvota suurissa koossa, koska he päättivät lisätä ylimääräistä datamäärää, mutta eivät ennustaneet, miten tämä tapahtuisi. vaikuttaa tietokannan kokoon. Tällaiset tapaukset tulevat myös meille yllätyksenä.
Ja nyt pieni kysymys sinulle. Mikä on kysymys, kun huomaat tietokantapalvelimen kuormituksen? Mikä on seuraava kysymyksesi?
Mutta varsinainen kysymys on seuraava. Mitä pyyntöjä kuorma aiheuttaa? Eli ei ole mielenkiintoista seurata kuorman aiheuttamia prosesseja. On selvää, että jos isäntä on tietokannan kanssa, tietokanta on siellä käynnissä ja on selvää, että vain tietokannat hävitetään siellä. Jos avaamme Topin, näemme siellä luettelon PostgreSQL-prosesseista, jotka tekevät jotain. Ylhäältä ei tule selvää, mitä he tekevät.
Vastaavasti sinun on löydettävä ne kyselyt, jotka aiheuttavat eniten kuormitusta, koska kyselyjen viritys tuottaa yleensä enemmän voittoa kuin PostgreSQL-konfigurointi tai käyttöjärjestelmän viritys tai jopa laitteiston viritys. Arvioni mukaan tämä on noin 80-85-90%. Ja tämä tehdään paljon nopeammin. Pyynnön korjaaminen on nopeampaa kuin asetusten korjaaminen, uudelleenkäynnistyksen ajoittaminen, varsinkin jos tietokantaa ei voida käynnistää uudelleen, tai laitteiston lisääminen. On helpompi kirjoittaa kysely uudelleen jonnekin tai lisätä indeksi saadaksesi paremman tuloksen tästä kyselystä.
Sen vuoksi on tarpeen seurata pyyntöjä ja niiden riittävyyttä. Otetaan toinen esimerkki valvonnasta. Ja tässäkin näyttää olevan erinomainen seuranta. Siellä on tietoa replikaatiosta, on tietoa suorituskyvystä, estämisestä, resurssien käytöstä. Kaikki on hyvin, mutta pyynnöistä ei ole tietoa. Ei ole selvää, mitkä kyselyt ovat käynnissä tietokannassamme, kuinka kauan ne ovat käynnissä, kuinka monta näistä kyselyistä. Meidän on aina oltava nämä tiedot seurannassa.
Ja saadaksemme nämä tiedot, voimme käyttää pg_stat_statements-moduulia. Sen perusteella voit rakentaa erilaisia grafiikoita. Voit esimerkiksi saada tietoa yleisimmistä pyynnöistä, eli niistä pyynnöistä, jotka suoritetaan useimmin. Kyllä, käyttöönottojen jälkeen on myös erittäin hyödyllistä tarkastella sitä ja ymmärtää, onko pyyntöjen määrä lisääntynyt.
Voit seurata pisimpiä pyyntöjä, eli niitä, joiden suorittaminen kestää pisimpään. Ne toimivat prosessorilla, ne kuluttavat I/O:ta. Voimme myös arvioida tämän kentillä total_time, mean_time, blk_write_time ja blk_read_time.
Voimme arvioida ja valvoa raskaimmat resurssien käytön pyynnöt, levyltä lukevat, muistilla toimivat tai päinvastoin jonkinlaisen kirjoituskuorman aiheuttamat pyynnöt.
Voimme arvioida anteliaimmat pyynnöt. Nämä ovat kyselyitä, jotka palauttavat suuren määrän rivejä. Se voi esimerkiksi olla jonkinlainen pyyntö, jossa he unohtivat asettaa rajan. Ja se vain palauttaa taulukon tai kyselyn koko sisällön pyydettyihin taulukoihin.
Voit myös seurata kyselyitä, jotka käyttävät väliaikaisia tiedostoja tai väliaikaisia taulukoita.
Ja meillä on edelleen taustaprosesseja. Taustaprosessit ovat ensisijaisesti tarkistuspisteitä tai niitä kutsutaan myös tarkistuspisteiksi, nämä ovat autotyhjiö ja replikointi.
Toinen esimerkki valvonnasta. Vasemmalla on Huolto-välilehti, siirry siihen ja toivottavasti näet jotain hyödyllistä. Mutta tässä on vain tyhjiön aika ja tilastojen kerääminen, ei mitään muuta. Tämä on erittäin huonoa tietoa, joten tarvitset aina tietoa siitä, miten taustaprosessit toimivat tietokannassamme ja onko niiden työssä ongelmia.
Kun tarkastelemme tarkistuspisteitä, on muistettava, että tarkistuspisteemme huuhtelevat "likaiset" sivut sirpaloidulta muistialueelta levylle ja luovat sitten tarkistuspisteen. Ja tätä tarkistuspistettä voidaan käyttää paikkana jo palautuksen aikana, jos PostgreSQL yhtäkkiä lopetettiin hätätilanteessa.
Näin ollen, jotta voit huuhdella kaikki "likaiset" sivut levylle, sinun on kirjoitettava tietty määrä. Ja yleensä järjestelmissä, joissa on paljon muistia, tämä on paljon. Ja jos teemme tarkistuspisteitä hyvin usein lyhyellä aikavälillä, levyn suorituskyky heikkenee suuresti. Ja asiakkaiden pyynnöt kärsivät resurssien puutteesta. He kilpailevat resursseista ja heillä ei ole tuottavuutta.
Näin ollen voimme valvoa esiintyvien tarkistuspisteiden määrää määritettyjen kenttien pg_stat_bgwriter-ohjelman kautta. Ja jos meillä on paljon tarkistuspisteitä tietyn ajan (10-15-20 minuuttia, puoli tuntia), esimerkiksi 3-4-5, niin tämä voi jo olla ongelma. Ja sinun on jo katsottava tietokannasta, katsottava kokoonpanosta, mikä aiheuttaa niin paljon tarkistuspisteitä. Ehkä iso levy on tulossa. Voimme jo arvioida työmäärää, koska olemme jo lisänneet työkuormituskaavioita. Voimme jo säätää keskeytyspisteparametreja ja varmistaa, että ne eivät vaikuta suuresti kyselyn suorituskykyyn.
Palaan jälleen automaattiseen tyhjiöön, koska se on sellainen asia, kuten sanoin, joka voi helposti laskea yhteen sekä levyn että kyselyn suorituskyvyn, joten on aina tärkeää mitata automaattisen tyhjiön määrä.
Autovakuumityöntekijöitä tietokannassa on rajoitettu määrä. Oletusarvoisesti niitä on kolme, joten jos meillä on kolme työntekijää koko ajan tietokannassa työssään, niin tämä tarkoittaa, että autoimurimme on alikonfiguroitu, meidän on nostettava rajoja, tarkistettava automaattisen tyhjiön asetuksia ja kiivettävä jo konfiguraatioon.
On tärkeää arvioida, ketkä tyhjiötyöntekijät työskentelevät meillä. Joko se käynnistettiin käyttäjältä, DBA tuli sisään ja laukaisi jonkinlaisen tyhjiön käsillään, ja tämä loi kuorman. Meillä on ongelma. Tai tämä on niiden tyhjiöiden lukumäärä, jotka irrottavat tapahtumalaskurin. Joillekin PostgreSQL-versioille nämä ovat erittäin raskaita tyhjiöitä. Ja ne voivat helposti lisätä suorituskykyä, koska he vähentävät koko taulukon ja skannaavat kaikki tämän taulukon lohkot.
Ja tietysti tyhjiön kesto. Jos meillä on pitkät imurit, jotka toimivat erittäin pitkään, tämä tarkoittaa, että meidän tulee jälleen kiinnittää huomiota tyhjiön kokoonpanoon ja ehkä harkita sen asetuksia uudelleen. Koska voi syntyä tilanne, kun tyhjiö toimii pöydällä pitkään (3-4 tuntia), mutta tyhjiön työskentelyn aikana taulukkoon onnistui taas kerääntymään suuri määrä kuolleita rivejä. Ja heti kun tyhjiö on ohi, hänen täytyy imuroida tämä pöytä uudelleen. Ja tulemme tilanteeseen - äärettömään tyhjiöön. Ja tässä tapauksessa tyhjiö ei selviä työstään, ja taulukot alkavat vähitellen turvota kokoaan, vaikka hyödyllisten tietojen määrä siinä pysyy samana. Siksi katsomme pitkissä tyhjiöissä aina kokoonpanoa ja yritämme optimoida sen, mutta samalla niin, että asiakkaan pyyntöjen suorituskyky ei kärsi.
Nyt ei käytännössä ole PostgreSQL-asennusta, jossa ei olisi suoratoiston replikointia. Replikointi on prosessi, jossa tietoja siirretään isäntälaitteesta replikaan.
Replikointi PostgreSQL:ssä järjestetään tapahtumalokin kautta. Isäntä luo tapahtumalokin. Verkkoyhteyden tapahtumaloki siirtyy replikaan, jonka jälkeen se toistetaan replikassa. Kaikki on yksinkertaista.
Vastaavasti pg_stat_replication-näkymää käytetään replikointiviiveen seuraamiseen. Mutta se ei ole helppoa hänelle. Versiossa 10 näkymään on tehty useita muutoksia. Ensinnäkin jotkut kentät on nimetty uudelleen. Ja joitain kenttiä on lisätty. 10. versiossa ilmestyi kenttiä, joiden avulla voit arvioida replikointiviiveen sekunneissa. Se on erittäin mukava. Ennen versiota 10 oli mahdollista arvioida replikointiviive tavuina. Tämä ominaisuus säilyi 10. versiossa, eli voit valita, mikä on sinulle kätevämpää - arvioi viive tavuina tai arvioi viive sekunneissa. Monet tekevät molempia.
Replikointiviiveen arvioimiseksi sinun on kuitenkin tiedettävä lokin sijainti tapahtumassa. Ja nämä tapahtumalokin paikat ovat vain pg_stat_replication-näkymässä. Suhteellisesti sanottuna voimme käyttää pg_xlog_location_diff()-funktiota ottamaan tapahtumalokista kaksi pistettä. Laske niiden välinen delta ja laske replikointiviive tavuina. Se on erittäin kätevä ja yksinkertainen.
Versiossa 10 tämä funktio nimettiin uudelleen muotoon pg_wal_lsn_diff(). Yleensä kaikissa toiminnoissa, näkymissä ja apuohjelmissa, joissa sana "xlog" kohdattiin, se korvattiin arvolla "wal". Tämä on sekä näkymissä että funktioissa. Tämä on sellainen innovaatio.
Lisäksi kymmenennessä versiossa lisättiin rivejä, jotka osoittavat erityisesti viiveen. Nämä ovat kirjoitusviive, huuhteluviive, toistoviive. Eli näitä asioita on tärkeää seurata. Jos näemme, että meillä on replikointiviive, meidän on tutkittava, miksi se ilmestyi, mistä se tuli, ja korjattava ongelma.
Järjestelmän mittareilla melkein kaikki on kunnossa. Kun seuranta syntyy, se alkaa järjestelmän mittareista. Tämä on prosessorien, muistin, swapin, verkon ja levyn käyttöä. Siitä huolimatta monet parametrit eivät ole siellä oletuksena.
Jos kaikki on kunnossa prosessin hävittämisessä, levyn hävittämisessä on ongelmia. Valvontakehittäjät lisäävät yleensä kaistanleveystietoja. Se voi olla iops- tai tavuissa. Mutta he unohtavat latenssin ja levylaitteiden käytön. Nämä ovat tärkeämpiä parametreja, joiden avulla voimme arvioida, kuinka kuormitettuja levymme ovat ja kuinka paljon ne hidastavat. Jos meillä on korkea latenssi, tämä tarkoittaa, että levyissä on ongelmia. Jos käyttöaste on korkea, tämä tarkoittaa, että levyt eivät kestä. Nämä ovat enemmän laadullisia ominaisuuksia kuin kaistanleveyttä.
Nämä tilastot voidaan kuitenkin saada myös /proc-tiedostojärjestelmästä, kuten prosessorien kierrätyksessä. Miksi tätä tietoa ei lisätä seurantaan, en tiedä. Mutta on silti tärkeää, että se on seurannassasi.
Sama pätee verkkoliitäntöihin. Tietoa verkon kaistanleveydestä on paketeissa, tavuissa, mutta siitä huolimatta ei ole tietoa latenssista eikä käytöstä, vaikka tämäkin on hyödyllistä tietoa.
Kaikessa seurannassa on haittapuolensa. Ja riippumatta siitä, millaista seurantaa käytät, se ei aina täytä tiettyjä kriteerejä. Mutta siitä huolimatta ne kehittyvät, uusia ominaisuuksia lisätään, uusia asioita, joten valitse jotain ja viimeistele se.
Ja jotta voit lopettaa, sinulla on aina oltava käsitys, mitä annetut tilastot tarkoittavat ja kuinka voit ratkaista ongelmia sen avulla.
Ja muutama keskeinen kohta:
- Aina pitää seurata saatavuutta, olla kojelaudat, jotta voi nopeasti arvioida, että pohjan kanssa on kaikki kunnossa.
- Sinulla on aina oltava käsitys siitä, mitkä asiakkaat työskentelevät tietokannassasi, jotta voit karsia huonot asiakkaat ja ampua heidät.
- On tärkeää arvioida, kuinka nämä asiakkaat työskentelevät datan kanssa. Sinulla on oltava käsitys työmäärästäsi.
- On tärkeää arvioida, miten tämä työmäärä muodostuu, minkä kyselyiden avulla. Voit arvioida kyselyitä, optimoida niitä, muuttaa niitä ja rakentaa indeksejä niille. Se on erittäin tärkeää.
- Taustaprosessit voivat vaikuttaa negatiivisesti asiakkaiden pyyntöihin, joten on tärkeää varmistaa, etteivät he käytä liikaa resursseja.
- Järjestelmämetriikan avulla voit tehdä suunnitelmia skaalaamiseksi, palvelimiesi kapasiteetin lisäämiseksi, joten on tärkeää seurata ja arvioida myös niitä.
Jos olet kiinnostunut tästä aiheesta, voit seurata näitä linkkejä.
on tilastojen kerääjän virallinen dokumentaatio. Siellä on kuvaus kaikista tilastonäkymistä ja kuvaus kaikista kentistä. Voit lukea, ymmärtää ja analysoida niitä. Ja niiden pohjalta rakenna omia kaavioita, lisää seurantaasi.
Pyydä esimerkkejä:
Tämä on yrityksemme ja minun omani. Heillä on näytepyyntöjä. Ei ole kyselyjä Select* from series, jotain siellä. Siellä on jo valmiita liitospyyntöjä, joissa käytetään mielenkiintoisia toimintoja, joiden avulla voit tehdä luettavia, käteviä arvoja raakaluvuista, eli nämä ovat tavuja, aikaa. Voit valita niitä, katsella niitä, analysoida niitä, lisätä ne monitoroihisi, rakentaa niiden pohjalta omia monitoreja.
kysymykset
Kysymys: Sanoit, että et mainostaisi brändejä, mutta silti ihmettelen - millaisia kojetauluja käytät projekteissasi?
Vastaus: Eri tavoin. Tapahtuu, että tulemme asiakkaan luo ja hänellä on jo oma valvonta. Ja neuvomme asiakasta, mitä hänen valvontaansa pitää lisätä. Pahin tilanne on Zabbixilla. Koska sillä ei ole kykyä rakentaa TopN-grafiikkaa. Käytämme itse koska konsultoimme näitä kavereita valvonnasta. He suorittivat PostgreSQL-valvonnan TOR-tietojemme perusteella. Kirjoitan omaa lemmikkiprojektiani, joka kerää dataa Prometheuksen kautta ja vetää sen sisään . Tehtäväni on tehdä oma viejä Prometheukseen ja piirtää sitten kaikki Grafanaan.
Kysymys: Onko olemassa analogeja AWR-raporteille tai ... aggregaatioille? Oletko tietoinen tällaisesta?
Vastaus: Kyllä, tiedän mikä AWR on, se on hieno asia. Tällä hetkellä on olemassa useita polkupyöriä, jotka toteuttavat suunnilleen seuraavan mallin. Tietyillä aikaväleillä jotkin perusviivat kirjoitetaan samaan PostgreSQL:ään tai erilliseen tallennustilaan. Voit googlettaa niitä Internetissä, ne ovat. Yksi tällaisen asian kehittäjistä istuu sql.ru-foorumilla PostgreSQL-säikeessä. Voit saada hänet kiinni sieltä. Kyllä sellaisiakin on olemassa, niitä voi käyttää. plus siinä Kirjoitan myös asian, jonka avulla voit tehdä saman.
PS1 Jos käytät postgres_exporteria, mitä hallintapaneelia käytät? Niitä on useita. Ne ovat jo vanhentuneita. Voiko yhteisö luoda päivitetyn mallin?
PS2 poistettu pganalyze, koska se on patentoitu SaaS-tarjous, joka keskittyy suorituskyvyn seurantaan ja automaattisiin viritysehdotuksiin.
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Mikä itseisännöity postgresql-seuranta (kojelaudalla) on mielestäsi paras?
-
30,0%Zabbix + lisäykset Alexey Lesovskylta tai zabbix 4.4 tai 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 on patentoitu SaaS - ei voi poistaa1
-
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
10 käyttäjää äänesti. 26 käyttäjää pidättyi äänestämästä.
Lähde: will.com