Suggerenu di familiarizàvi cù a trascrizione di u rapportu di Alexey Lesovsky da Data Egret "Basi di Monitoring PostgreSQL"
In questu rapportu, Alexey Lesovsky parlerà di i punti chjave di statistiche postgres, ciò chì significanu, è per quessa ch'elli anu da esse inclusu in u monitoraghju; nantu à quale carte deve esse in u monitoraghju, cumu aghjunghje è cumu interpretà. U rapportu serà utile per l'amministratori di basa di dati, l'amministratori di u sistema è i sviluppatori chì anu interessatu à a risoluzione di i prublemi di Postgres.
Mi chjamu Alexey Lesovsky, rapprisentanu Data Egret.
Uni pochi di parolle nantu à mè stessu. Aghju cuminciatu assai tempu fà cum'è amministratore di sistema.
Amministratu ogni tipu di Linux diffirenti, facia diverse cose ligati à Linux, vale à dì virtualizazione, monitorizazione, travagliatu cù proxy, etc. Ma à un certu puntu sò diventatu più implicatu in basa di dati, PostgreSQL. Mi piacia assai. È à un certu puntu, aghju cuminciatu à trattà cù PostgreSQL a maiò parte di u mo tempu di travagliu. È cusì gradualmente sò diventatu un DBA PostgreSQL.
È in tutta a mo carriera, aghju sempre interessatu à i temi di statistiche, surviglianza, telemetria. È quandu era un amministratore di sistema, aghju travagliatu assai dura in Zabbix. È hà scrittu una piccula serie di script cum'è . Era assai populari in u so tempu. E ci era pussibule di monitorà e cose impurtanti assai diverse, micca solu Linux, ma ancu diversi cumpunenti.
Avà sò digià fattu PostgreSQL. Sò digià scrittu un'altra cosa chì vi permette di travaglià cù statistiche PostgreSQL. Hè chjamatu (articulu nantu à Habré - ).
Una piccula introduzione. Chì sò e situazioni cù i nostri clienti, cù i nostri clienti ? Ci hè un tipu d'accidente assuciatu cù a basa di dati. È quandu a basa di dati hè digià stata restaurata, u capu di u dipartimentu o u capu di sviluppu vene è dice: "Amici, duvemu monitorà a basa di dati, perchè qualcosa di male hè accadutu è hè necessariu chì questu ùn succede micca in u futuru". E quì principia u prucessu interessante di sceglie un sistema di surviglianza o adattà un sistema di monitoraghju esistenti per pudè monitorà a vostra basa di dati - PostgreSQL, MySQL o altri. È i culleghi cumincianu à offre: "Aghju intesu chì ci hè una tale basa di dati. Adupremu ". I culleghi cumincianu à litigà cun l'altri. È à a fine si scopre chì scegliemu un tipu di basa di dati, ma u monitoraghju PostgreSQL hè piuttostu debbuli rapprisintatu in questu è avemu sempre da finisce qualcosa. Pigliate alcuni repository da GitHub, clonateli, adattate scripts, in qualche modu sintonizzali. È à a fine si cade in qualchì tipu di travagliu manuale.
Dunque, in questu rapportu, pruvaraghju à dà un pocu di cunniscenze nantu à cumu sceglie u monitoraghju micca solu per PostgreSQL, ma ancu per a basa di dati. È per dà a cunniscenza chì vi permetterà di finisce u vostru monitoraghju per avè qualchì benefiziu da ellu, per pudè monitorà a vostra basa di dati cun benefiziu per prevene ogni situazione d'urgenza imminente chì pò esse in u tempu.
E quelli idee chì saranu in questu rapportu, ponu esse adattati direttamente à qualsiasi basa di dati, sia un DBMS o noSQL. Dunque, micca solu PostgreSQL quì, ma ci saranu parechje ricette nantu à cumu fà questu in PostgreSQL. Ci saranu esempi di dumande, esempi di entità chì PostgreSQL hà per u monitoraghju. È se u vostru DBMS hà e cose chì permettenu di mette in u monitoraghju, pudete ancu adattà, aghjunghje è sarà bè.
Ùn aghju micca rapportu
parlà di cumu furnisce è almacenà metriche. Ùn diceraghju nunda di dati di post-processamentu è furnisce à l'utilizatori. È ùn diceraghju nunda di l'alerta.
Ma in u corsu di a storia, vi mustrarà diverse screenshots di monitorings esistenti, in qualchì manera li criticaraghju. In ogni casu, pruvaraghju micca di nome di marche per ùn creà publicità o anti-publicità per questi prudutti. Dunque, tutte e coincidenze sò casuali è restanu nantu à a vostra imaginazione.
Prima, capisce ciò chì hè u monitoraghju. U monitoraghju hè una cosa assai impurtante per avè. Tutti capiscenu questu. Ma à u stessu tempu, u monitoraghju ùn hè micca ligatu à un pruduttu cummerciale è ùn affetta micca direttamente i profitti di a cumpagnia, cusì u monitoraghju hè sempre datu tempu nantu à una basa residuale. Se avemu u tempu, allora simu ingaghjati in u monitoraghju, se ùn ci hè micca tempu, allora OK, u metteremu in u backlog è un ghjornu vulteremu à sti travaglii.
Dunque, da a nostra pratica, quandu venemu à i clienti, u monitoraghju hè spessu sottusviluppatu è ùn hà micca cose interessanti chì ci aiutanu à fà un travagliu megliu cù a basa di dati. È dunque u monitoraghju sempre deve esse finitu.
E basa di dati sò cose cusì cumplesse chì avete ancu bisognu di monitorà, perchè e basa di dati sò un repository di informazioni. È l'infurmazione hè assai impurtante per a cumpagnia, ùn pò esse persa in ogni modu. Ma à u stessu tempu, e basa di dati sò pezzi di software assai cumplessi. Sò custituiti da parechji cumpunenti. È parechji di sti cumpunenti deve esse monitoratu.
Se parlemu specificamente di PostgreSQL, pò esse rapprisintatu cum'è un tali schema, chì hè custituitu da un gran numaru di cumpunenti. Sti cumpunenti interagisce cù l'altri. È à u stessu tempu, PostgreSQL hà u chjamatu subsistema Stats Collector, chì vi permette di cullà statistiche nantu à u funziunamentu di sti sottosistemi è furnisce una interfaccia à l'amministratore o l'utilizatore per pudè vede sti statistiche.
Questa statistiche hè presentata in forma di qualchì settore di funzioni è viste (vista). Puderanu ancu esse chjamati tavule. Questu hè, utilizendu un cliente psql regulare, pudete cunnette à a basa di dati, selezziunate queste funzioni è vedute, è uttene qualchi numeri specifichi nantu à l'operazione di i sottosistemi PostgreSQL.
Pudete aghjunghje questi numeri à u vostru sistema di surviglianza favuritu, tracciate grafici, aghjunghje funzioni è uttene analisi à longu andà.
Ma in questu rapportu, ùn aghju micca copre tutte queste funzioni senza eccezzioni, perchè pò piglià un ghjornu sanu. Mi riferiraghju literalmente à duie, trè o quattru cose è vi dicu cumu aiutanu à fà u monitoraghju megliu.
E se parlemu di monitorà a basa di dati, allora chì deve esse monitoratu? Prima di tuttu, avemu bisognu di monitorà a dispunibilità, perchè a basa di dati hè un serviziu chì furnisce l'accessu à e dati à i clienti è avemu bisognu di monitorà a dispunibilità, è ancu furnisce alcune di e so caratteristiche qualitative è quantitative.
Avemu ancu bisognu di monitorà i clienti chì si cunnetta à a nostra basa di dati, perchè ponu esse à tempu i clienti normali è i clienti dannosi chì ponu dannà a basa di dati. Hanu ancu bisognu à esse monitoratu è seguitu.
Quandu i clienti sò cunnessi à a basa di dati, hè ovvi chì cumincianu à travaglià cù i nostri dati, cusì avemu bisognu di monitorà cumu i clienti travaglianu cù e dati: cù quale tavule, à un puntu più minimu cù quale indici. Questu hè, avemu bisognu di valutà a carica di travagliu chì hè creatu da i nostri clienti.
Ma a carica di travagliu hè ancu custituita, sicuru, di richieste. L'applicazioni si cunnetta à a basa di dati, accede à e dati cù e dumande, per quessa, hè impurtante per valutà ciò chì dumandemu avemu in a basa di dati, monitorizà a so adattazione, chì ùn sò micca scritte in modu stortu, chì alcune opzioni anu da esse riscrivite è fatte in modu chì travaglianu più veloce. è cun megliu rendiment.
E postu chì parlemu di a basa di dati, a basa di dati hè sempre prucessi di fondu. I prucessi di sfondate mantenenu u rendiment di a basa di dati à un bonu livellu, cusì necessitanu una certa quantità di risorse per elli stessi. È à u stessu tempu, ponu sovrappone cù i risorsi di richieste di u cliente, cusì u travagliu greedy di i prucessi di fondu pò influenzà direttamente u rendiment di e dumande di i clienti. Dunque, anu ancu esse monitoratu è seguitu in modu chì ùn ci sò micca distorsioni in quantu à i prucessi di fondo.
È questu hè tuttu in quantu à u monitoraghju di basa di dati resta in a metrica di u sistema. Ma datu chì a maiò parte di a nostra infrastruttura sana va à i nuvuli, a metrica di u sistema di un òspite individuale sempre svanisce in u fondu. Ma in basa di dati, sò sempre pertinenti è, sicuru, hè ancu necessariu di monitorà e metriche di u sistema.
Cù metrica di u sistema, tuttu hè più o menu fine, tutti i sistemi di surviglianza muderni sustenianu digià sti metrichi, ma in generale, certi cumpunenti ùn sò micca abbastanza è certe cose anu da esse aghjuntu. I toccu ancu nantu à elli, parechji slides seranu nantu à elli.
U primu puntu di u pianu hè l'accessibilità. Cosa hè l'accessibilità? A dispunibilità in u mo intelligenza hè a capacità di a basa per serve cunnessione, vale à dì, a basa hè rialzata, cum'è serviziu, accetta cunnessione da i clienti. È sta accessibilità pò esse valutata da qualchi caratteristiche. Queste caratteristiche sò assai convenienti per vede nantu à i dashboards.
Tuttu u mondu sapi ciò chì i dashboards sò. Questu hè quandu avete pigliatu un ochju à u screnu, chì riassume l'infurmazioni necessarii. È pudete digià immediatamente stabilisce s'ellu ci hè un prublema in a basa di dati o micca.
In cunsiquenza, a dispunibilità di a basa di dati è altre caratteristiche chjave deve esse sempre messu nantu à i dashboards in modu chì sta infurmazione hè in manu, sempre cun voi. Certi ditaglii supplementari chì digià aiutanu in l'inchiesta di incidenti, in l'investigazione di qualchi situazione d'urgenza, anu digià bisognu à esse posti nantu à dashboards secundarii, o oculati in ligami drilldown chì portanu à sistemi di surviglianza di terzu.
Un esempiu di un sistema di monitoraghju cunnisciutu. Questu hè un sistema di monitoraghju assai cool. Coglie assai dati, ma da u mo puntu di vista, hà un cuncettu stranu di dashboards. Ci hè un ligame "Crea Dashboard". Ma quandu crea un dashboard, crea una lista di duie colonne, una lista di charts. È quandu avete bisognu di fighjà qualcosa, cuminciate à cliccà, scrolling, circà u graficu desideratu cù u mouse. È questu richiede u tempu, vale à dì chì ùn ci hè micca dashboards cum'è tali. Ci sò solu listi di charts.
Chì deve esse aghjuntu à questi dashboards? Pudete principià cù una caratteristica cum'è u tempu di risposta. PostgreSQL hà a vista pg_stat_statements. Hè disattivatu per automaticamente, ma hè una di e viste impurtanti di u sistema chì deve esse sempre attivatu è utilizatu. Guarda l'infurmazioni nantu à tutte e dumande in esecuzione chì sò state eseguite in a basa di dati.
In cunsiquenza, pudemu principià da u fattu chì pudemu piglià u tempu d'esekzione tutale di tutte e dumande è dividite per u numeru di richieste cù i campi sopra. Ma questu hè una temperatura cusì media in l'uspidale. Pudemu custruisce nantu à altri campi - u tempu minimu di esecuzione di a dumanda, u massimu è a mediana. È pudemu ancu custruisce percentili, PostgreSQL hà e funzioni currispundenti per questu. È pudemu avè alcuni numeri chì caratterizeghjanu u tempu di risposta di a nostra basa di dati per e dumande digià cumpletu, vale à dì ùn eseguimu micca a falsa dumanda "selezziunà 1" è fighjemu u tempu di risposta, ma analizemu u tempu di risposta per e dumande digià cumplette è tracciamu o una figura separata, o custruemu un graficu basatu annantu à questu.
Hè impurtante ancu di guardà u numeru di errori chì u sistema genera attualmente. È per questu pudete aduprà a vista pg_stat_database. Avemu destinatu à u campu di xact_rollback. Stu campu ùn solu mostra u nùmeru di rollbacks chì si trovanu in a basa di dati, ma ancu piglià in contu u numeru di errori. Relativamente parlante, pudemu vede sta figura in u nostru dashboard è vede quanti errori avemu in u mumentu. Se ci sò assai errori, allora questu hè digià un bonu mutivu per vede in i logs è vede chì tipu d'errori sò è perchè si sò, è poi invistisce è risolve.
Pudete aghjunghje una cosa cum'è un Tachometer. Quessi sò u numeru di transazzione per seconda è u numeru di richieste per seconda. Relativamente parlante, pudete aduprà sti numeri cum'è a prestazione attuale di a vostra basa di dati è osservà s'ellu ci sò picchi in richieste, picchi in transacciones, o, à u cuntrariu, a basa di dati hè sottucarcata perchè qualchì tipu di backend hè cascatu. Hè impurtante sempre di guardà sta figura è ricurdate chì per u nostru prughjettu una tale prestazione hè normale, è i valori sopra è sottu sò digià qualchì problematica è incomprensibile, chì significa chì avemu bisognu di vede perchè tali numeri. .
Per stimà u numeru di transazzione, pudemu dinò riferite à a vista pg_stat_database. Pudemu aghjunghje u nùmeru di cummissioni è u nùmeru di rollbacks per ottene u numeru di transazzione per seconda.
Ognunu capisce chì parechje dumande ponu esse in una transazzione? Dunque TPS è QPS sò ligeramente diffirenti.
U numaru di dumande per seconda pò esse acquistatu da pg_stat_statements è solu calculà a summa di tutte e dumande eseguite. Hè chjaru chì paragunemu u valore attuale cù u precedente, sottrae, uttene u delta, uttene a quantità.
Pudete aghjunghje metriche supplementari se vulete, chì aiutanu ancu à valutà a dispunibilità di a nostra basa di dati è seguite s'ellu ci era un downtime.
Una di queste metriche hè uptime. Ma uptime in PostgreSQL hè un pocu complicatu. Vi dicu perchè. Quandu PostgreSQL principia, cumencia à rapportà u uptime. Ma se in un certu puntu, per esempiu, un compitu era in esecuzione di notte, un OOM-killer hè ghjuntu è hà terminatu per forza u prucessu di u zitellu PostgreSQL, allora in questu casu PostgreSQL termina a cunnessione di tutti i clienti, resetta l'area di memoria sharded è principia a ricuperazione da l'ultimu puntu di cuntrollu. E mentre sta ricuperazione da u puntu di cuntrollu dura, a basa di dati ùn accetta micca cunnessione, vale à dì, sta situazione pò esse valutata cum'è downtime. Ma questu ùn hà micca resettatu u contatore di uptime, perchè tene in contu u tempu chì u postmaster hè stata cuminciatu da u primu mumentu. Dunque, tali situazioni ponu esse saltati.
Avete ancu monitorà u numeru di travagliadori di vacuum. Tuttu u mondu sa chì hè l'autovacuum in PostgreSQL? Questu hè un sottosistema interessante in PostgreSQL. Parechji articuli sò stati scritti nantu à questu, parechji rapporti sò stati fatti. Parechje discussioni nantu à u vacuum, cumu si deve travaglià. Parechje consideranu un male necessariu. Ma hè. Questu hè un tipu di cullizzioni di basura chì pulisce e versioni obsoleti di fila chì ùn sò micca necessarii da alcuna transazzione è libera spaziu in tavule è indici per e fila novi.
Perchè deve esse monitoratu? Perchè u vacuum à volte face assai male. Cunsumeghja una grande quantità di risorse è e richieste di i clienti cumincianu à soffre di questu.
È deve esse monitoratu per mezu di a vista pg_stat_activity, di quale parleraghju in a sezione dopu. Questa vista mostra l'attività attuale in a basa di dati. È attraversu sta attività, pudemu seguità u numeru di vacuums chì travaglianu avà. Pudemu monitorà i vacuums è vede chì se avemu superatu u limitu, allora questu hè l'occasione di guardà in i paràmetri PostgreSQL è in qualchì manera ottimisà l'operazione di u vacuum.
Una altra caratteristica di PostgreSQL hè chì PostgreSQL hè assai malatu di transazzioni longu. In particulare, da e transazzione chì pende per un bellu pezzu è ùn facenu nunda. Quessi sò i chjamati stat idle-in-transaction. Una tale transazzione cuntene chjusi, impedisce à u vacuum di travaglià. È com'è u risultatu - i tavulini si stende, aumentanu in grandezza. E dumande chì travaglianu cù sti tavulini, cumincianu à travaglià più lentamente, perchè avete bisognu di sparà tutte e versioni antichi di fila da a memoria à u discu è torna. Per quessa, u tempu, a durazione di e transazzioni più longu, e richieste di vacuum più longu deve esse monitoratu. E s'è no vemu qualchi prucessi chì sò stati in esecuzione per un tempu assai longu, per più di 10-20-30 minuti per una carica OLTP, allora avemu bisognu di attentu à elli è furzà à finisce, o ottimisate l'applicazione in modu chì ùn sò micca chjamati è ùn pende micca tantu longu. Per una carica analitica, 10-20-30 minuti hè normale, ci sò ancu più longu.
Dopu avemu l'opzione cù i clienti cunnessi. Quandu avemu digià furmatu un dashboard, publicatu metriche di accessibilità chjave nantu à questu, pudemu ancu aghjunghje infurmazioni supplementari nantu à i clienti cunnessi quì.
L'infurmazione nantu à i clienti cunnessi hè impurtante perchè, da u puntu di vista di PostgreSQL, ci sò diversi tipi di clienti. Ci sò boni clienti è ci sò cattivi clienti.
Un esempiu simplice. Per cliente, vogliu dì l'applicazione. L'applicazione hà cunnessu à a basa di dati è immediatamente cumencia à mandà e so dumande quì, a basa di dati processa è eseguisce, è torna i risultati à u cliente. Quessi sò clienti boni è ghjusti.
Ci sò situazioni chì u cliente hè cunnessu, mantene a cunnessione, ma ùn faci nunda. Hè in u statu inattivu.
Ma ci sò clienti cattivi. Per esempiu, u stessu cliente cunnessu, hà apertu una transazzione, hà fattu qualcosa in a basa di dati, è andò in u codice, per esempiu, per accede à una fonte esterna o per processà e dati ricivuti. Ma à u stessu tempu, ùn hà micca chjusu a transazzione. È a transazzione pende in a basa di dati è mantene a serratura nantu à a linea. Questu hè un cattivu statu. È s'ellu di colpu l'applicazione in un locu in ellu casca da una eccezzioni (Eccezione), allora a transazzione pò esse aperta per un tempu assai longu. È questu affetta direttamente u rendiment di PostgreSQL. PostgreSQL correrà più lentamente. Per quessa, hè impurtante di seguità tali clienti in u tempu è finisce u so travagliu in forza. È avete bisognu di ottimisà a vostra applicazione per chì ùn ci sò micca tali situazioni.
Altri clienti cattivi aspettanu clienti. Ma diventanu cattivi per via di e circustanze. Per esempiu, una transazzione simplice inattivu: pò apre una transazzione, piglià chjusi nantu à qualchi linea, poi cascarà in un locu in u codice, lascendu una transazzione appesa. Un altru clientu vinarà, dumandà a stessa dati, ma scontru un serratura, perchè quella transazzione appesa detene già serrature in qualchi fila necessaria. È a seconda transazzione penderà in anticipazione quandu a prima transazzione hè cumpleta o u so amministratore a chjude per forza. Cusì, e transazzioni pendenti ponu accumulà è sopra à u limitu di cunnessione di basa di dati. È quandu u limitu hè pienu, l'applicazione ùn pò più travaglià cù a basa di dati. Questa hè digià una situazione d'emergenza per u prugettu. Dunque, i clienti cattivi anu da esse tracciati è risposti in una manera puntuale.
Un altru esempiu di surviglianza. È quì hè un dashboard decentu. Ci hè infurmazione nantu à e cunnessione da sopra. Cunnessione DB - 8 pezzi. È hè tuttu. Ùn avemu micca infurmazione nantu à quali clienti sò attivi, quali clienti sò solu inattivi, senza fà nunda. Ùn ci hè micca infurmazione nantu à e transazzioni pendenti è e cunnessione pendenti, vale à dì questu hè una figura chì mostra u numeru di cunnessione è hè questu. E poi indovinà per sè stessu.
Per quessa, per aghjunghje sta informazione à u monitoraghju, avete bisognu di riferite à a vista di u sistema pg_stat_activity. Se passate assai tempu in PostgreSQL, questu hè una vista assai bona chì deve diventà u vostru amicu, perchè mostra l'attività attuale in PostgreSQL, vale à dì ciò chì succede in questu. Ci hè una linea separata per ogni prucessu chì mostra l'infurmazioni nantu à questu prucessu: da quale host hè stata fatta a cunnessione, sottu quale utilizatore, sottu quale nome, quandu a transazzione hè stata iniziata, quale dumanda hè attualmente eseguita, quale dumanda hè stata eseguita l'ultima. È, dunque, pudemu evaluà u statu di u cliente da u campu di stat. Relativamente parlante, pudemu raggruppà per questu campu è uttene quelli stats chì sò avà in a basa di dati è u numeru di cunnessione chì sò cù questa stat in a basa di dati. È pudemu mandà i numeri digià ricevuti à u nostru monitoraghju è tracciate grafici nantu à elli.
Hè impurtante ancu di valutà a durata di a transazzione. Aghju digià dettu chì hè impurtante per evaluà a durata di u vacuums, ma e transazzione sò ancu evaluate in u listessu modu. Ci sò campi xact_start è query_start. Anu, relativamente parlante, mostranu l'ora di iniziu di a transazzione è l'ora di iniziu di a dumanda. Pigliemu a funzione now() , chì mostra u timestamp attuale, è sottrae a transazzione è dumandate timestamps. È avemu a durazione di a transazzione, a durata di a dumanda.
Se vedemu transazzioni longu, duvemu cumpiendu dighjà. Per una carica OLTP, e transazzioni longu sò digià più di 1-2-3 minuti. Per una carica OLAP, e transazzioni longu sò nurmali, ma s'ellu ci sò più di duie ore, allora questu hè ancu un signu chì avemu un skew in qualchì locu.
Una volta chì i clienti anu cunnessu à a basa di dati, cumincianu à travaglià cù i nostri dati. Accedenu à e tavule, accede à l'indici per ottene dati da una tavula. È hè impurtante per evaluà cumu i clienti travaglianu cù questi dati.
Questu hè necessariu per valutà a nostra carica di travagliu è apprussimatamente capisce quale tavule avemu u "più caldu". Per esempiu, questu hè necessariu in situazioni induve vulemu pusà tavule "caldi" nantu à qualchì tipu di almacenamiento SSD veloce. Per esempiu, certi tavule d'archiviu chì ùn avemu micca utilizatu per un bellu pezzu pò esse trasferitu à qualchì tipu d'archiviu "frid", à i dischi SATA è lasciate campà quì, seranu accessu cumu necessariu.
Hè ancu utile per a deteczione di anomalie dopu ogni versione è implementazione. Diciamu chì u prugettu hà sviluppatu una nova funzione. Per esempiu, avemu aghjustatu una nova funziunalità per travaglià cù a basa di dati. È se custruemu grafici per l'usu di tavule, pudemu facilmente detectà sti anomalie nantu à sti grafici. Per esempiu, aghjurnà bursts o sguassà bursts. Serà assai visibile.
Hè ancu pussibule di detect anomalie di statistiche "floated". Cosa significa? PostgreSQL hà un pianificatore di query assai forte è assai bonu. È i sviluppatori dedicanu assai tempu à u so sviluppu. Cumu travaglia ? Per custruisce boni piani, PostgreSQL recullà statistiche nantu à a distribuzione di dati in tavule cù un certu intervallu di tempu, cù una certa periodicità. Quessi sò i valori più frequenti: u numeru di valori unichi, infurmazione nantu à NULL in a tavula, assai infurmazione.
Basatu annantu à queste statistiche, u pianificatore crea parechje dumande, sceglie u più ottimale, è usa stu pianu di dumanda per eseguisce a dumanda stessu è rinvià e dati.
È succede chì e statistiche "float". A qualità è a quantità di dati anu cambiatu in qualchì modu in a tavula, ma e statistiche ùn sò micca raccolte. È i piani furmati pò esse micca ottimali. È se i nostri piani diventanu suboptimali in quantu à u monitoraghju chì sò cullati, sicondu i tavule, pudemu vede sti anomalie. Per esempiu, in qualchì locu a dati hà cambiatu qualitativamente è invece di l'indici, un passaghju sequenziale attraversu a tavula hà cuminciatu à esse utilizatu, i.e. se a dumanda deve vultà solu fila 100 (ci hè un limitu di 100), allora una enumerazione cumpleta serà realizata per sta dumanda. È questu sempre hà un effettu assai cattivu nantu à u rendiment.
È pudemu vede in u monitoraghju. E digià fighjate sta dumanda, eseguite spiegà per ella, recullate statistiche, custruite un novu indice supplementu. È digià risponde à stu prublema. Dunque hè impurtante.
Un altru esempiu di surviglianza. Pensu chì assai persone u ricunnoscenu perchè hè assai populari. Chi usa in i so prughjetti ? E quale usa stu pruduttu in cunghjunzione cù Prometheus? U fattu hè chì in u repositoriu standard di stu monitoraghju ci hè un dashboard per travaglià cù PostgreSQL - Prumeteu. Ma ci hè un dettagliu cattivu quì.
Ci sò parechje carte. È i bytes sò specificati cum'è unità, vale à dì chì ci sò 5 gràfici. Quessi sò Insert data, Update data, Elimina data, Fetch data è Return data. I byte sò specificati cum'è a dimensione di unità. Ma u fattu hè chì e statistiche in PostgreSQL torna dati in tuple (file). E, per quessa, sti gràfiche sò un modu assai bonu per sottovalutà a vostra carica di travagliu parechje volte, decine di volte, perchè una tupla ùn hè micca un byte, una tupla hè una stringa, hè assai byte è hè sempre di lunghezza variabile. Vale à dì, calculà a carica di travagliu in byte cù tuples hè un compitu irrealisticu o assai difficiule. Dunque, quandu aduprate un dashboard o un monitoraghju integratu, hè sempre impurtante di capisce chì u travagliu currettamente è vi restituite dati valutati currettamente.
Cumu uttene statistiche nantu à sti tavulini? Per fà questu, PostgreSQL hà una famiglia di vista. È a vista principale hè . User_tables - questu significa chì e tavule sò create in nome di l'utilizatore. In cuntrastu, ci sò viste di u sistema, chì sò utilizati da PostgreSQL stessu. È ci hè una tabella riassuntu Alltables, chì include u sistema è l'utilizatori. Pudete principià da qualsiasi di elli chì ti piace più.
I campi sopra ponu esse usatu per valutà u numeru di inserimenti, aghjurnamenti è sguassati. U dashboard d'esempiu chì aghju utilizatu usa questi campi per evaluà e caratteristiche di a carica di travagliu. Dunque, pudemu ancu custruisce nantu à elli. Ma vale a pena ricurdà chì questi sò tuples, micca byte, cusì ùn pudemu micca piglià è fà byte.
Basatu nantu à sti dati, pudemu custruisce i chjamati TopN-tables. Per esempiu, Top-5, Top-10. È pudete tene traccia di quelli tavulini caldi chì sò utilizati più cà l'altri. Per esempiu, 5 tavule "caldi" per inserimentu. E sicondu questi TopN-tables, valutemu a nostra carica di travagliu è pudemu valutà i bursts of workload after any releases and updates, and deployments.
Hè impurtante ancu di valutà a dimensione di a tavula, perchè qualchì volta i sviluppatori stendenu una nova funzione, è i nostri tavulini cumincianu à gonfià in i so grandi dimensioni, perchè anu decisu di aghjunghje una quantità addiziale di dati, ma ùn anu micca predichendu cumu questu. influenza a dimensione di a basa di dati. Tali casi sò ancu sorpresi per noi.
È avà una piccula dumanda per voi. Chì ci hè a quistione quandu avete a carica nantu à u servitore di basa di dati? Chì ghjè a vostra prossima dumanda ?
Ma a vera quistione hè a seguente. Chì dumanda causa a carica? Questu hè, ùn hè micca interessante per fighjà i prucessi chì a carica causa. Hè chjaru chì se l'ospite hè cun una basa di dati, allora a basa di dati hè in esecuzione quì è hè chjaru chì solu e basa di dati seranu disposti quì. Se apremu Top, vedemu una lista di prucessi PostgreSQL chì facenu qualcosa. Da Top ùn serà micca chjaru ciò chì facenu.
Per quessa, avete bisognu di truvà e dumande chì causanu a più carica, perchè a sintonizazione di query, in regula, dà più prufittu chè a cunfigurazione PostgreSQL o l'accordu di u sistema operatore, o ancu l'accordu di hardware. Sicondu a mo stima, questu hè circa 80-85-90%. È questu hè fattu assai più veloce. Hè più veloce per correggerà a dumanda chì per correggerà a cunfigurazione, pianificà un reiniciu, soprattuttu se a basa di dati ùn pò esse riavviata, o aghjunghje hardware. Hè più faciule per riscrive a dumanda in qualchì locu o aghjunghje un indexu per ottene un risultatu megliu da sta dumanda.
In cunsiquenza, hè necessariu di monitorà e dumande è a so adattazione. Pigliemu un altru esempiu di surviglianza. È quì, ancu, pare esse un surviglianza eccellente. Ci hè infurmazione nantu à a replicazione, ci hè infurmazione nantu à u throughput, u bluccatu, l'utilizazione di risorse. Tuttu hè bè, ma ùn ci hè micca infurmazione nantu à e dumande. Ùn hè micca chjaru chì e dumande sò in esecuzione in a nostra basa di dati, quantu duranu, quante di queste dumande. Avemu bisognu di avè sempre sta infurmazione in u monitoraghju.
È per uttene sta infurmazione, pudemu usà u modulu pg_stat_statements. In a so basa, pudete custruisce una varietà di gràfiche. Per esempiu, pudete piglià infurmazione nantu à e dumande più frequenti, vale à dì, nantu à e dumande chì sò realizati più spessu. Iè, dopu a implementazione hè ancu assai utile per fighjà è capisce s'ellu ci hè una crescita in e dumande.
Pudete monitorà e dumande più longu, vale à dì quelle richieste chì piglianu u più longu per compie. Eseguinu nantu à u processatore, cunsumanu I / O. Pudemu ancu evaluà questu da i campi total_time, mean_time, blk_write_time è blk_read_time.
Pudemu evaluà è monitorà e richieste più pesanti in quantu à l'usu di risorse, quelli chì leghjenu da u discu, quelli chì travaglianu cù memoria, o, à u cuntrariu, creanu un tipu di carica di scrittura.
Pudemu valutà e dumande più generose. Quessi sò e dumande chì tornanu un gran numaru di fila. Per esempiu, pò esse un tipu di dumanda induve anu scurdatu di stabilisce un limitu. È torna solu u cuntenutu sanu sanu di a tavula o dumanda nantu à e tavule richieste.
È pudete ancu monitorà e dumande chì utilizanu schedarii tempuranee o tavule tempuranee.
È avemu sempre prucessi di fondo. I prucessi di fondo sò principarmenti checkpoints o sò ancu chjamati checkpoints, questi sò autovacuum è replicazione.
Un altru esempiu di surviglianza. Ci hè una tabulazione di Manutenzione à a manca, andate à ellu è sperate di vede qualcosa d'utile. Ma quì, solu u tempu di u vacuum è a cullizzioni di statistiche, nunda di più. Questa hè una infurmazione assai povera, cusì avete sempre bisognu d'avè infurmazione nantu à cumu i prucessi di fondo funzionanu in a nostra basa di dati è s'ellu ci sò prublemi da u so travagliu.
Quandu guardemu i punti di cuntrollu, deve esse ricurdatu chì i nostri punti di cuntrollu sguassate e pagine "sporche" da l'area di memoria sharded à u discu, poi creanu un puntu di cuntrollu. È questu puntu di cuntrollu pò esse digià usatu cum'è un locu durante a ricuperazione, se PostgreSQL hè stata terminata di colpu in una emergenza.
Per quessa, per sguassà tutte e pagine "spurte" à u discu, avete bisognu di fà una certa quantità di scrittura. È, in regula, in sistemi cù una grande quantità di memoria, questu hè assai. È se facemu punti di cuntrollu assai spessu in qualchì intervallu brevi, allora u rendiment di u discu scenderà assai. È e richieste di i clienti soffrenu di una mancanza di risorse. Cumpeteranu per risorse è mancanu a produtividade.
Per quessa, attraversu pg_stat_bgwriter nantu à i campi specificati, pudemu monitorà u numeru di punti di cuntrollu chì si trovanu. È s'ellu avemu assai checkpoints per un certu periodu di tempu (per 10-15-20 minuti, per una meza ora), per esempiu, 3-4-5, allura questu pò esse digià un prublema. È avete digià bisognu di circà in a basa di dati, fighjate in a cunfigurazione, ciò chì provoca una tale abbundanza di punti di cuntrollu. Forse vene un grande record. Pudemu digià evaluà a carica di travagliu, perchè avemu digià aghjuntu charts di carichi di travagliu. Pudemu digià aghjustà i paràmetri di breakpoint è assicuratevi chì ùn anu micca assai influenza in u rendiment di a dumanda.
Vulteraghju di novu à l'autovacuum perchè hè u tipu di cosa, cum'è aghju dettu, chì ponu facilmente aghjunghje u performance di u discu è di a dumanda, cusì hè sempre impurtante per misurà a quantità di autovacuum.
U numaru di travagliadori autovacuum in a basa di dati hè limitatu. Per automaticamente, ci sò trè, perchè s'ellu avemu trè travagliadori chì travaglianu in a basa di dati tuttu u tempu, allora questu significa chì u nostru autovacuum hè sottoconfiguratu, avemu bisognu di elevà i limiti, rivisione i paràmetri di l'autovacuum è digià cullà in a cunfigurazione.
Hè impurtante di valutà quale travagliadori di vacuum travaglianu per noi. Sia hè stata lanciata da l'utilizatore, u DBA hè ghjuntu è hà lanciatu un tipu di vacuum cù e so mani, è questu hà creatu una carica. Avemu qualchì prublema. O questu hè u numeru di vacuums chì unscrew u contatore di transazzione. Per alcune versioni di PostgreSQL, questi sò vacuums assai pesanti. È ponu facilmente aghjunghje prestazioni perchè sò sottratte tutta a tavola, scannendu tutti i blocchi in questa tabella.
E, sicuru, a durata di i vacuums. Se avemu longu vacuums chì currenu per un tempu assai longu, allora questu significa chì duvemu torna attente à a cunfigurazione di u vacuum è forsi ricunsiderà i so paràmetri. Perchè una situazione pò esse quandu u vacuum travaglia nantu à a tavula per un bellu pezzu (3-4 ore), ma durante u travagliu di u vacuum, una grande quantità di fila morta hà riisciutu à accumulà in a tavula. È appena u vacuum hè finitu, hà bisognu à aspirate sta tavola di novu. È ghjunghjemu à una situazione - un vacuum infinitu. È in questu casu, u vacuum ùn face micca cù u so travagliu, è i tavulini cumincianu à sbulicà gradualmente in grandezza, ancu s'ellu a quantità di dati utili in questu ferma u listessu. Per quessa, in vacuums longu, avemu sempre guardà a cunfigurazione è pruvate d'ottimisimu, ma à u stessu tempu, per chì u rendiment di e dumande di u cliente ùn soffre micca.
Avà ùn ci hè praticamenti micca installazione PostgreSQL induve ùn ci era micca replicazione in streaming. A replicazione hè u prucessu di trasferimentu di dati da un maestru à una replica.
A replicazione in PostgreSQL hè disposta per mezu di un logu di transazzione. U maestru genera un logu di transazzione. U logu di transazzione nantu à a cunnessione di a rete va à a replica, dopu hè riproduce nantu à a replica. Tuttu hè simplice.
Per quessa, a vista pg_stat_replication hè aduprata per monitorizà u lag di replicazione. Ma ùn hè micca faciule per ella. In a versione 10, a vista hà subitu parechji cambiamenti. Prima, alcuni di i campi sò stati rinominati. E alcuni di i campi sò stati aghjuntu. In a 10a versione, i campi apparsu chì permettenu di evaluà u lag di replicazione in seconde. Hè assai còmode. Prima di a versione 10, era pussibule stimà u lag di replicazione in bytes. Questa funzione hè stata in a 10a versione, vale à dì chì pudete sceglie ciò chì hè più cunvene per voi - evaluate u lag in bytes o evaluate u lag in seconde. Parechji facenu tramindui.
In ogni casu, per evaluà u lag di replicazione, avete bisognu di cunnosce a pusizione di u log in a transazzione. E queste pusizioni di u logu di transazzione sò solu in a vista pg_stat_replication. Relativamente parlante, pudemu usà a funzione pg_xlog_location_diff () per piglià dui punti in u logu di transazzione. Calculate u delta trà elli è uttene u lag di replicazione in byte. Hè assai còmuda è simplice.
In a versione 10 sta funzione hè stata rinominata pg_wal_lsn_diff (). In generale, in tutte e funzioni, vista, utilità, induve a parolla "xlog" hè stata scontru, hè stata rimpiazzata cù u valore "wal". Questu hè sia in vede è in funzioni. Questa hè una tale innovazione.
In più, in a 10a versione, i linii sò stati aghjuntu chì mostranu specificamente u lag. Quessi sò scrive lag, flush lag, replay lag. Hè per quessa, hè impurtante di monitorà queste cose. Se vedemu chì avemu un lag di replicazione, allora avemu bisognu di investigà perchè hè apparsu, da induve hè vinutu è risolve u prublema.
Cù metrica di u sistema, quasi tuttu hè in ordine. Quandu ogni surviglianza hè natu, principia cù metrica di u sistema. Questu hè l'utilizazione di processori, memoria, swap, rete è discu. Ma in ogni modu, parechji paràmetri ùn sò micca quì per difettu.
Sè tuttu hè in ordine cù a dispusizione di u prucessu, allura ci sò prublemi cù a dispusizione di u discu. In regula, i sviluppatori di monitoraghju aghjunghjenu l'infurmazioni di larghezza di banda. Pò esse in iops o byte. Ma si scurdanu di a latenza è di l'utilizazione di u discu. Quessi sò paràmetri più impurtanti chì permettenu di valutà quantu sò caricati i nostri dischi è quantu rallentanu. Se avemu una latenza alta, questu significa chì ci sò parechji prublemi cù i dischi. Se avemu un altu usu, allora questu significa chì i dischi ùn ponu micca affruntà. Quessi sò carattiristichi più qualitativi cà a larghezza di banda.
Tuttavia, sti statistiche ponu ancu esse ottenute da u sistema di fugliale /proc, cum'è hè fattu per u riciclamentu di u processatore. Perchè sta informazione ùn hè micca aghjuntu à u monitoraghju, ùn sò micca. Ma hè sempre impurtante di avè in u vostru monitoraghju.
U stessu hè veru per l'interfaccia di rete. Ci hè infurmazione nantu à a larghezza di banda di a rete in pacchetti, in byte, ma ùn ci hè micca infurmazione nantu à a latenza è micca infurmazione nantu à l'utilizazione, ancu s'ellu hè ancu infurmazione utile.
Ogni monitoraghju hà i so inconvenienti. È ùn importa micca u tipu di surviglianza chì pigliate, ùn sempre falla à scuntrà certi criteri. Ma in ogni casu, si sviluppanu, sò aghjuntu novi funziunalità, cose novi, cusì sceglite qualcosa è finisce.
È per finisce, duvete sempre avè una idea di ciò chì significanu e statistiche date è cumu pudete risolve i prublemi cun ella.
È uni pochi di punti chjave:
- Avete sempre bisognu di monitorà a dispunibilità, avè dashboards per pudè valutà rapidamente chì tuttu hè in ordine cù a basa.
- Avete sempre bisognu di avè una idea di ciò chì i clienti travaglianu cù a vostra basa di dati per sguassà i clienti cattivi è spararli.
- Hè impurtante per evaluà cumu questi clienti travaglianu cù dati. Avete bisognu di avè una idea di a vostra carica di travagliu.
- Hè impurtante di valutà cumu si forma sta carica di travagliu, cù l'aiutu di quale dumande. Pudete valutà e dumande, pudete ottimisimu, refactor, custruisce indici per elli. Hè assai impurtante.
- I prucessi di sfondate ponu avè un impattu negativu nantu à e richieste di i clienti, per quessa, hè impurtante per assicurà chì ùn anu micca aduprà troppu risorse.
- A metrica di u sistema permette di fà piani di scaling, per aumentà a capacità di i vostri servitori, per quessa hè impurtante di seguità è evaluà ancu.
Sè site interessatu in questu tema, pudete seguità questi ligami.
hè a documentazione ufficiale da u cullettore di statistiche. Ci hè una descrizzione di tutte e viste statistiche è una descrizzione di tutti i campi. Pudete leghje, capisce è analizà. È nantu à a basa di elli, custruite i vostri charts, aghjunghje à u vostru monitoraghju.
Richiede esempi:
Questu hè u nostru repositoriu corporativu è u mo propiu. Hanu dumande di mostra. Ùn ci hè micca dumande da a selezzione * da a serie, qualcosa quì. Ci sò digià dumande pronti cù unizzioni, utilizendu funzioni interessanti chì permettenu di fà leghjite, valori convenienti da i numeri crudi, vale à dì, questi sò bytes, tempu. Pudete sceglie, fighjate, analizà, aghjunghje à i vostri monitori, custruiscenu i vostri monitori basati nantu à elli.
I vostri dumanni
Quistione: Avete dettu chì ùn avete micca publicità marchi, ma mi dumandu sempre - chì tipu di dashboards aduprate in i vostri prughjetti?
Risposta: In diverse manere. Succede chì venemu à u cliente è hà digià u so propiu monitoraghju. È cunsigliemu à u cliente nantu à ciò chì deve esse aghjuntu à u so monitoraghju. A situazione peghju hè cù Zabbix. Perchè ùn hà micca a capacità di custruisce TopN-graphics. Noi stessi usemu perchè avemu cunsultatu sti picciotti nantu à u monitoraghju. Hanu fattu un monitoraghju PostgreSQL basatu annantu à u nostru TOR. Scrivu u mo propiu prughjettu per animali domestici, chì raccoglie dati attraversu Prometheus è l'attrae . U mo compitu hè di fà u mo propiu esportatore in Prometheus è dopu disegnà tuttu in Grafana.
Quistione: Ci sò analoghi di rapporti AWR o ... aggregazioni? Sapete qualcosa cusì ?
Risposta: Iè, sò ciò chì AWR hè, hè una cosa bella. À u mumentu, ci sò una varietà di biciclette chì implementanu circa u mudellu seguente. À qualchì intervallu di tempu, certi basi sò scritti à u stessu PostgreSQL o à un almacenamentu separatu. Pudete google nantu à Internet, sò. Unu di i sviluppatori di una tale cosa si trova nantu à u foru sql.ru in u filu PostgreSQL. Pudete catturà quì. Iè, ci sò tali cose, ponu esse usatu. plus in u so Scrivu ancu una cosa chì vi permette di fà u listessu.
PS1 Sè vo aduprate postgres_exporter, chì dashboard usate? Ci sò parechji di elli. Sò digià obsoleti. A cumunità pò creà un mudellu aghjurnatu?
PS2 Eliminatu pganalyze perchè hè un'offerta SaaS proprietaria chì si concentra in u monitoraghju di u rendiment è i suggerimenti di sintonizazione automatizata.
Solu l'utilizatori registrati ponu participà à l'indagine. , per piacè.
Quale monitoraghju postgresql self-hosted (cù dashboard) pensate chì hè u megliu?
-
30,0%Zabbix + aggiunte da Alexey Lesovsky o zabbix 4.4 o 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 hè un SaaS proprietariu - ùn pò micca sguassà1
-
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 utilizatori anu vutatu. 26 utilizatori si sò astenuti.
Source: www.habr.com