Ik stel foar dat jo it transkripsje fan it rapport lêze troch Alexey Lesovsky fan Data Egret "Fundamentals of PostgreSQL monitoring"
Yn dit rapport sil Alexey Lesovsky prate oer de kaaipunten fan post-gressstatistiken, wat se betsjutte, en wêrom't se oanwêzich wêze moatte yn tafersjoch; oer hokker grafiken moatte wêze yn 'e monitoaring, hoe't se tafoegje en hoe't se se ynterpretearje. It rapport sil nuttich wêze foar databasebehearders, systeembehearders en ûntwikkelders dy't ynteressearre binne yn Postgres-probleemoplossing.
Myn namme is Alexey Lesovsky, ik fertsjintwurdigje it bedriuw Data Egret.
In pear wurden oer mysels. Ik begon lang lyn as systeembehearder.
Ik administrearre allerhanne ferskillende Linux-systemen, wurke oan ferskate dingen dy't relatearre binne oan Linux, dus virtualisaasje, monitoring, wurke mei proxy's, ensfh Mar op in stuit begon ik mear te wurkjen mei databases, PostgreSQL. Ik mocht him echt leuk fine. En op in stuit begon ik it measte fan myn wurktiid oan PostgreSQL te wurkjen. En sa stadichoan waard ik in PostgreSQL DBA.
En yn myn karriêre haw ik altyd ynteressearre west yn 'e ûnderwerpen statistyk, tafersjoch en telemetry. En doe't ik in systeembehearder wie, wurke ik tige nau gear mei Zabbix. En ik skreau in lytse set fan skripts lykas . Hy wie frij populêr yn syn tiid. En dêr wie it mooglik om hiel ferskillende wichtige dingen te kontrolearjen, net allinich Linux, mar ek ferskate komponinten.
No wurkje ik oan PostgreSQL. Ik skriuw al in oar ding wêrmei jo kinne wurkje mei PostgreSQL-statistiken. It hjit (artikel oer Habré - ).
In lytse ynliedende notysje. Hokker situaasjes hawwe ús klanten, ús kliïnten? Der is in soarte fan ûngelok yn ferbân mei de databank. En as de databank al wer restaurearre is, komt it haad fan de ôfdieling of it haad fan ûntwikkeling en seit: "Freonen, wy moatte de databank kontrolearje, want der is wat slims bard en wy moatte foarkomme dat dit yn 'e takomst bart." En hjir begjint it nijsgjirrige proses fan it kiezen fan in tafersjochsysteem of it oanpassen fan in besteand tafersjochsysteem sadat jo jo database kinne kontrolearje - PostgreSQL, MySQL of guon oaren. En kollega's begjinne te suggerearjen: “Ik hearde dat der sa’n en sa’n databank is. Litte wy it brûke." Kollega's begjinne mei-inoar te argumintearjen. En op it lêst docht it bliken dat wy in soarte fan databank selektearje, mar PostgreSQL-monitoring wurdt der nochal min yn presintearre en wy moatte altyd wat tafoegje. Nim wat repositories fan GitHub, klonje se, oanpasse skripts en oanpasse se op ien of oare manier. En úteinlik wurdt it in soarte fan hânwurk.
Dêrom sil ik yn dit petear besykje jo wat kennis te jaan oer hoe't jo kontrôle kieze net allinich foar PostgreSQL, mar ek foar de databank. En jou jo de kennis wêrmei jo jo tafersjoch kinne foltôgje om der wat foardiel fan te krijen, sadat jo jo databank mei foardiel kinne kontrolearje, om alle oankommende needsituaasjes dy't kinne ûntstean fuortendaliks te foarkommen.
En de ideeën dy't yn dit rapport sille wêze kinne direkt wurde oanpast oan elke database, of it no in DBMS of noSQL is. Dêrom is d'r net allinich PostgreSQL, mar d'r sille in protte resepten wêze oer hoe't jo dit kinne dwaan yn PostgreSQL. D'r sille foarbylden wêze fan fragen, foarbylden fan entiteiten dy't PostgreSQL hat foar tafersjoch. En as jo DBMS deselde dingen hat wêrmei jo se yn tafersjoch kinne sette, kinne jo se ek oanpasse, tafoegje en it sil goed wêze.
Ik sil net yn it rapport stean
prate oer hoe't jo metriken leverje en opslaan. Ik sil neat sizze oer it postferwurkjen fan de gegevens en it presintearjen oan de brûker. En ik sil neat sizze oer warskôging.
Mar as it ferhaal foarútgiet, sil ik ferskate skermôfbyldings fan besteande tafersjoch sjen litte en se op ien of oare manier bekritisearje. Mar dochs sil ik besykje gjin merken te neamen om gjin reklame of anty-reklame te meitsjen foar dizze produkten. Dêrom binne alle tafallichheden willekeurich en wurde oerlitten oan jo ferbylding.
Litte wy earst útfine wat tafersjoch is. Monitoring is in heul wichtich ding om te hawwen. Elkenien begrypt dit. Mar tagelyk is tafersjoch net relatearre oan in saaklik produkt en hat gjin direkte ynfloed op de winst fan it bedriuw, sadat tiid altyd wurdt tawiisd oan tafersjoch op in residuele basis. As wy tiid hawwe, dan dogge wy tafersjoch; as wy gjin tiid hawwe, dan OK, wy sille it yn 'e efterstân sette en ienris sille wy weromkomme nei dizze taken.
Dêrom, út ús praktyk, as wy by kliïnten komme, is tafersjoch faaks net kompleet en hat gjin ynteressante dingen dy't ús soene helpe om in bettere baan te dwaan mei de database. En dêrom moat monitoaring altyd foltôge wurde.
Databanken binne sokke komplekse dingen dy't ek kontrolearre wurde moatte, om't databanken in repository fan ynformaasje binne. En ynformaasje is heul wichtich foar it bedriuw; it kin op gjin inkelde manier ferlern gean. Mar tagelyk binne databases heul komplekse stikken software. Se besteane út in grut oantal komponinten. En in protte fan dizze komponinten moatte wurde kontrolearre.
As wy it spesifyk oer PostgreSQL prate, dan kin it wurde fertsjintwurdige yn 'e foarm fan in skema dat bestiet út in grut oantal komponinten. Dizze komponinten ynteraksje mei elkoar. En tagelyk hat PostgreSQL it saneamde Stats Collector-subsysteem, wêrtroch jo statistiken kinne sammelje oer de wurking fan dizze subsystemen en in soarte fan ynterface foar de behearder of brûker leverje, sadat hy dizze statistiken besjen kin.
Dizze statistiken wurde presintearre yn 'e foarm fan in bepaalde set fan funksjes en werjeften. Se kinne ek wurde neamd tabellen. Dat is, mei in gewoane psql-kliïnt, kinne jo ferbine mei de databank, meitsje in selekt op dizze funksjes en werjeften, en krije wat spesifike nûmers oer de wurking fan de PostgreSQL subsystemen.
Jo kinne dizze nûmers tafoegje oan jo favorite tafersjochsysteem, grafiken tekenje, funksjes tafoegje en analysearje op 'e lange termyn.
Mar yn dit rapport sil ik al dizze funksjes net folslein dekke, om't it de hiele dei kin duorje. Ik sil letterlik twa, trije of fjouwer dingen oanpakke en jo fertelle hoe't se helpe om tafersjoch better te meitsjen.
En as wy prate oer databankmonitoring, wat moat dan kontrolearre wurde? Alderearst moatte wy de beskikberens kontrolearje, om't de databank in tsjinst is dy't tagong jout ta gegevens oan kliïnten en wy moatte de beskikberens kontrolearje, en ek wat fan har kwalitative en kwantitative skaaimerken leverje.
Wy moatte ek kliïnten kontrolearje dy't ferbine mei ús databank, om't se sawol normale kliïnten as skealike kliïnten kinne wêze dy't de databank skea kinne. Se moatte ek wurde kontrolearre en har aktiviteiten wurde folge.
As kliïnten ferbine mei de databank, is it dúdlik dat se begjinne te wurkjen mei ús gegevens, dus moatte wy kontrolearje hoe't kliïnten wurkje mei de gegevens: mei hokker tabellen, en yn mindere mjitte, mei hokker yndeksen. Dat is, wy moatte de wurkdruk evaluearje dy't wurdt makke troch ús kliïnten.
Mar wurkdruk bestiet fansels ek út oanfragen. Applikaasjes ferbine mei de databank, tagong ta gegevens mei queries, dus it is wichtich om te evaluearjen hokker fragen wy hawwe yn 'e databank, kontrolearje har adekwaatheid, dat se net krom skreaun binne, dat guon opsjes opnij skreaun en makke wurde moatte, sadat se rapper wurkje en mei bettere prestaasjes.
En om't wy it oer in databank hawwe, is de databank altyd eftergrûnprosessen. Eftergrûnprosessen helpe databaseprestaasjes op in goed nivo te behâlden, sadat se in bepaalde hoemannichte boarnen nedich binne foar harsels om te operearjen. En tagelyk kinne se oerlaapje mei helpboarnen foar kliïntoanfraach, sadat gierige eftergrûnprosessen direkt ynfloed kinne op 'e prestaasjes fan oanfragen fan kliïnten. Dêrom moatte se ek wurde kontrolearre en folge, sadat d'r gjin fersteuringen binne yn termen fan eftergrûnprosessen.
En dit alles yn termen fan databankmonitoring bliuwt yn 'e systeemmetrik. Mar yn betinken nommen dat de measte fan ús ynfrastruktuer nei de wolken beweecht, ferdwine de systeemmetriken fan in yndividuele host altyd op 'e eftergrûn. Mar yn databases binne se noch altyd relevant en, fansels, is it ek nedich om systeemmetriken te kontrolearjen.
Alles is min of mear goed mei systeemmetriken, alle moderne kontrôlesystemen stypje dizze metriken al, mar yn 't algemien binne guon komponinten noch net genôch en moatte guon dingen tafoege wurde. Ik sil se ek oanreitsje, der komme ferskate dia's oer.
It earste punt fan it plan is berikberens. Wat is tagonklikens? Beskikberens yn myn begryp is it fermogen fan 'e basis om ferbiningen te tsjinjen, d.w.s. de basis wurdt ferhege, it, as in tsjinst, akseptearret ferbiningen fan kliïnten. En dizze tagonklikens kin wurde beoardiele troch bepaalde skaaimerken. It is heul handich om dizze skaaimerken te werjaan op dashboards.
Elkenien wit wat dashboards binne. Dit is as jo ien kear op it skerm hawwe sjoen wêrop de nedige ynformaasje wurdt gearfette. En jo kinne fuortendaliks bepale oft der in probleem is yn 'e databank of net.
Dêrom moatte de beskikberens fan 'e databank en oare wichtige skaaimerken altyd wurde werjûn op dashboards, sadat dizze ynformaasje by de hân is en altyd beskikber foar jo. Guon oanfoljende details dy't al helpe by it ûndersyk fan ynsidinten, by it ûndersykjen fan guon needsituaasjes, moatte se al pleatst wurde op sekundêre dashboards, of ferburgen yn drilldown-keppelings dy't liede ta tafersjochsystemen fan tredden.
In foarbyld fan ien bekend tafersjochsysteem. Dit is in heul cool tafersjochsysteem. Se sammelet in protte gegevens, mar út myn eachpunt, se hat in nuver konsept fan dashboards. D'r is in keppeling om "in dashboard oan te meitsjen". Mar as jo in dashboard meitsje, meitsje jo in list fan twa kolommen, in list mei grafiken. En as jo wat moatte besjen, begjinne jo te klikken mei de mûs, rôlje, sykje nei de winske kaart. En dit duorret tiid, d.w.s. d'r binne gjin dashboards as sadanich. D'r binne allinich listen mei charts.
Wat moatte jo tafoegje oan dizze dashboards? Jo kinne begjinne mei sa'n karakteristyk as reaksjetiid. PostgreSQL hat de werjefte pg_stat_statements. It is standert útskeakele, mar it is ien fan 'e wichtige systeemwerjeften dy't altyd moatte wurde ynskeakele en brûkt. It bewarret ynformaasje oer alle rinnende queries dy't binne útfierd yn 'e databank.
Dêrnjonken kinne wy begjinne mei it feit dat wy de totale útfieringstiid fan alle oanfragen kinne nimme en it dielen troch it oantal oanfragen mei de boppesteande fjilden. Mar dit is de gemiddelde temperatuer yn it sikehûs. Wy kinne begjinne fan oare fjilden - minimale query-útfiertiid, maksimum en mediaan. En wy kinne sels percentiles bouwe; PostgreSQL hat dêr oerienkommende funksjes foar. En wy kinne wat sifers krije dy't de antwurdtiid fan ús databank karakterisearje foar al foltôge oanfragen, d.w.s. wy fiere it falske fersyk 'selektearje 1' net út en sjogge nei de antwurdtiid, mar wy analysearje de antwurdtiid foar al foltôge oanfragen en tekenje of in aparte figuer, of wy bouwe in grafyk basearre op it.
It is ek wichtich om it oantal flaters te kontrolearjen dat op it stuit wurdt generearre troch it systeem. En hjirfoar kinne jo de werjefte pg_stat_database brûke. Wy rjochtsje ús op it fjild xact_rollback. Dit fjild toant net allinnich it oantal rollbacks dy't foarkomme yn de databank, mar hâldt ek rekken mei it oantal flaters. Relatyf sprutsen kinne wy dit figuer yn ús dashboard werjaan en sjen hoefolle flaters wy op it stuit hawwe. As d'r in protte flaters binne, dan is dit in goede reden om yn 'e logs te sjen en te sjen hokker soarte flaters se binne en wêrom't se foarkomme, en dan ynvestearje en oplosse.
Jo kinne sa'n ding tafoegje as in Tachometer. Dit binne it oantal transaksjes per sekonde en it oantal oanfragen per sekonde. Relatyf sprutsen kinne jo dizze nûmers brûke as de aktuele prestaasjes fan jo databank en observearje oft d'r peaks binne yn oanfragen, peaks yn transaksjes, of oarsom, oft de databank ûnderladen is om't guon backend mislearre is. It is wichtich om altyd nei dizze figuer te sjen en te betinken dat foar ús projekt dit soarte fan prestaasjes normaal is, mar de wearden boppe en ûnder binne al in soarte fan problematysk en ûnbegryplik, wat betsjut dat wy moatte sjen wêrom't dizze sifers binne sa heech.
Om it oantal transaksjes te skatten, kinne wy wer ferwize nei de werjefte fan pg_stat_database. Wy kinne it oantal commits en it oantal rollbacks tafoegje en it oantal transaksjes per sekonde krije.
Begrypt elkenien dat ferskate oanfragen yn ien transaksje passe kinne? Dêrom binne TPS en QPS wat oars.
It oantal oanfragen per sekonde kin krigen wurde fan pg_stat_statements en gewoan berekkenje de som fan alle foltôge oanfragen. It is dúdlik dat wy de hjoeddeistige wearde fergelykje mei de foarige, it ôflûke, de delta krije en de kwantiteit krije.
Jo kinne ekstra metriken tafoegje as jo wolle, dy't ek helpe om de beskikberens fan ús databank te evaluearjen en te kontrolearjen oft der ûnderbrekkings west hawwe.
Ien fan dizze metriken is uptime. Mar uptime yn PostgreSQL is in bytsje lestich. Ik sil dy fertelle wêrom. As PostgreSQL is begon, begjint uptime te rapportearjen. Mar as op in stuit, bygelyks, in taak nachts rûn, in OOM-killer kaam en mei geweld it PostgreSQL-berneproses beëinige, dan beëiniget PostgreSQL yn dit gefal de ferbining fan alle kliïnten, reset it sharded ûnthâldgebiet en begjint herstel fan de lêste kontrôle. En wylst dit herstel fan it kontrôlepunt duorret, akseptearret de databank gjin ferbiningen, dus dizze situaasje kin wurde beoardiele as downtime. Mar de uptime-teller sil net weromset wurde, om't it rekken hâldt mei de opstarttiid fan postmaster fan it earste momint. Dêrom kinne sokke situaasjes oerslein wurde.
Jo moatte ek it oantal fakuümwurkers kontrolearje. Wit elkenien wat autovacuum is yn PostgreSQL? Dit is in ynteressant subsysteem yn PostgreSQL. Der binne in protte artikels oer har skreaun, in protte rapporten binne makke. Der binne in soad diskusjes oer fakuüm en hoe't it wurkje moat. In protte beskôgje it in needsaaklik kwea. Mar sa is it. Dit is in soarte fan analoog fan in garbage collector dy't ferâldere ferzjes fan rigen skjinmakket dy't net nedich binne foar elke transaksje en romte frijmakket yn tabellen en yndeksen foar nije rigen.
Wêrom moatte jo it kontrolearje? Want it fakuüm docht wolris sear. It ferbrûkt in grutte hoemannichte boarnen en kliïntoanfragen begjinne dêrtroch te lijen.
En it moat wurde kontrolearre fia de werjefte pg_stat_activity, dêr't ik oer sil prate yn 'e folgjende seksje. Dizze werjefte lit de aktuele aktiviteit yn 'e databank sjen. En fia dizze aktiviteit kinne wy it oantal fakuüm folgje dat op it stuit wurket. Wy kinne fakuüm folgje en sjen dat as wy de limyt hawwe oerbrocht, dan is dit in reden om de PostgreSQL-ynstellingen te besjen en op ien of oare manier de wurking fan it fakuüm te optimalisearjen.
In oar ding oer PostgreSQL is dat PostgreSQL heul siik is fan lange transaksjes. Benammen fan transaksjes dy't lang hingje en neat dogge. Dit is de saneamde stat idle-in-transaksje. Sa'n transaksje hâldt slûzen en foarkomt dat it fakuüm wurket. En as gefolch, de tabellen swollen en tanimme yn grutte. En queries dy't wurkje mei dizze tabellen begjinne te wurkjen stadiger, omdat jo moatte shovel alle âlde ferzjes fan rigen fan ûnthâld nei skiif en werom. Dêrom moatte de tiid, de doer fan 'e langste transaksjes, de langste fakuümoanfragen ek wurde kontrolearre. En as wy sjogge guon prosessen dy't rinne foar in hiel lange tiid, al mear as 10-20-30 minuten foar in OLTP-load, dan moatte betelje omtinken oan harren en krêftich beëinigje se, of optimalisearjen fan de applikaasje sadat se wurde net neamd en hingje net sa lang. Foar in analytyske wurkdruk is 10-20-30 minuten normaal; d'r binne ek langere.
Dêrnei hawwe wy de opsje mei ferbûne kliïnten. As wy al in dashboard hawwe oanmakke en wichtige beskikberensmetriken derop pleatst, kinne wy dêr ek ekstra ynformaasje tafoegje oer ferbûne kliïnten.
Ynformaasje oer ferbûne kliïnten is wichtich om't, út in PostgreSQL-perspektyf, kliïnten oars binne. D'r binne goede kliïnten en d'r binne minne kliïnten.
In ienfâldich foarbyld. Troch klant begryp ik de applikaasje. De applikaasje is ferbûn mei de databank en begjint fuortendaliks syn fersiken dêr te ferstjoeren, de databank ferwurket en útfiert se, en jout de resultaten werom nei de kliïnt. Dit binne goede en korrekte kliïnten.
Der binne situaasjes as de kliïnt hat ferbûn, it hâldt de ferbining, mar docht neat. It is yn idle steat.
Mar d'r binne minne kliïnten. Bygelyks, deselde kliïnt ferbûn, iepene in transaksje, die wat yn 'e database en gie dan yn' e koade, bygelyks om tagong te krijen ta in eksterne boarne of om de ûntfongen gegevens dêr te ferwurkjen. Mar hy hat de transaksje net sluten. En de transaksje hinget yn 'e databank en wurdt holden yn in slot op' e line. Dit is in minne tastân. En as ynienen in applikaasje earne yn himsels mislearret mei in útsûndering, dan kin de transaksje hiel lang iepen bliuwe. En dit hat direkt ynfloed op PostgreSQL-prestaasjes. PostgreSQL sil stadiger wêze. Dêrom is it wichtich om sokke kliïnten op 'e tiid te folgjen en har wurk krêftich te beëinigjen. En jo moatte jo applikaasje optimalisearje, sadat sokke situaasjes net foarkomme.
Oare minne kliïnten wachtsje kliïnten. Mar se wurde min troch omstannichheden. Bygelyks, in ienfâldige idle transaksje: it kin iepenje in transaksje, nimme slûzen op guon rigels, dan earne yn 'e koade sil mislearje, it ferlitten fan in hingjende transaksje. In oare klant sil komme en freegje deselde gegevens, mar hy sil tsjinkomme in slot, omdat dy hingjende transaksje al hâldt slûzen op guon fereaske rigen. En de twadde transaksje sil hingje om te wachtsjen op 'e earste transaksje om te foltôgjen of mei geweld te sluten troch de behearder. Dêrom kinne ôfhannele transaksjes de limyt fan 'e databaseferbining sammelje en folje. En as de limyt fol is, kin de applikaasje net mear wurkje mei de databank. Dit is al in needsituaasje foar it projekt. Dêrom moatte minne kliïnten op 'e tiid wurde folge en reagearre wurde.
In oar foarbyld fan tafersjoch. En hjir is al in fatsoenlik dashboard. Der is ynformaasje oer ferbinings hjirboppe. DB-ferbining - 8 stikken. En it is alles. Wy hawwe gjin ynformaasje oer hokker kliïnten aktyf binne, hokker kliïnten gewoan idle binne, neat dwaan. D'r is gjin ynformaasje oer pending transaksjes en pending ferbinings, dat wol sizze dit is in figuer dat toant it oantal ferbinings en dat is it. En dan sels riede.
Dêrom, om dizze ynformaasje ta te foegjen oan tafersjoch, moatte jo tagong krije ta de pg_stat_activity-systeemwerjefte. As jo in protte tiid yn PostgreSQL besteegje, dan is dit in heul goede werjefte dy't jo freon moat wurde, om't it de hjoeddeistige aktiviteit yn PostgreSQL toant, dus wat deryn bart. Foar elk proses is d'r in aparte rigel dy't ynformaasje toant oer dit proses: fan hokker host de ferbining is makke, ûnder hokker brûker, ûnder hokker namme, wannear't de transaksje begon is, hokker fersyk op it stuit rint, hokker fersyk foar it lêst útfierd is. En dêrom kinne wy de steat fan 'e klant evaluearje mei it statfjild. Relatyf sprutsen kinne wy groepearje op dit fjild en krije dy statistiken dy't op it stuit yn 'e database binne en it oantal ferbiningen dy't dizze stat yn' e database hawwe. En wy kinne de al ûntfongen nûmers nei ús tafersjoch stjoere en grafiken tekenje op basis dêrfan.
It is ek wichtich om de doer fan 'e transaksje te evaluearjen. Ik haw al sein dat it wichtich is om de doer fan vacuums te evaluearjen, mar transaksjes wurde op deselde wize evaluearre. D'r binne xact_start- en query_start-fjilden. Se, relatyf sjoen, litte de starttiid fan 'e transaksje en de starttiid fan it fersyk sjen. Wy nimme de funksje no (), dy't de hjoeddeiske tiidstempel toant, en de transaksje ôflûke en tiidstempel fersykje. En wy krije de doer fan 'e transaksje, de doer fan it fersyk.
As wy lange transaksjes sjogge, moatte wy se al foltôgje. Foar in OLTP-lading binne lange transaksjes al mear as 1-2-3 minuten. Foar in OLAP-workload binne lange transaksjes normaal, mar as se mear as twa oeren nimme om te foltôgjen, dan is dit ek in teken dat wy earne in skew hawwe.
As kliïnten ienris ferbûn binne mei de database, begjinne se te wurkjen mei ús gegevens. Se krije tagong ta tabellen, se krije tagong ta yndeksen om gegevens út 'e tabel te heljen. En it is wichtich om te evaluearjen hoe't kliïnten ynteraksje mei dizze gegevens.
Dit is nedich om ús wurkdruk te evaluearjen en rûchwei te begripen hokker tabellen de "waarmste" binne foar ús. Bygelyks, dit is nedich yn situaasjes dêr't wy wolle pleatse "hot" tabellen op in soarte fan flugge SSD opslach. Bygelyks, guon argyftabellen dy't wy in lange tiid net hawwe brûkt, kinne wurde ferpleatst nei in soarte fan "kâld" argyf, nei SATA-skiven en lit se dêr wenje, se wurde tagong as nedich.
Dit is ek nuttich foar it opspoaren fan anomalies nei elke releases en ynset. Litte wy sizze dat it projekt wat nije funksje hat útbrocht. Wy hawwe bygelyks nije funksjonaliteit tafoege foar it wurkjen mei de databank. En as wy grafen foar tabelgebrûk plotje, kinne wy dizze anomalies maklik op dizze grafiken detektearje. Bygelyks bywurkje bursts of wiskje bursts. It sil tige sichtber wêze.
Jo kinne ek anomalies detektearje yn "driuwende" statistiken. Wat betsjut dat? PostgreSQL hat in heul sterke en heul goede queryplanner. En de ûntwikkelders besteegje in protte tiid oan har ûntwikkeling. Hoe wurket hy? Om goede plannen te meitsjen, sammelt PostgreSQL statistiken oer de ferdieling fan gegevens yn tabellen op in bepaald tiidynterval en mei in bepaalde frekwinsje. Dit binne de meast foarkommende wearden: it oantal unike wearden, ynformaasje oer NULL yn 'e tabel, in protte ynformaasje.
Op grûn fan dizze statistiken konstruearret de planner ferskate queries, selekteart de meast optimale en brûkt dit queryplan om de query sels út te fieren en gegevens werom te jaan.
En it bart dat de statistiken "float". De kwaliteit en kwantiteit gegevens op ien of oare manier feroare yn 'e tabel, mar de statistiken waarden net sammele. En de plannen binne miskien net optimaal. En as ús plannen suboptimaal blike te wêzen op basis fan de sammele tafersjoch, basearre op 'e tabellen, sille wy dizze anomalies kinne sjen. Bygelyks, earne feroare de gegevens kwalitatyf en ynstee fan 'e yndeks begon in opienfolgjende pass troch de tabel te brûken, d.w.s. as in query mar 100 rigen moat weromjaan (der is in limyt fan 100), dan sil in folsleine sykopdracht foar dizze query útfierd wurde. En dit hat altyd in hiel min effekt op prestaasjes.
En wy kinne dit sjen yn tafersjoch. En sjoch al nei dizze fraach, útfiere in útlis foar it, sammelje statistiken, bou in nije ekstra yndeks. En al reagearje op dit probleem. Dêrom is it wichtich.
In oar foarbyld fan tafersjoch. Ik tink dat in protte minsken him werkenne om't hy tige populêr is. Wa't it brûkt yn har projekten ? Wa brûkt dit produkt yn gearhing mei Prometheus? It feit is dat yn it standert repository fan dizze tafersjoch in dashboard is foar wurkjen mei PostgreSQL - Prometheus. Mar d'r is ien min detail.
D'r binne ferskate grafiken. En bytes wurde oanjûn as ienheid, d.w.s. d'r binne 5 grafiken. Dit binne gegevens ynfoegje, gegevens bywurkje, gegevens wiskje, gegevens ophelje en gegevens weromjaan. De ienheidsmjitting is bytes. Mar it ding is dat statistiken yn PostgreSQL gegevens weromjout yn tuple (rijen). En dêrom binne dizze grafiken in heul goede manier om jo wurkdruk ferskate kearen, tsientallen kearen te ûnderskatten, om't in tuple gjin byte is, in tuple is in tekenrige, it is in protte bytes en it is altyd fan fariabele lingte. Dat is, it berekkenjen fan wurkdruk yn bytes mei tuples is in unrealistyske taak as heul lestich. Dêrom, as jo in dashboard as ynboude tafersjoch brûke, is it altyd wichtich om te begripen dat it goed wurket en jo korrekt beoardiele gegevens werombringt.
Hoe kinne jo statistiken krije oer dizze tabellen? Foar dit doel hat PostgreSQL in bepaalde famylje fan werjeften. En de wichtichste werjefte is . User_tables - dit betsjut tabellen makke út namme fan de brûker. Yn tsjinstelling binne d'r systeemwerjeften dy't wurde brûkt troch PostgreSQL sels. En d'r is in gearfettingstabel Alltables, dy't sawol systeem- as brûkers omfettet. Jo kinne begjinne fan ien fan harren dy't jo it bêste fine.
Mei de boppesteande fjilden kinne jo it oantal ynfoegingen, fernijings en wiskjes skatte. It foarbyld fan in dashboard dat ik brûkte brûkt dizze fjilden om de skaaimerken fan in wurkdruk te evaluearjen. Dêrom kinne wy ek op har bouwe. Mar it is it wurdich te ûnthâlden dat dit tuples binne, gjin bytes, dus wy kinne it net gewoan yn bytes dwaan.
Op grûn fan dizze gegevens kinne wy saneamde TopN-tabellen bouwe. Bygelyks, Top-5, Top-10. En jo kinne track dy hite tabellen dy't wurde recycled mear as oaren. Bygelyks, 5 "hot" tabellen foar ynfoegje. En mei dizze TopN-tabellen evaluearje wy ús wurkdruk en kinne bursts fan wurkdruk evaluearje nei elke releases, updates en ynset.
It is ek wichtich om de grutte fan 'e tafel te evaluearjen, om't soms ûntwikkelders in nije funksje útrolje, en ús tabellen begjinne te swollen yn har grutte dimensjes, om't se besletten in ekstra hoemannichte gegevens ta te foegjen, mar net foarsizze hoe't dit soe beynfloedzje de grutte fan de databank. Sokke gefallen komme ek foar ús as ferrassingen.
En no in lytse fraach foar jo. Hokker fraach ûntstiet as jo de lading op jo databanktsjinner fernimme? Wat is de folgjende fraach dy't jo hawwe?
Mar yn feite komt de fraach as folget. Hokker oanfragen feroarsaket de lading? Dat is, it is net nijsgjirrich om te sjen nei de prosessen dy't wurde feroarsake troch de lading. It is dúdlik dat as de host in databank hat, dan rint de databank dêr en it is dúdlik dat allinnich de databanken dêr ôfset wurde. As wy Top iepenje, sille wy dêr in list sjen mei prosessen yn PostgreSQL dy't wat dogge. It sil fan Top net dúdlik wurde wat se dogge.
Dêrom moatte jo de fragen fine dy't de heechste lading feroarsaakje, om't tuning-fragen, as regel, mear winst jout dan it ôfstimmen fan de PostgreSQL- of bestjoeringssysteemkonfiguraasje, of sels it ôfstimmen fan 'e hardware. Neffens myn skatting is dit sawat 80-85-90%. En dit wurdt dien folle flugger. It is flugger om in fersyk te korrizjearjen dan de konfiguraasje te korrigearjen, in trochstart te plannen, benammen as de databank net opnij starte kin, of hardware tafoegje. It is makliker om de query earne oer te skriuwen of in yndeks ta te foegjen om in better resultaat fan dizze query te krijen.
Dêrtroch is it needsaaklik om oanfragen en har adekwaatheid te kontrolearjen. Lit ús nimme in oar foarbyld fan tafersjoch. En ek hjir liket der in poerbêste tafersjoch te wêzen. D'r is ynformaasje oer replikaasje, d'r is ynformaasje oer trochfier, blokkearjen, gebrûk fan boarnen. Alles is goed, mar der is gjin ynformaasje oer fersiken. It is net dúdlik hokker queries yn ús databank rinne, hoe lang se rinne, hoefolle fan dizze queries binne. Wy moatte dizze ynformaasje altyd hawwe yn ús tafersjoch.
En om dizze ynformaasje te krijen kinne wy de module pg_stat_statements brûke. Op grûn dêrfan kinne jo in ferskaat oan grafiken bouwe. Jo kinne bygelyks ynformaasje krije oer de meast foarkommende queries, dat is, oer dy queries dy't it meast útfierd wurde. Ja, nei ynset is it ek heul nuttich om it te besjen en te begripen as d'r in tanimming is yn oanfragen.
Jo kinne de langste fragen kontrolearje, dat is, dy fragen dy't it langst nimme om te foltôgjen. Se rinne op 'e prosessor, se konsumearje I / O. Wy kinne dit ek evaluearje mei de fjilden total_time, mean_time, blk_write_time en blk_read_time.
Wy kinne de swierste oanfragen evaluearje en kontrolearje yn termen fan boarnegebrûk, dyjingen dy't lêze fan skiif, dy't wurkje mei ûnthâld, of, oarsom, in soarte fan skriuwlading meitsje.
Wy kinne de meast royale oanfragen evaluearje. Dit binne de fragen dy't in grut oantal rigen werombringe. Dit kin bygelyks in fersyk wêze wêr't se fergetten binne om in limyt yn te stellen. En it jout gewoan de hiele ynhâld fan 'e tabel as query oer de ûnderfrege tabellen.
En jo kinne ek fragen kontrolearje dy't tydlike bestannen of tydlike tabellen brûke.
En wy hawwe noch eftergrûnprosessen. Eftergrûnprosessen binne foaral kontrôlepunten of se wurde ek kontrôlepunten neamd, dit binne autovacuum en replikaasje.
In oar foarbyld fan tafersjoch. D'r is in ljepblêd Underhâld oan de linkerkant, gean nei it en hoopje wat nuttich te sjen. Mar hjir is allinnich de tiid fan fakuüm operaasje en statistyk kolleksje, neat mear. Dit is heul minne ynformaasje, dus wy moatte altyd ynformaasje hawwe oer hoe't eftergrûnprosessen wurkje yn ús databank en oft der problemen binne fan har wurk.
As wy sjogge nei checkpoints, wy moatte betinke dat checkpoints Flush smoarge siden út de sharded ûnthâld gebiet oan skiif, dan meitsje in kontrôle. En dit kontrôlepunt kin dan brûkt wurde as plak foar herstel as PostgreSQL yn in need ynienen beëinige waard.
Dêrom, om alle "smoarge" siden nei de skiif te spoelen, moatte jo in bepaald oantal skriuwen dwaan. En, as in regel, op systemen mei grutte hoemannichten ûnthâld, dit is in protte. En as wy yn in koart ynterval heul faak kontrôlepunten dogge, dan sil de skiifprestaasje heul signifikant sakje. En oanfragen fan kliïnten sille lije fan in tekoart oan middels. Se sille konkurrearje om boarnen en gebrek oan produktiviteit.
Dêrtroch kinne wy fia pg_stat_bgwriter mei help fan de oantsjutte fjilden it oantal kontrôlepunten kontrolearje dy't foarkomme. En as wy in protte kontrôlepunten hawwe oer in bepaalde tiid (yn 10-15-20 minuten, yn in heal oere), bygelyks 3-4-5, dan kin dit al in probleem wêze. En jo moatte al sjen yn 'e databank, sjoch yn' e konfiguraasje, wat feroarsake sa'n oerfloed fan kontrôlepunten. Miskien is der in soarte fan grutte opname. Wy kinne de wurkdruk al evaluearje, om't wy wurkdrukgrafiken al tafoege hawwe. Wy kinne de kontrôlepuntparameters al oanpasse en derfoar soargje dat se gjin grutte ynfloed hawwe op de prestaasjes fan query.
Ik kom werom nei autovacuum wer omdat it is sa'n ding, lykas ik sei, dat kin maklik optelle sawol skiif en query prestaasjes, dus it is altyd wichtich om te skatten it bedrach fan autovacuum.
It oantal autovacuum-arbeiders yn 'e databank is beheind. Standert binne d'r trije fan har, dus as wy altyd trije arbeiders hawwe dy't wurkje yn 'e databank, betsjut dit dat ús autovacuum net konfigureare is, wy moatte de grinzen ferheegje, de autovacuum-ynstellingen feroarje en yn 'e konfiguraasje komme.
It is wichtich om te evaluearjen hokker fakuümwurkers wy hawwe. Of it waard lansearre fan 'e brûker, de DBA kaam en lansearre in soarte fan fakuüm mei de hân, en dit makke in lading. Wy hawwe in soarte fan probleem. Of dit is it oantal fakuüm dat de transaksjeteller losdraait. Foar guon ferzjes fan PostgreSQL binne dit heul swiere vacuums. En se kinne de prestaasjes maklik optelle, om't se de hiele tabel lêze, alle blokken yn dy tabel scannen.
En, fansels, de doer fan fakuüm. As wy langduorjende fakuümkes hawwe dy't in heul lange tiid rinne, dan betsjut dit dat wy opnij omtinken moatte jaan oan 'e fakuümkonfiguraasje en miskien har ynstellingen opnij besjen. Om't in situaasje kin ûntstean as it fakuüm wurket op 'e tafel foar in lange tiid (3-4 oeren), mar yn' e tiid dat it fakuüm wurke, slagge in grut oantal deade rigen te sammeljen yn 'e tafel wer. En sa gau as it fakuüm foltôge is, moat hy dizze tafel wer stofsûgje. En wy komme ta in situaasje - in einleaze fakuüm. En yn dit gefal is it fakuüm net omgean mei syn wurk, en de tabellen stadichoan begjinne te swollen yn grutte, hoewol't it folume fan brûkbere gegevens dêryn bliuwt itselde. Dêrom sjogge wy by lange fakuüm altyd nei de konfiguraasje en besykje it te optimalisearjen, mar tagelyk sadat de prestaasjes fan kliïntoanfragen net lije.
Tsjintwurdich is d'r praktysk gjin PostgreSQL-ynstallaasje dy't gjin streaming-replikaasje hat. Replikaasje is it proses fan it ferpleatsen fan gegevens fan in master nei in replika.
Replikaasje yn PostgreSQL wurdt dien fia in transaksjelog. De wizard genereart in transaksjelogboek. It transaksjelogboek reizget oer de netwurkferbining nei de replika, en dan wurdt it reprodusearre op 'e replika. It is ienfâldich.
Dêrtroch wurdt de werjefte fan pg_stat_replikaasje brûkt om de replikaasjefertraging te kontrolearjen. Mar net alles is ienfâldich mei har. Yn ferzje 10 hat de werjefte ferskate feroarings ûndergien. Earst binne guon fjilden omneamd. En guon fjilden binne tafoege. Yn ferzje 10 ferskynden fjilden wêrmei jo de replikaasjefertraging yn sekonden kinne skatte. It is hiel noflik. Foar ferzje 10 wie it mooglik om de replikaasjefertraging yn bytes te skatten. Dizze opsje bliuwt yn ferzje 10, d.w.s. jo kinne kieze wat handiger is foar jo - skatte de efterstân yn bytes of skatten de efterstân yn sekonden. In protte minsken dogge beide.
Mar dochs, om de replikaasjefertraging te evaluearjen, moatte jo de posysje fan it log yn 'e transaksje witte. En dizze transaksje log posysjes binne krekt yn de pg_stat_replication werjefte. Relatyf sprutsen, kinne wy nimme twa punten yn de transaksje log mei help fan de funksje pg_xlog_location_diff (). Berekkenje de delta tusken har en krije de replikaasjefertraging yn bytes. It is heul handich en ienfâldich.
Yn ferzje 10 waard dizze funksje omdoopt ta pg_wal_lsn_diff (). Yn 't algemien, yn alle funksjes, werjeften en nutsbedriuwen wêr't it wurd "xlog" ferskynde, waard it ferfongen troch de wearde "wal". Dit jildt foar sawol werjeften as funksjes. Dit is sa'n ynnovaasje.
Plus, yn ferzje 10 waarden rigels tafoege dy't spesifyk de efterstân sjen litte. Dit binne skriuwfertraging, flushlag, replaylag. Dat is, it is wichtich om dizze dingen te kontrolearjen. As wy sjogge dat wy in replikaasjefertraging hawwe, dan moatte wy ûndersykje wêrom't it ferskynde, wêr't it kaam en it probleem reparearje.
Hast alles is yn oarder mei systeemmetriken. As elke tafersjoch begjint, begjint it mei systeemmetriken. Dit is de beskikking fan processors, ûnthâld, swap, netwurk en skiif. In protte parameters binne lykwols net standert.
As alles yn oarder is mei it recyclingproses, dan binne d'r problemen mei diskrecycling. As regel foegje tafersjochûntwikkelders ynformaasje ta oer trochstreaming. It kin wêze yn iops of bytes. Mar se ferjitte oer latency en gebrûk fan skiifapparaten. Dit binne wichtiger parameters dy't ús tastean om te evaluearjen hoe laden ús skiven binne en hoe stadich se binne. As wy hege latency hawwe, dan betsjut dit dat d'r wat problemen binne mei de skiven. As wy hege benutten hawwe, betsjut it dat de skiven net omgean. Dit binne bettere skaaimerken dan trochset.
Boppedat kinne dizze statistiken ek krije fan it /proc-bestânsysteem, lykas dien wurdt foar recyclingprozessors. Ik wit net wêrom dizze ynformaasje net wurdt tafoege oan tafersjoch. Mar dochs is it wichtich om dit te hawwen yn jo tafersjoch.
Itselde jildt foar netwurk ynterfaces. D'r is ynformaasje oer netwurktrochput yn pakketten, yn bytes, mar d'r is lykwols gjin ynformaasje oer latency en gjin ynformaasje oer gebrûk, hoewol dit ek nuttige ynformaasje is.
Elke tafersjoch hat neidielen. En hokker soarte tafersjoch jo ek nimme, it sil altyd net oan guon kritearia foldwaan. Mar dochs ûntwikkelje se, nije funksjes en nije dingen wurde tafoege, dus kies wat en foltôgje it.
En om te foltôgjen, moatte jo altyd in idee hawwe fan wat de levere statistiken betsjutte en hoe't jo se kinne brûke om problemen op te lossen.
En in pear wichtige punten:
- Jo moatte altyd de beskikberens kontrolearje en dashboards hawwe, sadat jo fluch kinne beoardielje dat alles yn oarder is mei de database.
- Jo moatte altyd in idee hawwe fan hokker kliïnten mei jo database wurkje om minne kliïnten út te weidzjen en se del te sjitten.
- It is wichtich om te evaluearjen hoe't dizze kliïnten wurkje mei gegevens. Jo moatte in idee hawwe oer jo wurkdruk.
- It is wichtich om te evaluearjen hoe't dizze wurkdruk wurdt foarme, mei help fan hokker fragen. Jo kinne fragen evaluearje, jo kinne se optimalisearje, refaktorearje, yndeksen foar har bouwe. It is tige wichtich.
- Eftergrûnprosessen kinne negatyf beynfloedzje oanfragen fan kliïnten, dus it is wichtich om te kontrolearjen dat se net te folle boarnen brûke.
- Systeemmetriken kinne jo plannen meitsje foar skaalfergrutting en it fergrutsjen fan de kapasiteit fan jo servers, dus it is wichtich om se ek te folgjen en te evaluearjen.
As jo ynteressearre binne yn dit ûnderwerp, dan kinne jo dizze keppelings folgje.
- dit is offisjele dokumintaasje fan 'e statistyksamler. Der is in beskriuwing fan alle statistyske werjeften en in beskriuwing fan alle fjilden. Jo kinne se lêze, begripe en analysearje. En basearre op har, bouwe jo grafiken en foegje se ta oan jo tafersjoch.
Foarbyld oanfragen:
Dit is ús bedriuwsrepository en myn eigen. Se befetsje foarbyldfragen. D'r binne gjin fragen fan 'e selekteare * út searjes dêr. D'r binne al klearebare fragen mei joins, mei ynteressante funksjes dy't jo rûge sifers kinne omsette yn lêsbere, handige wearden, dus dit binne bytes, tiid. Jo kinne se ophelje, sjoch nei se, analysearje se, foegje se ta oan jo tafersjoch, bouwe jo tafersjoch op basis dêrfan.
Jo fragen
Fraach: Jo hawwe sein dat jo gjin merken sille advertearje, mar ik bin noch altyd nijsgjirrich - wat foar dashboards brûke jo yn jo projekten?
Antwurd: It ferskilt. It komt foar dat wy by in klant komme en dy hat al in eigen tafersjoch. En wy advisearje de klant oer wat moat wurde tafoege oan har tafersjoch. De minste situaasje is mei Zabbix. Om't it net de mooglikheid hat om TopN-grafiken te bouwen. Wy sels brûke , om't wy mei dizze jonges oer tafersjoch wiene. Se kontroleare PostgreSQL basearre op ús technyske spesifikaasjes. Ik skriuw myn eigen pet-projekt, dat gegevens sammelt fia Prometheus en werjaan . Myn taak is om myn eigen eksporteur te meitsjen yn Prometheus en dan alles yn Grafana wer te jaan.
Fraach: Binne d'r analogen fan AWR-rapporten of ... aggregaasje? Witte jo sa'n ding?
Antwurd: Ja, ik wit wat AWR is, it is in cool ding. Op it stuit binne d'r in ferskaat oan fytsen dy't sawat it folgjende model implementearje. Op guon ynterval fan tiid wurde guon basislinen skreaun nei deselde PostgreSQL as nei in aparte opslach. Jo kinne se op it ynternet googleje, se binne der. Ien fan 'e ûntwikkelders fan sa'n ding sit op it sql.ru-foarum yn 'e PostgreSQL-thread. Jim kinne him dêr fange. Ja, der binne sokke dingen, se kinne brûkt wurde. Plus yn syn Ik skriuw ek in ding wêrmei jo itselde kinne dwaan.
PS1 As jo postgres_exporter brûke, hokker dashboard brûke jo? Der binne ferskate fan harren. Se binne al ferâldere. Miskien sil de mienskip in bywurke sjabloan oanmeitsje?
PS2 Fuortsmite pganalyze om't it in proprietêr SaaS-oanbod is dat him rjochtet op prestaasjesmonitoring en automatyske tuning-suggestjes.
Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. , asjebleaft.
Hokker sels-hosted postgresql-monitoring (mei dashboard) beskôgje jo it bêste?
-
30,0%Zabbix + tafoegings fan 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 in proprietêre SaaS - ik kin it net wiskje1
-
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 brûkers stimden. 26 brûkers ûntholden har.
Boarne: www.habr.com