Ek stel voor dat u die transkripsie van die verslag deur Alexey Lesovsky van Data Egret "Basics of PostgreSQL Monitoring" lees
In hierdie verslag sal Alexey Lesovsky praat oor die sleutelpunte van postgres-statistieke, wat dit beteken en hoekom dit by die monitering ingesluit moet word; oor watter kaarte in monitering moet wees, hoe om dit by te voeg en hoe om te interpreteer. Die verslag sal nuttig wees vir databasisadministrateurs, stelseladministrateurs en ontwikkelaars wat belangstel in Postgres-foutsporing.
My naam is Alexey Lesovsky, ek verteenwoordig Data Egret.
'n Paar woorde oor myself. Ek het lank gelede as 'n stelseladministrateur begin.
Ek het allerhande verskillende Linux geadministreer, verskeie dinge gedoen wat met Linux verband hou, dit wil sê virtualisering, monitering, met gevolmagtigdes gewerk, ens. Maar op 'n stadium het ek meer betrokke geraak by databasisse, PostgreSQL. Ek het baie van hom gehou. En op 'n stadium het ek die meeste van my werktyd met PostgreSQL begin hanteer. En so het ek geleidelik 'n PostgreSQL DBA geword.
En regdeur my loopbaan was ek nog altyd geïnteresseerd in die onderwerpe van statistiek, monitering, telemetrie. En toe ek 'n stelseladministrateur was, het ek baie hard aan Zabbix gewerk. En het 'n klein stel skrifte geskryf soos . Hy was baie gewild in sy tyd. En daar was dit moontlik om baie verskillende belangrike dinge te monitor, nie net Linux nie, maar ook verskeie komponente.
Nou doen ek reeds PostgreSQL. Ek skryf reeds 'n ander ding wat jou toelaat om met PostgreSQL-statistieke te werk. Dit word genoem (artikel oor Habré - ).
'n Klein inleiding. Wat is die situasies met ons kliënte, met ons kliënte? Daar is 'n soort ongeluk wat verband hou met die databasis. En wanneer die databasis reeds herstel is, kom die hoof van die departement of die ontwikkelingshoof en sê: “Vriende, ons moet die databasis monitor, want iets ergs het gebeur en dit is nodig dat dit nie in die toekoms gebeur nie.” En hier begin die interessante proses om 'n moniteringstelsel te kies of 'n bestaande moniteringstelsel aan te pas sodat jy jou databasis kan monitor - PostgreSQL, MySQL of ander. En kollegas begin aanbied: “Ek het gehoor daar is so en so ’n databasis. Kom ons gebruik dit." Kollegas begin met mekaar stry. En op die ou end blyk dit dat ons 'n soort databasis kies, maar PostgreSQL-monitering is taamlik swak daarin verteenwoordig en ons moet altyd iets klaarmaak. Neem 'n paar bewaarplekke van GitHub, kloon dit, pas skrifte aan, pas dit op een of ander manier aan. En op die ou end val dit uit in een of ander handewerk.
Daarom sal ek in hierdie verslag probeer om u 'n bietjie kennis te gee oor hoe om monitering nie net vir PostgreSQL nie, maar ook vir die databasis te kies. En om die kennis te gee wat jou sal toelaat om jou monitering te voltooi om 'n bietjie voordeel daaruit te trek, sodat jy jou databasis met voordeel kan monitor om enige opkomende noodsituasies wat mettertyd mag ontstaan, te voorkom.
En daardie idees wat in hierdie verslag sal wees, hulle kan direk aangepas word by enige databasis, of dit nou 'n DBMS of noSQL is. Daarom, nie net PostgreSQL hier nie, maar daar sal baie resepte wees oor hoe om dit in PostgreSQL te doen. Daar sal voorbeelde van navrae wees, voorbeelde van entiteite wat PostgreSQL het vir monitering. En as jou DBBS dieselfde dinge het wat jou toelaat om dit in monitering te plaas, kan jy dit ook aanpas, byvoeg en dit sal goed wees.
Ek sal nie rapporteer nie
praat oor hoe om maatstawwe te lewer en te stoor. Ek sal niks sê oor die naverwerking van data en die verskaffing daarvan aan die gebruiker nie. En ek sal niks sê oor waarskuwing nie.
Maar in die loop van die storie sal ek verskillende skermskote van bestaande monitering wys, op een of ander manier sal ek hulle kritiseer. Nietemin, ek sal probeer om nie handelsmerke te noem om nie advertensies of anti-advertensies vir hierdie produkte te skep nie. Daarom is alle toevallighede lukraak en bly op jou verbeelding.
Laat ons eers verstaan wat monitering is. Monitering is 'n baie belangrike ding om te hê. Almal verstaan dit. Maar terselfdertyd hou monitering nie verband met 'n besigheidsproduk nie en beïnvloed dit nie die maatskappy se wins direk nie, dus word monitering altyd tyd gegee op 'n residuele basis. As ons tyd het, dan is ons besig met monitering, as daar nie tyd is nie, dan OK, ons sal dit in die agterstand plaas en eendag sal ons terugkeer na hierdie take.
Daarom, uit ons praktyk, wanneer ons by kliënte kom, is monitering dikwels onderontwikkel en het geen interessante dinge wat ons sal help om 'n beter werk met die databasis te doen nie. En daarom moet monitering altyd afgehandel word.
Databasisse is sulke komplekse dinge wat jy ook moet monitor, want databasisse is 'n bewaarplek van inligting. En die inligting is baie belangrik vir die maatskappy, dit kan op geen manier verlore gaan nie. Maar terselfdertyd is databasisse baie komplekse stukke sagteware. Hulle bestaan uit baie komponente. En baie van hierdie komponente moet gemonitor word.
As ons spesifiek oor PostgreSQL praat, kan dit as so 'n skema voorgestel word, wat uit 'n groot aantal komponente bestaan. Hierdie komponente is in wisselwerking met mekaar. En terselfdertyd het PostgreSQL die sogenaamde Stats Collector-substelsel, wat jou toelaat om statistieke oor die werking van hierdie substelsels in te samel en 'n koppelvlak aan die administrateur of gebruiker te verskaf sodat hy hierdie statistieke kan sien.
Hierdie statistieke word aangebied in die vorm van een of ander stel funksies en sienings (aansig). Hulle kan ook tafels genoem word. Dit wil sê, deur 'n gewone psql-kliënt te gebruik, kan u aan die databasis koppel, hierdie funksies en aansigte kies, en 'n paar spesifieke nommers kry oor die werking van PostgreSQL-substelsels.
Jy kan hierdie nommers by jou gunsteling moniteringstelsel voeg, grafieke teken, kenmerke byvoeg en op die lang termyn analise kry.
Maar in hierdie verslag sal ek nie al hierdie funksies sonder uitsondering dek nie, want dit kan 'n hele dag neem. Ek sal letterlik na twee, drie of vier dinge verwys en ek sal jou vertel hoe dit help om monitering beter te maak.
En as ons praat oor die monitering van die databasis, wat moet gemonitor word? Eerstens moet ons beskikbaarheid monitor, want die databasis is 'n diens wat toegang tot data aan kliënte bied en ons moet beskikbaarheid monitor, en ook van die kwalitatiewe en kwantitatiewe kenmerke daarvan verskaf.
Ons moet ook die kliënte monitor wat aan ons databasis koppel, want hulle kan beide normale kliënte en skadelike kliënte wees wat die databasis kan beskadig. Hulle moet ook gemonitor en opgespoor word.
Wanneer kliënte aan die databasis koppel, is dit duidelik dat hulle met ons data begin werk, daarom moet ons monitor hoe kliënte met data werk: met watter tabelle, in 'n mindere mate met watter indekse. Dit wil sê, ons moet die werklading wat deur ons kliënte geskep word, evalueer.
Maar die werklading bestaan natuurlik ook uit versoeke. Toepassings koppel aan die databasis, kry toegang tot data deur navrae te gebruik, daarom is dit belangrik om te evalueer watter navrae ons in die databasis het, hul toereikendheid te monitor, dat hulle nie skeef geskryf is nie, dat sommige opsies herskryf en gemaak moet word sodat hulle vinniger werk en met beter prestasie.
En aangesien ons oor die databasis praat, is die databasis altyd agtergrondprosesse. Agtergrondprosesse hou die databasisprestasie op 'n goeie vlak, so hulle benodig 'n sekere hoeveelheid hulpbronne vir hulself om te hardloop. En terselfdertyd kan hulle oorvleuel met kliënteversoekbronne, sodat die gulsige werk van agtergrondprosesse die prestasie van kliëntversoeke direk kan beïnvloed. Daarom moet hulle ook gemonitor en opgespoor word sodat daar geen vervormings in terme van agtergrondprosesse is nie.
En dit is alles in terme van databasismonitering bly in die stelselmetriek. Maar aangesien ons hele infrastruktuur vir die grootste deel na die wolke gaan, vervaag die stelselstatistieke van 'n individuele gasheer altyd op die agtergrond. Maar in databasisse is dit steeds relevant en dit is natuurlik ook nodig om stelselstatistieke te monitor.
Met stelselmaatstawwe is alles min of meer in orde, alle moderne moniteringstelsels ondersteun reeds hierdie maatstawwe, maar oor die algemeen is sommige komponente steeds nie genoeg nie en sommige dinge moet bygevoeg word. Ek sal ook aan hulle raak, verskeie skyfies sal daaroor handel.
Die eerste punt van die plan is toeganklikheid. Wat is toeganklikheid? Beskikbaarheid in my verstaan is die vermoë van die basis om verbindings te bedien, dit wil sê, die basis word verhoog, dit, as 'n diens, aanvaar verbindings van kliënte. En hierdie toeganklikheid kan deur sekere kenmerke beoordeel word. Hierdie eienskappe is baie gerieflik om op dashboards te vertoon.
Almal weet wat dashboards is. Dit is wanneer jy een keer na die skerm gekyk het, wat die nodige inligting opgesom het. En jy kan reeds dadelik vasstel of daar 'n probleem in die databasis is of nie.
Gevolglik moet die beskikbaarheid van die databasis en ander sleutelkenmerke altyd op dashboards geplaas word sodat hierdie inligting byderhand is, altyd by jou. Sommige bykomende besonderhede wat reeds help met die ondersoek van voorvalle, in die ondersoek van sommige noodsituasies, dit moet reeds op sekondêre dashboards geplaas word, of weggesteek word in drilldown-skakels wat na derdeparty-moniteringstelsels lei.
'n Voorbeeld van een bekende moniteringstelsel. Dit is 'n baie oulike moniteringstelsel. Dit versamel baie data, maar uit my oogpunt het dit 'n vreemde konsep van dashboards. Daar is 'n skakel "Skep Dashboard". Maar wanneer jy 'n dashboard skep, skep jy 'n twee-kolom lys, 'n lys van grafieke. En wanneer jy na iets moet kyk, begin jy klik, blaai, soek na die verlangde grafiek met die muis. En dit neem tyd, dit wil sê daar is geen dashboards as sodanig nie. Daar is slegs lyste van grafieke.
Wat moet by hierdie kontroleskerms gevoeg word? Jy kan begin met so 'n kenmerk soos reaksietyd. PostgreSQL het die pg_stat_statements-aansig. Dit is by verstek gedeaktiveer, maar dit is een van die belangrike stelselaansigte wat altyd geaktiveer en gebruik moet word. Dit stoor inligting oor alle lopende navrae wat in die databasis uitgevoer is.
Gevolglik kan ons begin met die feit dat ons die totale uitvoeringstyd van alle versoeke kan neem en deur die aantal versoeke kan deel deur die bogenoemde velde te gebruik. Maar dit is so 'n gemiddelde temperatuur in die hospitaal. Ons kan voortbou op ander velde - die minimum navraaguitvoertyd, die maksimum en die mediaan. En ons kan selfs persentiele bou, PostgreSQL het die ooreenstemmende funksies hiervoor. En ons kan 'n paar syfers kry wat die reaksietyd van ons databasis kenmerk vir reeds voltooide versoeke, dit wil sê ons voer nie die vals 'kies 1'-versoek uit en kyk na die reaksietyd nie, maar ons ontleed die reaksietyd vir reeds voltooide versoeke en teken óf 'n aparte figuur, of ons bou 'n grafiek op grond daarvan.
Dit is ook belangrik om tred te hou met die aantal foute wat die stelsel tans genereer. En hiervoor kan jy die pg_stat_database-aansig gebruik. Ons teiken die xact_rollback-veld. Hierdie veld wys nie net die aantal terugskrywings wat in die databasis voorkom nie, maar neem ook die aantal foute in ag. Relatief gesproke kan ons hierdie syfer in ons dashboard vertoon en sien hoeveel foute ons op die oomblik het. As daar baie foute is, dan is dit reeds 'n goeie rede om na die logs te kyk en te sien watter soort foute dit is en hoekom dit voorkom, en dan te belê en dit op te los.
Jy kan iets soos 'n Toerenteller byvoeg. Dit is die aantal transaksies per sekonde en die aantal versoeke per sekonde. Relatief gesproke kan jy hierdie nommers as die huidige prestasie van jou databasis gebruik en waarneem of daar pieke in versoeke, pieke in transaksies is, of omgekeerd, die databasis is onderlaai omdat 'n soort backend afgeval het. Dit is belangrik om altyd na hierdie syfer te kyk en te onthou dat so 'n prestasie normaal is vir ons projek, en die waardes hierbo en onder is reeds 'n soort problematies en onverstaanbaar, wat beteken dat ons moet kyk hoekom sulke getalle .
Om die aantal transaksies te skat, kan ons weer na die pg_stat_database-aansig verwys. Ons kan die aantal commits en die aantal terugskrywings byvoeg om die aantal transaksies per sekonde te kry.
Almal verstaan dat verskeie versoeke in een transaksie kan inpas? Daarom verskil TPS en QPS effens.
Die aantal versoeke per sekonde kan verkry word vanaf pg_stat_statements en bereken eenvoudig die som van alle uitgevoer versoeke. Dit is duidelik dat ons die huidige waarde met die vorige vergelyk, trek af, kry die delta, kry die bedrag.
Jy kan bykomende maatstawwe byvoeg as jy wil, wat ook help om die beskikbaarheid van ons databasis te assesseer en op te spoor of daar enige stilstand was.
Een van hierdie maatstawwe is uptyd. Maar uptyd in PostgreSQL is 'n bietjie moeilik. Ek sal jou vertel hoekom. Wanneer PostgreSQL begin, begin dit uptyd rapporteer. Maar as een of ander taak byvoorbeeld in die nag aan die gang was, 'n OOM-moordenaar het gekom en die PostgreSQL-kinderproses met geweld beëindig, dan beëindig PostgreSQL in hierdie geval die verbinding van alle kliënte, stel die versnipperde geheue-area terug en begin herstel vanaf die laaste kontrolepunt. En terwyl hierdie herstel van die kontrolepunt duur, aanvaar die databasis nie verbindings nie, dit wil sê, hierdie situasie kan as stilstand beoordeel word. Maar dit sal nie die optydteller terugstel nie, want dit neem die tyd in ag wat die posmeester van die eerste oomblik af begin is. Daarom kan sulke situasies oorgeslaan word.
Jy moet ook die aantal vakuumwerkers monitor. Almal weet wat is outovakuum in PostgreSQL? Dit is 'n interessante substelsel in PostgreSQL. Baie artikels is daaroor geskryf, baie verslae is gemaak. Baie besprekings oor vakuum, hoe dit moet werk. Baie beskou dit as 'n noodsaaklike euwel. Maar dit is. Dit is 'n soort vullisverwyderaar wat verouderde weergawes van rye skoonmaak wat nie deur enige van die transaksies benodig word nie en spasie in tabelle en indekse vir nuwe rye vrystel.
Hoekom moet dit gemonitor word? Want die vakuum maak soms baie seer. Dit verbruik 'n groot hoeveelheid hulpbronne en kliënteversoeke begin hierdeur ly.
En dit moet gemonitor word deur die pg_stat_activity-aansig, waaroor ek in die volgende afdeling sal praat. Hierdie aansig wys die huidige aktiwiteit in die databasis. En deur hierdie aktiwiteit kan ons die aantal stofsuiers opspoor wat tans werk. Ons kan stofsuiers monitor en sien dat as ons die limiet oorskry het, dit 'n geleentheid is om na die PostgreSQL-instellings te kyk en op een of ander manier die werking van die vakuum te optimaliseer.
Nog 'n kenmerk van PostgreSQL is dat PostgreSQL baie siek is vir lang transaksies. Veral van transaksies wat lank hang en niks doen nie. Dit is die sogenaamde stat idle-in-transaction. So 'n transaksie hou slotte, dit verhoed dat die vakuum werk. En as gevolg daarvan - die tafels swel, hulle neem toe in grootte. En navrae wat met hierdie tabelle werk, hulle begin stadiger werk, want jy moet al die ou weergawes van rye van geheue na skyf en terug skuif. Daarom moet die tyd, die duur van die langste transaksies, die langste vakuumversoeke ook gemonitor word. En as ons 'n paar prosesse sien wat vir 'n baie lang tyd aan die gang is, vir meer as 10-20-30 minute vir 'n OLTP-lading, dan moet ons daaraan aandag gee en hulle dwing om te beëindig, of die toepassing te optimaliseer sodat hulle word nie geroep nie en hang nie so lank nie. Vir 'n analitiese lading is 10-20-30 minute normaal, daar is ook langer.
Volgende het ons die opsie met gekoppelde kliënte. Wanneer ons reeds 'n kontroleskerm gevorm het en sleuteltoeganklikheidsmaatstawwe daarop geplaas het, kan ons ook bykomende inligting oor gekoppelde kliënte daar byvoeg.
Die inligting oor gekoppelde kliënte is belangrik, want vanuit die oogpunt van PostgreSQL is daar verskillende tipes kliënte. Daar is goeie kliënte en daar is slegte kliënte.
'n Eenvoudige voorbeeld. Met kliënt bedoel ek die toepassing. Die toepassing het aan die databasis gekoppel en begin dadelik sy versoeke daarheen stuur, die databasis verwerk en voer dit uit, en stuur die resultate aan die kliënt terug. Dit is goeie en regte kliënte.
Daar is situasies dat die kliënt verbind is, dit behou die verbinding, maar doen niks. Dit is in die ledige toestand.
Maar daar is slegte kliënte. Dieselfde kliënt het byvoorbeeld gekoppel, 'n transaksie oopgemaak, iets in die databasis gedoen en dan in die kode ingegaan, byvoorbeeld om toegang tot 'n eksterne bron te verkry of om die ontvangde data daar te verwerk. Maar terselfdertyd het hy nie die transaksie gesluit nie. En die transaksie hang in die databasis en hou die slot op die lyn. Dit is 'n slegte toestand. En as die toepassing êrens binne-in skielik deur 'n uitsondering val (Uitsondering), dan kan die transaksie vir 'n baie lang tyd oop bly. En dit beïnvloed die werkverrigting van PostgreSQL direk. PostgreSQL sal stadiger loop. Daarom is dit belangrik om sulke kliënte betyds op te spoor en hul werk met geweld te beëindig. En jy moet jou toepassing optimaliseer sodat daar nie sulke situasies is nie.
Ander slegte kliënte is wagtende kliënte. Maar hulle word sleg as gevolg van omstandighede. Byvoorbeeld, 'n eenvoudige ledige transaksie: dit kan 'n transaksie oopmaak, slotte op sommige lyne neem, dan sal dit iewers in die kode val, wat 'n hangende transaksie laat. 'n Ander kliënt sal kom, dieselfde data versoek, maar dit sal 'n slot teëkom, want daardie hangtransaksie het reeds slotte op 'n paar nodige rye. En die tweede transaksie sal in afwagting hang wanneer die eerste transaksie voltooi is of sy administrateur dit met geweld sluit. Dus, hangende transaksies kan die databasisverbindingslimiet ophoop en oorloop. En wanneer die limiet vol is, kan die toepassing nie meer met die databasis werk nie. Dit is reeds 'n noodsituasie vir die projek. Daarom moet slegte kliënte opgespoor word en betyds daarop gereageer word.
Nog 'n voorbeeld van monitering. En hier is 'n ordentlike dashboard. Daar is inligting oor verbindings van bo af. DB-verbinding - 8 stukke. En dit is al. Ons het geen inligting oor watter kliënte aktief is, watter kliënte net ledig is en niks doen nie. Daar is geen inligting oor hangende transaksies en hangende verbindings nie, dit wil sê dit is so 'n syfer wat die aantal verbindings toon en dit is dit. En raai dan self.
Gevolglik, om hierdie inligting by monitering te voeg, moet jy na die pg_stat_activity-stelselaansig verwys. As jy baie tyd in PostgreSQL spandeer, dan is dit 'n baie goeie siening wat jou vriend behoort te word, want dit wys die huidige aktiwiteit in PostgreSQL, dit wil sê wat daarin gebeur. Daar is 'n aparte reël vir elke proses wat inligting oor hierdie proses wys: vanaf watter gasheer die verbinding gemaak is, onder watter gebruiker, onder watter naam, wanneer die transaksie begin is, watter versoek tans uitgevoer word, watter versoek laaste uitgevoer is. En dienooreenkomstig kan ons die toestand van die kliënt evalueer deur die stat-veld. Relatief gesproke kan ons volgens hierdie veld groepeer en daardie statistieke kry wat nou in die databasis is en die aantal verbindings wat met hierdie statistiek in die databasis is. En ons kan die reeds ontvangde nommers na ons monitering stuur en grafieke daarop teken.
Dit is ook belangrik om die duur van die transaksie te evalueer. Ek het reeds gesê dat dit belangrik is om die duur van vakuums te evalueer, maar transaksies word ook op dieselfde manier geëvalueer. Daar is xact_start en query_start velde. Hulle, relatief gesproke, toon die begintyd van die transaksie en die begintyd van die versoek. Ons neem die now() funksie, wat die huidige tydstempel wys, en trek die transaksie af en versoek tydstempels. En ons kry die duur van die transaksie, die duur van die versoek.
As ons lang transaksies sien, moet ons dit reeds voltooi. Vir 'n OLTP-lading is lang transaksies reeds meer as 1-2-3 minute. Vir 'n OLAP-lading is lang transaksies normaal, maar as dit langer as twee uur duur, is dit ook 'n teken dat ons iewers 'n skeeftrek het.
Sodra die kliënte aan die databasis gekoppel het, begin hulle met ons data werk. Hulle kry toegang tot tabelle, hulle kry toegang tot indekse om data uit 'n tabel te kry. En dit is belangrik om te evalueer hoe kliënte met hierdie data werk.
Dit is nodig om ons werklading te evalueer en rofweg te verstaan watter tabelle ons die “warmste” het. Dit is byvoorbeeld nodig in situasies waar ons "warm" tafels op 'n soort vinnige SSD-berging wil plaas. Byvoorbeeld, sommige argieftabelle wat ons vir 'n lang tyd nie gebruik het nie, kan oorgedra word na 'n soort "koue" argief, na SATA-skywe en laat hulle daar woon, hulle sal verkry word soos nodig.
Dit is ook nuttig om afwykings na enige vrystellings en ontplooiings op te spoor. Kom ons sê die projek het 'n nuwe kenmerk uitgerol. Ons het byvoorbeeld nuwe funksionaliteit bygevoeg om met die databasis te werk. En as ons grafieke bou vir die gebruik van tabelle, kan ons hierdie anomalieë maklik op hierdie grafieke opspoor. Werk byvoorbeeld sarsies op of vee sarsies uit. Dit sal baie sigbaar wees.
Dit is ook moontlik om anomalieë van "gedryf" statistieke op te spoor. Wat beteken dit? PostgreSQL het 'n baie sterk en baie goeie navraagbeplanner. En die ontwikkelaars bestee baie tyd aan die ontwikkeling daarvan. Hoe werk hy? Om goeie planne te bou, versamel PostgreSQL statistieke oor die verspreiding van data in tabelle met 'n sekere tydsinterval, met 'n mate van periodisiteit. Dit is die mees algemene waardes: die aantal unieke waardes, inligting oor NULL in die tabel, baie inligting.
Op grond van hierdie statistieke bou die beplanner verskeie navrae, kies die mees optimale een en gebruik hierdie navraagplan om die navraag self uit te voer en data terug te gee.
En dit gebeur dat die statistieke "dryf". Die kwaliteit en hoeveelheid data het op een of ander manier in die tabel verander, maar die statistieke is nie ingesamel nie. En die planne wat gevorm word, is dalk nie optimaal nie. En as ons planne suboptimaal blyk te wees in terme van die monitering wat ingesamel word, sal ons volgens die tabelle hierdie afwykings kan sien. Byvoorbeeld, iewers het die data kwalitatief verander en in plaas van die indeks, het 'n opeenvolgende deurgang deur die tabel begin gebruik word, m.a.w. as die navraag slegs 100 rye moet terugstuur (daar is 'n limiet van 100), dan sal 'n volledige opsomming vir hierdie navraag gedoen word. En dit het altyd 'n baie slegte uitwerking op prestasie.
En ons kan dit in monitering sien. En kyk reeds na hierdie navraag, voer verduidelik daarvoor, versamel statistieke, bou 'n nuwe bykomende indeks. En reageer reeds op hierdie probleem. Daarom is dit belangrik.
Nog 'n voorbeeld van monitering. Ek dink baie mense herken hom omdat hy baie gewild is. Wie gebruik in hul projekte ? En wie gebruik hierdie produk saam met Prometheus? Die feit is dat daar in die standaardbewaarplek van hierdie monitering 'n dashboard is om met PostgreSQL te werk - Prometheus. Maar daar is een slegte detail hier.
Daar is verskeie kaarte. En grepe word as eenheid gespesifiseer, dit wil sê daar is 5 grafieke. Dit is Voeg data in, Dateer data op, Vee data uit, Haal data en Gee data terug. Bytes word gespesifiseer as die eenheidsdimensie. Maar die feit is dat statistieke in PostgreSQL data in tuple (rye) gee. En dienooreenkomstig is hierdie grafieke 'n baie goeie manier om jou werklading verskeie kere, dosyne kere te onderskat, want 'n tupel is nie 'n greep nie, 'n tupel is 'n string, dit is baie grepe en dit is altyd van veranderlike lengte. Dit wil sê, die berekening van die werklading in grepe met behulp van tupels is 'n onrealistiese taak of 'n baie moeilike een. Daarom, wanneer jy 'n dashboard of ingeboude monitering gebruik, is dit altyd belangrik om te verstaan dat dit korrek werk en korrek geëvalueerde data aan jou terugstuur.
Hoe om statistieke oor hierdie tabelle te kry? Om dit te doen, het PostgreSQL 'n familie van sienings. En die hoofaansig is . User_tables - dit beteken dat die tabelle namens die gebruiker geskep word. Daarteenoor is daar stelselaansigte wat deur PostgreSQL self gebruik word. En daar is 'n opsommingstabel Alltables, wat beide stelsel en gebruiker insluit. Jy kan begin by enige van hulle waarvan jy die meeste hou.
Die bogenoemde velde kan gebruik word om die aantal invoegings, opdaterings en verwyderings te skat. Die voorbeeld dashboard wat ek gebruik het, gebruik hierdie velde om die kenmerke van die werklading te evalueer. Daarom kan ons ook daarop voortbou. Maar dit is die moeite werd om te onthou dat dit tuples is, nie grepe nie, so ons kan dit nie neem en dit bytes maak nie.
Op grond van hierdie data kan ons die sogenaamde TopN-tabelle bou. Byvoorbeeld, Top-5, Top-10. En jy kan tred hou met daardie warm tafels wat meer as ander gebruik word. Byvoorbeeld, 5 "warm" tafels vir invoeging. En volgens hierdie TopN-tabelle, evalueer ons ons werklading en kan sarsies werklading evalueer na enige vrystellings en opdaterings, en ontplooiings.
Dit is ook belangrik om die grootte van die tabel te evalueer, want soms ontplooi ontwikkelaars 'n nuwe kenmerk, en ons tabelle begin swel in hul groot groottes, omdat hulle besluit het om 'n bykomende hoeveelheid data by te voeg, maar nie voorspel het hoe dit sou beïnvloed die grootte van die databasis. Sulke gevalle kom ook vir ons as verrassings.
En nou 'n klein vraag vir jou. Wat is die vraag wanneer jy die las op die databasisbediener sien? Wat is jou volgende vraag?
Maar die eintlike vraag is die volgende. Watter versoeke veroorsaak die vrag? Dit wil sê, dit is nie interessant om die prosesse wat die las veroorsaak, dop te hou nie. Dit is duidelik dat as gasheer met 'n databasis is, dan loop die databasis daar en dit is duidelik dat slegs databasisse daar weggedoen sal word. As ons Top oopmaak, sal ons daar 'n lys van PostgreSQL-prosesse sien wat iets doen. Van Bo sal dit nie duidelik wees wat hulle doen nie.
Gevolglik moet jy daardie navrae vind wat die meeste las veroorsaak, want navraaginstelling gee as 'n reël meer wins as PostgreSQL-konfigurasie of bedryfstelselinstelling, of selfs hardeware-instelling. Volgens my skatting is dit ongeveer 80-85-90%. En dit word baie vinniger gedoen. Dit is vinniger om die versoek reg te stel as om die konfigurasie reg te stel, 'n herbegin te skeduleer, veral as die databasis nie herbegin kan word nie, of hardeware by te voeg. Dit is makliker om die navraag iewers te herskryf of 'n indeks by te voeg om 'n beter resultaat uit hierdie navraag te kry.
Gevolglik is dit nodig om versoeke en hul toereikendheid te monitor. Kom ons neem nog 'n voorbeeld van monitering. En hier blyk ook uitstekende monitering te wees. Daar is inligting oor replikasie, daar is inligting oor deurset, blokkering, hulpbronbenutting. Alles is goed, maar daar is geen inligting oor versoeke nie. Dit is nie duidelik watter navrae in ons databasis loop nie, hoe lank dit loop, hoeveel van hierdie navrae. Ons moet altyd hierdie inligting in monitering hê.
En om hierdie inligting te kry, kan ons die pg_stat_statements-module gebruik. Op die basis daarvan kan u 'n verskeidenheid grafika bou. Byvoorbeeld, jy kan inligting kry oor die mees gereelde versoeke, dit wil sê oor daardie versoeke wat die meeste uitgevoer word. Ja, na ontplooiing is dit ook baie nuttig om daarna te kyk en te verstaan of daar enige toename in versoeke is.
Jy kan die langste navrae monitor, dit wil sê daardie navrae wat die langste loop. Hulle loop op die verwerker, hulle verbruik I/O. Ons kan dit ook evalueer deur die velde total_time, mean_time, blk_write_time en blk_read_time.
Ons kan die swaarste versoeke evalueer en monitor in terme van hulpbrongebruik, dié wat van skyf af lees, dié wat met geheue werk, of, inteendeel, ’n soort skryflading skep.
Ons kan die mees vrygewige versoeke evalueer. Dit is die navrae wat 'n groot aantal rye terugstuur. Dit kan byvoorbeeld 'n soort versoek wees waar hulle vergeet het om 'n limiet te stel. En dit gee net die hele inhoud van die tabel of navraag op die gevraagde tabelle terug.
En jy kan ook navrae monitor wat tydelike lêers of tydelike tabelle gebruik.
En ons het nog agtergrondprosesse. Agtergrondprosesse is hoofsaaklik kontrolepunte of dit word ook kontrolepunte genoem, dit is outovakuum en replikasie.
Nog 'n voorbeeld van monitering. Daar is 'n Onderhoud-oortjie aan die linkerkant, gaan daarna en hoop om iets nuttigs te sien. Maar hier, net die tyd van die vakuum en die versameling van statistieke, niks anders nie. Dit is baie swak inligting, so jy moet altyd inligting hê oor hoe agtergrondprosesse in ons databasis werk en of daar enige probleme van hul werk is.
Wanneer ons na kontrolepunte kyk, moet dit onthou word dat ons kontrolepunte "vuil" bladsye van die versnipperde geheue area na skyf spoel, en dan 'n kontrolepunt skep. En hierdie kontrolepunt kan reeds gebruik word as 'n plek tydens herstel, as PostgreSQL skielik in 'n noodgeval beëindig is.
Gevolglik, om al die "vuil" bladsye na skyf te spoel, moet jy 'n sekere hoeveelheid skryfwerk doen. En as 'n reël, op stelsels met 'n groot hoeveelheid geheue, is dit baie. En as ons baie gereeld kontrolepunte in 'n kort interval maak, sal skyfwerkverrigting baie sak. En kliënteversoeke sal ly onder 'n gebrek aan hulpbronne. Hulle sal meeding om hulpbronne en 'n gebrek aan produktiwiteit.
Gevolglik kan ons deur pg_stat_bgwriter op die gespesifiseerde velde die aantal kontrolepunte monitor wat voorkom. En as ons baie kontrolepunte het vir 'n sekere tydperk (vir 10-15-20 minute, vir 'n halfuur), byvoorbeeld 3-4-5, dan kan dit reeds 'n probleem wees. En jy moet reeds in die databasis kyk, kyk in die konfigurasie, wat so 'n oorvloed kontrolepunte veroorsaak. Miskien kom een of ander groot rekord. Ons kan reeds die werklading evalueer, want ons het reeds werkladingskaarte bygevoeg. Ons kan reeds die breekpuntparameters aanpas en seker maak dat dit nie die navraagprestasie grootliks beïnvloed nie.
Ek gaan weer terug na outovakuum, want dit is die soort ding, soos ek gesê het, wat maklik beide skyf- en navraagwerkverrigting kan optel, so dit is altyd belangrik om die hoeveelheid outovakuum te meet.
Die aantal outovakuumwerkers in die databasis is beperk. By verstek is daar drie van hulle, so as ons drie werkers het wat heeltyd in die databasis werk, dan beteken dit dat ons outovakuum onderkonfigureer is, ons moet die perke verhoog, die outovakuuminstellings hersien en reeds in die konfigurasie klim.
Dit is belangrik om te evalueer watter vakuumwerkers vir ons werk. Óf dit is van die gebruiker af geloods, die DBA het ingekom en 'n soort vakuum met sy hande geloods, en dit het 'n las geskep. Ons het 'n probleem. Of dit is die aantal stofsuiers wat die transaksieteller losdraai. Vir sommige weergawes van PostgreSQL is dit baie swaar stofsuiers. En hulle kan maklik prestasie byvoeg omdat hulle die hele tabel aftrek en al die blokke in hierdie tabel skandeer.
En natuurlik die duur van stofsuiers. As ons lang stofsuiers het wat vir 'n baie lang tyd loop, beteken dit dat ons weer aandag moet gee aan die konfigurasie van die vakuum en miskien die instellings daarvan moet heroorweeg. Omdat 'n situasie kan ontstaan wanneer die vakuum vir 'n lang tyd (3-4 uur) op die tafel werk, maar gedurende die tyd wat die vakuum gewerk het, het 'n groot hoeveelheid dooie rye weer daarin geslaag om in die tabel te versamel. En sodra die vakuum verby is, moet hy hierdie tafel weer stofsuig. En ons kom by 'n situasie - 'n oneindige vakuum. En in hierdie geval hanteer die vakuum nie sy werk nie, en begin die tabelle geleidelik in grootte swel, hoewel die hoeveelheid nuttige data daarin dieselfde bly. Daarom, in lang vakuums, kyk ons altyd na die konfigurasie en probeer om dit te optimaliseer, maar terselfdertyd, sodat die prestasie van kliëntversoeke nie ly nie.
Nou is daar feitlik geen PostgreSQL-installasie waar daar geen stroomreplikasie was nie. Replikasie is die proses om data van 'n meester na 'n replika oor te dra.
Replikasie in PostgreSQL word gereël deur 'n transaksielogboek. Die meester genereer 'n transaksielog. Die transaksielogboek op die netwerkverbinding gaan na die replika, dan word dit op die replika gereproduseer. Alles is eenvoudig.
Gevolglik word die pg_stat_replikasie-aansig gebruik om die replikasievertraging te monitor. Maar dit is nie vir haar maklik nie. In weergawe 10 het die aansig verskeie veranderinge ondergaan. Eerstens is sommige van die velde hernoem. En van die velde is bygevoeg. In die 10de weergawe het velde verskyn waarmee u die replikasievertraging in sekondes kan evalueer. Dit is baie gemaklik. Voor weergawe 10 was dit moontlik om die replikasievertraging in grepe te skat. Hierdie kenmerk het in die 10de weergawe gebly, dit wil sê jy kan kies wat vir jou geriefliker is - evalueer die vertraging in grepe of evalueer die vertraging in sekondes. Baie doen albei.
Om die replikasievertraging egter te evalueer, moet u die posisie van die logboek in die transaksie ken. En hierdie posisies van die transaksielog is net in die pg_stat_replikasie-aansig. Relatief gesproke kan ons die pg_xlog_location_diff() funksie gebruik om twee punte in die transaksielog te neem. Bereken die delta tussen hulle en kry die replikasievertraging in grepe. Dit is baie gerieflik en eenvoudig.
In weergawe 10 is hierdie funksie hernoem na pg_wal_lsn_diff(). Oor die algemeen, in alle funksies, aansigte, nutsprogramme, waar die woord "xlog" teëgekom is, is dit vervang met die waarde "wal". Dit is beide in aansigte en in funksies. Dit is so 'n innovasie.
Boonop is in die 10de weergawe lyne bygevoeg wat spesifiek die vertraging toon. Dit is skryfvertraging, spoelvertraging, herspeelvertraging. Dit wil sê, dit is belangrik om hierdie dinge te monitor. As ons sien dat ons 'n replikasievertraging het, moet ons ondersoek hoekom dit verskyn het, waar dit vandaan kom en die probleem oplos.
Met stelselstatistieke is byna alles in orde. Wanneer enige monitering gebore word, begin dit met stelselstatistieke. Dit is die gebruik van verwerkers, geheue, ruil, netwerk en skyf. Maar nietemin, baie parameters is nie by verstek daar nie.
As alles in orde is met die wegdoening van die proses, is daar probleme met die wegdoening van die skyf. As 'n reël voeg moniteringsontwikkelaars bandwydte-inligting by. Dit kan in iops of grepe wees. Maar hulle vergeet van latency en gebruik van skyftoestelle. Dit is belangriker parameters wat ons in staat stel om te evalueer hoe gelaai ons skywe is en hoeveel hulle stadiger word. As ons 'n hoë latensie het, beteken dit dat daar 'n paar probleme met die skywe is. As ons hoë benutting het, beteken dit dat die skywe nie kan hanteer nie. Dit is meer kwalitatiewe eienskappe as bandwydte.
Hierdie statistieke kan egter ook van die /proc-lêerstelsel verkry word, soos gedoen word vir verwerkersherwinning. Hoekom hierdie inligting nie by die monitering gevoeg word nie, weet ek nie. Maar dit is steeds belangrik om dit in jou monitering te hê.
Dieselfde geld vir netwerkkoppelvlakke. Daar is inligting oor netwerkbandwydte in pakkies, in grepe, maar nietemin is daar geen inligting oor latensie en geen inligting oor benutting nie, alhoewel dit ook nuttige inligting is.
Enige monitering het sy nadele. En maak nie saak watter soort monitering jy neem nie, dit sal altyd nie aan sekere kriteria voldoen nie. Maar nietemin, hulle ontwikkel, nuwe kenmerke word bygevoeg, nuwe dinge, so kies iets en voltooi dit.
En om af te handel, moet jy altyd 'n idee hê wat die gegewe statistieke beteken en hoe jy probleme daarmee kan oplos.
En 'n paar sleutelpunte:
- Jy moet altyd beskikbaarheid monitor, dashboards hê sodat jy vinnig kan assesseer dat alles in orde is met die basis.
- U moet altyd 'n idee hê van watter kliënte met u databasis werk om slegte kliënte uit te wis en hulle te skiet.
- Dit is belangrik om te evalueer hoe hierdie kliënte met data werk. Jy moet 'n idee hê oor jou werklading.
- Dit is belangrik om te evalueer hoe hierdie werklading gevorm word, met behulp van watter navrae. U kan navrae evalueer, u kan dit optimaliseer, dit herfaktoriseer, indekse daarvoor bou. Dit is baie belangrik.
- Agtergrondprosesse kan kliëntversoeke negatief beïnvloed, daarom is dit belangrik om seker te maak dat hulle nie te veel hulpbronne gebruik nie.
- Stelselstatistieke laat jou toe om planne te maak vir skaal, om die kapasiteit van jou bedieners te vergroot, so dit is belangrik om dit ook op te spoor en te evalueer.
As jy belangstel in hierdie onderwerp, dan kan jy hierdie skakels volg.
is die amptelike dokumentasie van die statistiekinsamelaar. Daar is 'n beskrywing van alle statistiese sienings en 'n beskrywing van alle velde. Jy kan dit lees, verstaan en ontleed. En op grond daarvan, bou jou eie kaarte, voeg by jou monitering.
Versoek voorbeelde:
Dit is ons korporatiewe bewaarplek en my eie. Hulle het voorbeeldversoeke. Daar is geen navrae van die kies* uit reeks nie, iets daar. Daar is reeds klaargemaakte versoeke met aansluitings, met behulp van interessante funksies wat jou toelaat om leesbare, gerieflike waardes van rou getalle te maak, dit wil sê, dit is grepe, tyd. U kan hulle kies, hulle dophou, dit ontleed, dit by u moniterings voeg, u eie moniterings op grond daarvan bou.
vrae
Vraag: Jy het gesê dat jy nie handelsmerke sal adverteer nie, maar ek wonder steeds – watter soort dashboards gebruik jy in jou projekte?
Antwoord: Op verskillende maniere. Dit gebeur dat ons na die kliënt kom en hy het reeds sy eie monitering. En ons adviseer die kliënt oor wat by sy monitering gevoeg moet word. Die ergste situasie is met Zabbix. Omdat dit nie die vermoë het om TopN-grafika te bou nie. Ons self gebruik omdat ons hierdie ouens oor monitering geraadpleeg het. Hulle het PostgreSQL-monitering gedoen op grond van ons TOR. Ek skryf my eie troeteldierprojek, wat data deur Prometheus versamel en intrek . My taak is om my eie uitvoerder in Prometheus te maak en dan alles in Grafana te teken.
Vraag: Is daar enige analoë van AWR-verslae of ... samevoegings? Is jy bewus van so iets?
Antwoord: Ja, ek weet wat AWR is, dis 'n gawe ding. Op die oomblik is daar 'n verskeidenheid fietse wat ongeveer die volgende model implementeer. Op 'n sekere tydsinterval word sommige basislyne na dieselfde PostgreSQL of na 'n aparte berging geskryf. Jy kan hulle op die internet google, hulle is. Een van die ontwikkelaars van so iets sit op die sql.ru-forum in die PostgreSQL-draad. Jy kan hom daar vang. Ja, daar is sulke goed, dit kan gebruik word. plus in sy Ek skryf ook 'n ding wat jou toelaat om dieselfde te doen.
PS1 As jy postgres_exporter gebruik, watter dashboard gebruik jy? Daar is verskeie van hulle. Hulle is reeds verouderd. Kan die gemeenskap 'n opgedateerde sjabloon skep?
PS2 verwyder pganalyze aangesien dit 'n eie SaaS-aanbieding is wat fokus op prestasiemonitering en outomatiese instelvoorstelle.
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Watter self-aangename postgresql-monitering (met dashboard) dink jy is die beste?
-
30,0%Zabbix + toevoegings van Alexey Lesovsky of zabbix 4.4 of 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 is 'n eie SaaS - kan nie delete1
-
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 gebruikers het gestem. 26 gebruikers het buite stemming gebly.
Bron: will.com