Conceptes bàsics de monitorització de PostgreSQL. Alexei Lesovski

Us suggereixo que llegiu la transcripció de l'informe d'Alexei Lesovsky de Data Egret "Funcions bàsiques de la supervisió de PostgreSQL"

En aquest informe, Alexey Lesovsky parlarà dels punts clau de les estadístiques de postgres, què volen dir i per què s'han d'incloure en el seguiment; sobre quins gràfics haurien d'haver en el seguiment, com afegir-los i com interpretar-los. L'informe serà útil per als administradors de bases de dades, administradors de sistemes i desenvolupadors que estiguin interessats en la resolució de problemes de Postgres.

Em dic Alexey Lesovsky, represento Data Egret.

Unes paraules sobre mi mateix. Vaig començar fa molt de temps com a administrador del sistema.

Vaig administrar tot tipus de Linux diferents, vaig fer diverses coses relacionades amb Linux, és a dir, virtualització, monitorització, vaig treballar amb proxies, etc. Però en algun moment em vaig involucrar més en bases de dades, PostgreSQL. Em va agradar molt. I en algun moment, vaig començar a tractar amb PostgreSQL la major part del meu temps de treball. I així, a poc a poc, em vaig convertir en un DBA de PostgreSQL.

I al llarg de la meva carrera, sempre m'han interessat els temes de l'estadística, el seguiment, la telemetria. I quan era administrador del sistema, vaig treballar molt dur en Zabbix. I va escriure un petit conjunt de guions com zabbix-extensions. Va ser força popular a la seva època. I allà es va poder controlar coses importants molt diferents, no només Linux, sinó també diversos components.

Ara ja estic fent PostgreSQL. Ja estic escrivint una altra cosa que et permet treballar amb estadístiques PostgreSQL. Es diu pgCenter (article sobre Habré - Estadística de Postgres sense nervis i tensió).

Una petita introducció. Quines són les situacions amb els nostres clients, amb els nostres clients? Hi ha algun tipus d'accident associat a la base de dades. I quan la base de dades ja s'ha restaurat, ve el cap de departament o el cap de desenvolupament i diu: "Amics, hem de vigilar la base de dades, perquè ha passat alguna cosa dolenta i és necessari que això no passi en el futur". I aquí comença l'interessant procés d'escollir un sistema de monitorització o adaptar un sistema de monitoratge existent perquè pugueu monitoritzar la vostra base de dades - PostgreSQL, MySQL o alguns altres. I els companys comencen a oferir: “He sentit que hi ha tal o tal base de dades. Utilitzem-lo". Els companys comencen a discutir entre ells. I al final resulta que escollim algun tipus de base de dades, però el monitoratge de PostgreSQL hi està força dèbilment representat i sempre hem d'acabar alguna cosa. Agafeu alguns repositoris de GitHub, cloneu-los, adapteu els scripts, ajusteu-los d'alguna manera. I al final cau en una mena de treball manual.

Per tant, en aquest informe, intentaré donar-vos alguns coneixements sobre com triar el monitoratge no només per a PostgreSQL, sinó també per a la base de dades. I donar els coneixements que us permetran finalitzar el vostre seguiment per treure'n algun benefici, de manera que pugueu supervisar amb benefici la vostra base de dades per tal d'evitar les properes situacions d'emergència que puguin sorgir a temps.

I aquelles idees que hi haurà en aquest informe, es poden adaptar directament a qualsevol base de dades, ja sigui un DBMS o noSQL. Per tant, no només aquí PostgreSQL, sinó que hi haurà moltes receptes sobre com fer-ho a PostgreSQL. Hi haurà exemples de consultes, exemples d'entitats que PostgreSQL té per supervisar. I si el vostre SGBD té les mateixes coses que us permeten posar-les en monitorització, també podeu adaptar-les, afegir-les i anirà bé.

No denunciaré
parlar sobre com lliurar i emmagatzemar mètriques. No diré res sobre el post-processament de les dades i el subministrament a l'usuari. I no diré res sobre l'alerta.
Però al llarg de la història, mostraré diferents captures de pantalla de monitoratges existents, d'alguna manera les criticaré. No obstant això, intentaré no anomenar marques per no crear publicitat o antipublicitat per a aquests productes. Per tant, totes les coincidències són aleatòries i romanen en la vostra imaginació.

En primer lloc, entenem què és el seguiment. El seguiment és una cosa molt important a tenir. Tothom ho entén. Però al mateix temps, el seguiment no està relacionat amb un producte empresarial i no afecta directament els beneficis de l'empresa, de manera que el seguiment sempre es dóna temps de manera residual. Si tenim temps, ens dediquem al seguiment, si no hi ha temps, bé, ho posarem a l'endarreriment i algun dia tornarem a aquestes tasques.

Per tant, des de la nostra pràctica, quan arribem als clients, el monitoratge sovint està poc desenvolupat i no té coses interessants que ens ajudin a fer un millor treball amb la base de dades. I, per tant, el seguiment sempre s'ha d'acabar.

Les bases de dades són coses tan complexes que també cal supervisar, perquè les bases de dades són un dipòsit d'informació. I la informació és molt important per a l'empresa, no es pot perdre de cap manera. Però, al mateix temps, les bases de dades són peces de programari molt complexes. Estan formats per molts components. I molts d'aquests components s'han de controlar.

Si parlem específicament de PostgreSQL, es pot representar com a tal esquema, que consta d'un gran nombre de components. Aquests components interactuen entre si. I al mateix temps, PostgreSQL disposa de l'anomenat subsistema Col·lector d'estadístiques, que permet recopilar estadístiques sobre el funcionament d'aquests subsistemes i proporcionar una interfície a l'administrador o usuari perquè pugui visualitzar aquestes estadístiques.

Aquestes estadístiques es presenten en forma d'algun conjunt de funcions i vistes (visualització). També es poden anomenar taules. És a dir, amb un client psql normal, podeu connectar-vos a la base de dades, seleccionar aquestes funcions i vistes i obtenir alguns números específics sobre el funcionament dels subsistemes PostgreSQL.

Podeu afegir aquests números al vostre sistema de monitorització preferit, dibuixar gràfics, afegir funcions i obtenir analítiques a la llarga.

Però en aquest informe, no tractaré totes aquestes funcions sense excepció, perquè pot trigar un dia sencer. Em referiré literalment a dues, tres o quatre coses i us explicaré com ajuden a millorar el seguiment.

I si parlem de seguiment de la base de dades, què s'ha de controlar? En primer lloc, hem de fer un seguiment de la disponibilitat, perquè la base de dades és un servei que dóna accés a les dades als clients i hem de fer un seguiment de la disponibilitat, i també aportar algunes de les seves característiques qualitatives i quantitatives.

També hem de supervisar els clients que es connecten a la nostra base de dades, perquè poden ser tant clients normals com clients nocius que poden danyar la base de dades. També s'han de controlar i fer un seguiment.

Quan els clients es connecten a la base de dades, és obvi que comencen a treballar amb les nostres dades, per la qual cosa hem de controlar com els clients treballen amb les dades: amb quines taules, en menor mesura amb quins índexs. És a dir, hem d'avaluar la càrrega de treball que creen els nostres clients.

Però la càrrega de treball també consisteix, és clar, en peticions. Les aplicacions es connecten a la base de dades, accedeixen a les dades mitjançant consultes, per això és important avaluar quines consultes tenim a la base de dades, controlar-ne l'adequació, que no estiguin escrites malament, que cal reescriure algunes opcions i fer-les perquè funcionin més ràpid. i amb millor rendiment.

I com que estem parlant de la base de dades, la base de dades és sempre processos en segon pla. Els processos de fons mantenen el rendiment de la base de dades a un bon nivell, de manera que requereixen una certa quantitat de recursos per executar-se. I, al mateix temps, es poden solapar amb els recursos de sol·licitud del client, de manera que el treball cobdiciós dels processos en segon pla pot afectar directament el rendiment de les sol·licituds del client. Per tant, també s'han de supervisar i fer un seguiment perquè no hi hagi distorsions pel que fa als processos de fons.

I això és tot pel que fa a la vigilància de la base de dades a la mètrica del sistema. Però atès que, en la seva major part, tota la nostra infraestructura va als núvols, les mètriques del sistema d'un host individual sempre s'esvaeixen en segon pla. Però a les bases de dades encara són rellevants i, per descomptat, també cal controlar les mètriques del sistema.

Amb les mètriques del sistema, tot està més o menys bé, tots els sistemes de monitorització moderns ja admeten aquestes mètriques, però en general, alguns components encara no són suficients i cal afegir algunes coses. També els tocaré, diverses diapositives seran sobre ells.

El primer punt del pla és l'accessibilitat. Què és l'accessibilitat? La disponibilitat al meu entendre és la capacitat de la base per servir connexions, és a dir, la base s'eleva, com a servei, accepta connexions dels clients. I aquesta accessibilitat es pot valorar per algunes característiques. Aquestes característiques són molt convenients per mostrar als taulers de comandament.

Tothom sap què són els quadres de comandament. És quan vas donar un cop d'ull a la pantalla, que resumia la informació necessària. I ja podeu determinar immediatament si hi ha un problema a la base de dades o no.
En conseqüència, la disponibilitat de la base de dades i altres característiques clau s'han de posar sempre als taulers de control perquè aquesta informació estigui a mà, sempre amb tu. Alguns detalls addicionals que ja ajuden en la investigació d'incidències, en la investigació d'algunes situacions d'emergència, ja s'han de col·locar en taulers secundaris, o amagar-los en enllaços de desglossament que porten a sistemes de monitoratge de tercers.

Un exemple d'un sistema de control conegut. Aquest és un sistema de monitoratge molt interessant. Recull moltes dades, però des del meu punt de vista, té un estrany concepte de taulers. Hi ha un enllaç "Crea un tauler de control". Però quan creeu un tauler, creeu una llista de dues columnes, una llista de gràfics. I quan necessiteu mirar alguna cosa, comenceu a fer clic, a desplaçar-vos, a buscar el gràfic desitjat amb el ratolí. I això requereix temps, és a dir, no hi ha taulers com a tals. Només hi ha llistes de gràfics.

Què s'ha d'afegir a aquests quadres de comandament? Podeu començar amb una característica com ara el temps de resposta. PostgreSQL té la vista pg_stat_statements. Està desactivat per defecte, però és una de les vistes importants del sistema que sempre s'hauria d'habilitar i utilitzar. Emmagatzema informació sobre totes les consultes en execució que es van executar a la base de dades.

En conseqüència, podem partir del fet que podem prendre el temps total d'execució de totes les sol·licituds i dividir-lo pel nombre de sol·licituds utilitzant els camps anteriors. Però aquesta és una temperatura tan mitjana a l'hospital. Podem basar-nos en altres camps: el temps mínim d'execució de la consulta, el màxim i la mitjana. I fins i tot podem construir percentils, PostgreSQL té les funcions corresponents per a això. I podem obtenir alguns números que caracteritzen el temps de resposta de la nostra base de dades per a sol·licituds ja completades, és a dir, no executem la falsa sol·licitud "selecciona 1" i mirem el temps de resposta, sinó que analitzem el temps de resposta de les sol·licituds ja completades i dibuixem qualsevol de les dues. una figura a part, o construïm un gràfic a partir d'ella.

També és important fer un seguiment del nombre d'errors que el sistema està generant actualment. I per a això podeu utilitzar la vista pg_stat_database. Ens estem orientant al camp xact_rollback. Aquest camp no només mostra el nombre de retrocessos que es produeixen a la base de dades, sinó que també té en compte el nombre d'errors. Relativament parlant, podem mostrar aquesta xifra al nostre tauler i veure quants errors tenim en aquest moment. Si hi ha molts errors, això ja és un bon motiu per mirar els registres i veure quin tipus d'errors són i per què es produeixen, i després invertir-los i resoldre'ls.

Podeu afegir una cosa com un tacòmetre. Aquests són el nombre de transaccions per segon i el nombre de sol·licituds per segon. En termes relatius, podeu utilitzar aquests números com a rendiment actual de la vostra base de dades i observar si hi ha pics de sol·licituds, pics de transaccions o, per contra, la base de dades està poc carregada perquè s'ha caigut algun tipus de backend. És important mirar sempre aquesta xifra i recordar que per al nostre projecte aquest rendiment és normal, i els valors de dalt i de sota ja són una mena de problemàtics i incomprensibles, la qual cosa significa que hem de mirar per què aquests números. .

Per tal d'estimar el nombre de transaccions, podem tornar a consultar la vista pg_stat_database. Podem afegir el nombre de commits i el nombre de rollbacks per obtenir el nombre de transaccions per segon.

Tothom entén que diverses sol·licituds poden encaixar en una transacció? Per tant, TPS i QPS són lleugerament diferents.

El nombre de sol·licituds per segon es pot obtenir des de pg_stat_statements i només cal calcular la suma de totes les sol·licituds executades. Està clar que comparem el valor actual amb l'anterior, restem, obtenim el delta, obtenim la quantitat.

Podeu afegir mètriques addicionals si voleu, que també ajuden a avaluar la disponibilitat de la nostra base de dades i fer un seguiment de si hi va haver temps d'inactivitat.

Una d'aquestes mètriques és el temps de funcionament. Però el temps de funcionament a PostgreSQL és una mica complicat. Et diré per què. Quan s'inicia PostgreSQL, comença a informar del temps d'activitat. Però si en algun moment, per exemple, una tasca s'estava executant a la nit, va arribar un OOM-killer i va acabar per força el procés fill de PostgreSQL, aleshores, en aquest cas, PostgreSQL finalitza la connexió de tots els clients, restableix l'àrea de memòria fragmentada i comença la recuperació des de l'últim punt de control. I mentre duri aquesta recuperació del punt de control, la base de dades no accepta connexions, és a dir, aquesta situació es pot valorar com a temps d'inactivitat. Però això no restablirà el comptador de temps d'activitat, perquè té en compte el moment en què es va iniciar el director de correus des del primer moment. Per tant, aquestes situacions es poden saltar.

També hauríeu de controlar el nombre de treballadors del buit. Tothom sap què és l'autovacuum a PostgreSQL? Aquest és un subsistema interessant a PostgreSQL. S'han escrit molts articles sobre això, s'han fet molts informes. Molta discussió sobre el buit, com hauria de funcionar. Molts ho consideren un mal necessari. Pero es. Es tracta d'una mena de col·lector d'escombraries que neteja versions obsoletes de files que no són necessàries per cap de les transaccions i allibera espai en taules i índexs per a files noves.

Per què s'ha de controlar? Perquè el buit de vegades fa molt de mal. Consumeix una gran quantitat de recursos i les peticions dels clients comencen a patir-ho.

I s'hauria de controlar a través de la vista pg_stat_activity, de la qual parlaré a la següent secció. Aquesta vista mostra l'activitat actual a la base de dades. I a través d'aquesta activitat, podem fer un seguiment del nombre d'aspiradores que estan funcionant ara mateix. Podem controlar els buits i veure que si hem superat el límit, aquesta és una ocasió per mirar la configuració de PostgreSQL i optimitzar d'alguna manera el funcionament del buit.

Una altra característica de PostgreSQL és que PostgreSQL està molt fart de transaccions llargues. Sobretot, de transaccions que pengen durant molt de temps i no fan res. Aquests són els anomenats stat idle-in-transaction. Aquesta transacció té panys, impedeix que el buit funcioni. I com a resultat, les taules s'inflen, augmenten de mida. I les consultes que funcionen amb aquestes taules, comencen a funcionar més lentament, perquè cal treure totes les versions antigues de files de la memòria al disc i viceversa. Per tant, també cal controlar el temps, la durada de les transaccions més llargues i les sol·licituds de buit més llargues. I si veiem alguns processos que s'estan executant durant molt de temps, durant més de 10-20-30 minuts per a una càrrega OLTP, hem de prestar-hi atenció i obligar-los a finalitzar, o optimitzar l'aplicació perquè no es diuen i no es pengen tant de temps. Per a una càrrega analítica, 10-20-30 minuts és normal, també n'hi ha de més llargues.

A continuació tenim l'opció amb clients connectats. Quan ja hem format un tauler i hi hem publicat mètriques clau d'accessibilitat, també hi podem afegir informació addicional sobre els clients connectats.

La informació sobre clients connectats és important perquè, des del punt de vista de PostgreSQL, hi ha diferents tipus de clients. Hi ha bons clients i hi ha mals clients.

Un exemple senzill. Per client, em refereixo a l'aplicació. L'aplicació s'ha connectat a la base de dades i immediatament comença a enviar-hi les seves peticions, la base de dades les processa i executa i retorna els resultats al client. Aquests són clients bons i correctes.

Hi ha situacions en què el client està connectat, manté la connexió, però no fa res. Està en estat inactiu.

Però hi ha mals clients. Per exemple, el mateix client es va connectar, va obrir una transacció, va fer alguna cosa a la base de dades i després va entrar al codi, per exemple, per accedir a una font externa o per processar-hi les dades rebudes. Però, al mateix temps, no va tancar la transacció. I la transacció es penja a la base de dades i manté el bloqueig a la línia. Aquest és un mal estat. I si de sobte l'aplicació en algun lloc dins d'ella cau per una excepció (excepció), aleshores la transacció pot romandre oberta durant molt de temps. I això afecta directament el rendiment de PostgreSQL. PostgreSQL s'executarà més lentament. Per tant, és important fer un seguiment d'aquests clients a temps i finalitzar el seu treball per la força. I cal optimitzar la vostra aplicació perquè no hi hagi situacions d'aquest tipus.

Altres mals clients estan esperant clients. Però es tornen dolents per les circumstàncies. Per exemple, una simple transacció inactiva: pot obrir una transacció, bloquejar algunes línies, després caurà en algun lloc del codi, deixant una transacció pendent. Vindrà un altre client, demanarà les mateixes dades, però es trobarà amb un bloqueig, perquè aquesta transacció penjada ja té bloquejos en algunes files necessàries. I la segona transacció es penjarà anticipadament quan es completi la primera transacció o el seu administrador la tanqui per la força. Així, les transaccions pendents poden acumular i desbordar el límit de connexió de la base de dades. I quan el límit és ple, l'aplicació ja no pot funcionar amb la base de dades. Aquesta ja és una situació d'emergència per al projecte. Per tant, cal fer un seguiment dels clients dolents i respondre-hi de manera oportuna.

Un altre exemple de seguiment. I aquí hi ha un quadre de comandament decent. Hi ha informació sobre connexions des de dalt. Connexió DB - 8 peces. I és tot. No tenim informació sobre quins clients estan actius, quins clients estan inactius, sense fer res. No hi ha informació sobre transaccions pendents i connexions pendents, és a dir, aquesta és una xifra que mostra el nombre de connexions i ja està. I després endevina tu mateix.

En conseqüència, per afegir aquesta informació a la supervisió, cal que consulteu la vista del sistema pg_stat_activity. Si passeu molt de temps a PostgreSQL, aquesta és una molt bona vista que hauria de convertir-se en el vostre amic, perquè mostra l'activitat actual a PostgreSQL, és a dir, què hi passa. Hi ha una línia separada per a cada procés que mostra informació sobre aquest procés: des de quin host s'ha fet la connexió, sota quin usuari, amb quin nom, quan es va iniciar la transacció, quina sol·licitud s'està executant actualment, quina sol·licitud es va executar l'última. I, en conseqüència, podem avaluar l'estat del client mitjançant el camp d'estadístiques. Relativament parlant, podem agrupar per aquest camp i obtenir les estadístiques que ara es troben a la base de dades i el nombre de connexions que hi ha amb aquesta estadística a la base de dades. I podem enviar els números ja rebuts al nostre seguiment i dibuixar-hi gràfics.
També és important avaluar la durada de la transacció. Ja he dit que és important avaluar la durada dels buits, però les transaccions també s'avaluen de la mateixa manera. Hi ha camps xact_start i query_start. Relativament, mostren l'hora d'inici de la transacció i l'hora d'inici de la sol·licitud. Prenem la funció now(), que mostra la marca de temps actual, i restem les marques de temps de la transacció i la sol·licitud. I obtenim la durada de la transacció, la durada de la sol·licitud.

Si veiem transaccions llargues, ja les hauríem de completar. Per a una càrrega OLTP, les transaccions llargues ja són més d'1-2-3 minuts. Per a una càrrega OLAP, les transaccions llargues són normals, però si s'executen durant més de dues hores, això també és un senyal que tenim un esbiaixament en algun lloc.

Un cop els clients s'han connectat a la base de dades, comencen a treballar amb les nostres dades. Accedeixen a taules, accedeixen a índexs per obtenir dades d'una taula. I és important avaluar com treballen els clients amb aquestes dades.

Això és necessari per avaluar la nostra càrrega de treball i entendre aproximadament quines taules tenim les "més calentes". Per exemple, això és necessari en situacions en què volem col·locar taules "calentes" en algun tipus d'emmagatzematge SSD ràpid. Per exemple, algunes taules d'arxiu que no hem utilitzat des de fa molt de temps es poden transferir a algun tipus d'arxiu "fred", a discs SATA i deixar-los viure allí, s'hi accedirà segons sigui necessari.

També és útil per detectar anomalies després de qualsevol llançament i desplegament. Suposem que el projecte va llançar alguna característica nova. Per exemple, hem afegit una nova funcionalitat per treballar amb la base de dades. I si construïm gràfics per a l'ús de taules, podem detectar fàcilment aquestes anomalies en aquests gràfics. Per exemple, actualitzar ràfegues o suprimir ràfegues. Serà molt visible.

També és possible detectar anomalies de les estadístiques "flotades". Què vol dir? PostgreSQL té un planificador de consultes molt fort i molt bo. I els desenvolupadors dediquen molt de temps al seu desenvolupament. Com treballa? Per tal de construir bons plans, PostgreSQL recull estadístiques sobre la distribució de dades en taules amb un determinat interval de temps, amb certa periodicitat. Aquests són els valors més freqüents: el nombre de valors únics, informació sobre NULL a la taula, molta informació.

A partir d'aquestes estadístiques, el planificador crea diverses consultes, tria la més òptima i utilitza aquest pla de consultes per executar la consulta i retornar dades.

I passa que les estadístiques "floten". Les dades de qualitat i quantitat van canviar d'alguna manera a la taula, però les estadístiques no es van recollir. I els plans formats poden no ser òptims. I si els nostres plans resulten subòptims pel que fa al seguiment que es recull, segons les taules, podrem veure aquestes anomalies. Per exemple, en algun lloc les dades van canviar qualitativament i en lloc de l'índex, es va començar a utilitzar un pas seqüencial per la taula, és a dir. si la consulta només ha de retornar 100 files (hi ha un límit de 100), es realitzarà una enumeració completa per a aquesta consulta. I això sempre té un efecte molt dolent en el rendiment.

I ho podem veure en el seguiment. I ja mireu aquesta consulta, feu-ne una explicació, recopilau estadístiques, creeu un nou índex addicional. I ja respon a aquest problema. Per tant és important.

Un altre exemple de seguiment. Crec que molta gent el reconeix perquè és molt popular. Qui utilitza en els seus projectes Prometeu? I qui utilitza aquest producte juntament amb Prometheus? El fet és que al repositori estàndard d'aquest seguiment hi ha un tauler per treballar amb PostgreSQL - postgres_exporter Prometeu. Però aquí hi ha un mal detall.

Hi ha diversos gràfics. I els bytes s'especifiquen com a unitat, és a dir, hi ha 5 gràfics. Aquests són Insereix dades, Actualitza dades, Suprimeix dades, Recupera dades i Retorna dades. Els bytes s'especifiquen com a dimensió de la unitat. Però el fet és que les estadístiques de PostgreSQL retornen dades en tupla (files). I, en conseqüència, aquests gràfics són una molt bona manera de subestimar la vostra càrrega de treball diverses vegades, desenes de vegades, perquè una tupla no és un byte, una tupla és una cadena, és molts bytes i sempre és de longitud variable. És a dir, calcular la càrrega de treball en bytes mitjançant tuples és una tasca poc realista o molt difícil. Per tant, quan utilitzeu un tauler de control o un monitoratge integrat, sempre és important entendre que funciona correctament i us retorna dades avaluades correctament.

Com obtenir estadístiques sobre aquestes taules? Per fer-ho, PostgreSQL té una família de vistes. I la vista principal és pg_stat_user_tables. Taules_usuari: això significa que les taules es creen en nom de l'usuari. En canvi, hi ha vistes del sistema, que són utilitzades pel mateix PostgreSQL. I hi ha una taula resum Alltables, que inclou tant el sistema com l'usuari. Pots començar per qualsevol d'ells que més t'agradi.

Els camps anteriors es poden utilitzar per estimar el nombre d'insercions, actualitzacions i supressions. El tauler d'exemple que he utilitzat utilitza aquests camps per avaluar les característiques de la càrrega de treball. Per tant, també podem construir-hi. Però val la pena recordar que es tracta de tuples, no de bytes, així que no podem agafar-lo i fer-lo bytes.

A partir d'aquestes dades, podem construir les anomenades TopN-tables. Per exemple, Top-5, Top-10. I podeu fer un seguiment d'aquestes taules calentes que s'utilitzen més que altres. Per exemple, 5 taules "calentes" per a la inserció. I segons aquestes TopN-taules, avaluem la nostra càrrega de treball i podem avaluar les ràfegues de càrrega de treball després de qualsevol llançament i actualització i desplegament.

També és important avaluar la mida de la taula, perquè de vegades els desenvolupadors presenten una nova funció i les nostres taules comencen a augmentar-se en les seves grans mides, perquè van decidir afegir una quantitat addicional de dades, però no van predir com ho faria. afecta la mida de la base de dades. Aquests casos també ens sorprenen.

I ara una petita pregunta per a tu. Quina és la pregunta quan observeu la càrrega al servidor de bases de dades? Quina és la teva següent pregunta?

Però la veritable pregunta és la següent. Quines peticions provoca la càrrega? És a dir, no és interessant observar els processos que provoca la càrrega. És clar que si l'amfitrió està amb una base de dades, aleshores la base de dades s'està executant allà i és clar que només s'eliminaran les bases de dades. Si obrim Top, hi veurem una llista de processos PostgreSQL que estan fent alguna cosa. Des de dalt no quedarà clar què estan fent.

En conseqüència, heu de trobar aquelles consultes que causen més càrrega, perquè l'ajust de consultes, per regla general, ofereix més beneficis que la configuració de PostgreSQL o l'ajust del sistema operatiu, o fins i tot l'ajust del maquinari. Segons la meva estimació, això és al voltant del 80-85-90%. I això es fa molt més ràpid. És més ràpid corregir la sol·licitud que corregir la configuració, programar un reinici, sobretot si la base de dades no es pot reiniciar, o afegir maquinari. És més fàcil reescriure la consulta en algun lloc o afegir un índex per obtenir un millor resultat d'aquesta consulta.

En conseqüència, cal fer un seguiment de les sol·licituds i la seva adequació. Prenguem un altre exemple de seguiment. I aquí també sembla que hi ha un seguiment excel·lent. Hi ha informació sobre la replicació, hi ha informació sobre el rendiment, el bloqueig i la utilització dels recursos. Tot està bé, però no hi ha informació sobre les peticions. No està clar quines consultes s'estan executant a la nostra base de dades, quant de temps s'executen, quantes d'aquestes consultes. Hem de tenir sempre aquesta informació en el seguiment.

I per obtenir aquesta informació, podem utilitzar el mòdul pg_stat_statements. Sobre la seva base, podeu crear una varietat de gràfics. Per exemple, podeu obtenir informació sobre les sol·licituds més freqüents, és a dir, sobre aquelles peticions que es realitzen amb més freqüència. Sí, després dels desplegaments també és molt útil mirar-ho i entendre si hi ha algun augment de sol·licituds.

Podeu supervisar les consultes més llargues, és a dir, les que s'executen més. S'executen al processador, consumeixen E/S. També ho podem avaluar mitjançant els camps total_time, mean_time, blk_write_time i blk_read_time.

Podem avaluar i controlar les sol·licituds més pesades pel que fa a l'ús de recursos, les que llegeixen des del disc, les que funcionen amb memòria o, per contra, crear algun tipus de càrrega d'escriptura.

Podem avaluar les peticions més generoses. Aquestes són les consultes que retornen un gran nombre de files. Per exemple, pot ser algun tipus de sol·licitud on s'obliden de posar un límit. I només retorna tot el contingut de la taula o consulta a les taules sol·licitades.

I també podeu supervisar les consultes que utilitzen fitxers temporals o taules temporals.

I encara tenim processos de fons. Els processos de fons són principalment punts de control o també s'anomenen punts de control, aquests són l'autobuit i la replicació.

Un altre exemple de seguiment. Hi ha una pestanya Manteniment a l'esquerra, aneu-hi i espereu veure alguna cosa útil. Però aquí, només el temps del buit i la recollida d'estadístiques, res més. Aquesta és una informació molt pobra, de manera que sempre necessiteu tenir informació sobre com funcionen els processos de fons a la nostra base de dades i si hi ha cap problema pel seu treball.

Quan mirem els punts de control, cal recordar que els nostres punts de control esborren pàgines "brutes" de l'àrea de memòria fragmentada al disc i, a continuació, creen un punt de control. I aquest punt de control ja es pot utilitzar com a lloc durant la recuperació, si PostgreSQL es va acabar de sobte en una emergència.

En conseqüència, per esborrar totes les pàgines "brutes" al disc, heu de fer una certa quantitat d'escriptura. I, per regla general, en sistemes amb una gran quantitat de memòria, això és molt. I si fem punts de control molt sovint en un interval curt, el rendiment del disc es reduirà molt. I les peticions dels clients patiran la manca de recursos. Competiran pels recursos i mancaran de productivitat.

En conseqüència, mitjançant pg_stat_bgwriter als camps especificats, podem controlar el nombre de punts de control que es produeixen. I si tenim molts punts de control durant un període de temps determinat (durant 10-15-20 minuts, durant mitja hora), per exemple, 3-4-5, això ja pot ser un problema. I ja cal buscar a la base de dades, mirar a la configuració, què provoca tanta abundància de punts de control. Potser vindrà algun gran disc. Ja podem avaluar la càrrega de treball, perquè ja hem afegit gràfics de càrrega de treball. Ja podem ajustar els paràmetres del punt d'interrupció i assegurar-nos que no afectin gaire el rendiment de la consulta.

Tornaré a l'aspiració automàtica perquè és el tipus de coses, com he dit, que poden sumar fàcilment el rendiment del disc i de la consulta, de manera que sempre és important mesurar la quantitat d'aspiració automàtica.

El nombre de treballadors d'autoaspiració a la base de dades és limitat. De manera predeterminada, n'hi ha tres, de manera que si tenim tres treballadors treballant a la base de dades tot el temps, això vol dir que el nostre buit automàtic està poc configurat, hem d'augmentar els límits, revisar la configuració de l'autobuit i ja pujar a la configuració.
És important avaluar quins treballadors del buit treballen per a nosaltres. O es va llançar des de l'usuari, el DBA va entrar i va llançar algun tipus de buit amb les seves mans, i això va crear una càrrega. Tenim algun problema. O aquest és el nombre de buits que desenrosquen el comptador de transaccions. Per a algunes versions de PostgreSQL, es tracta de buits molt pesats. I poden afegir rendiment fàcilment perquè resten tota la taula, escanejant tots els blocs d'aquesta taula.

I, per descomptat, la durada dels buits. Si tenim aspiradores llargues que funcionen durant molt de temps, això vol dir que hauríem de tornar a prestar atenció a la configuració de l'aspiradora i potser reconsiderar la seva configuració. Com que pot sorgir una situació quan el buit funciona a la taula durant molt de temps (3-4 hores), però durant el treball del buit, una gran quantitat de files mortes es va tornar a acumular a la taula. I tan bon punt s'acabi el buit, ha de tornar a aspirar aquesta taula. I arribem a una situació: un buit infinit. I en aquest cas, el buit no fa front al seu treball i les taules comencen a augmentar de mida gradualment, tot i que la quantitat de dades útils segueix sent la mateixa. Per tant, en buits llargs, ens fixem sempre en la configuració i intentem optimitzar-la, però alhora, perquè el rendiment de les sol·licituds dels clients no es ressenteixi.

Ara pràcticament no hi ha instal·lació de PostgreSQL on no hi hagi rèplica de streaming. La replicació és el procés de transferència de dades d'un mestre a una rèplica.

La replicació a PostgreSQL s'organitza mitjançant un registre de transaccions. El mestre genera un registre de transaccions. El registre de transaccions de la connexió de xarxa va a la rèplica i després es reprodueix a la rèplica. Tot és senzill.

En conseqüència, la vista pg_stat_replication s'utilitza per controlar el retard de replicació. Però no és fàcil per a ella. A la versió 10, la vista ha sofert diversos canvis. En primer lloc, alguns dels camps han canviat de nom. I alguns dels camps s'han afegit. A la 10a versió, van aparèixer camps que permeten avaluar el retard de replicació en segons. És molt còmode. Abans de la versió 10, era possible estimar el retard de replicació en bytes. Aquesta característica es va mantenir a la 10a versió, és a dir, podeu triar el que us convingui més: avalueu el retard en bytes o avalueu el retard en segons. Molts fan les dues coses.

Tanmateix, per avaluar el retard de replicació, cal conèixer la posició del registre a la transacció. I aquestes posicions del registre de transaccions només es troben a la vista pg_stat_replication. Relativament parlant, podem utilitzar la funció pg_xlog_location_diff() per prendre dos punts al registre de transaccions. Calculeu el delta entre ells i obteniu el retard de replicació en bytes. És molt còmode i senzill.

A la versió 10, aquesta funció es va canviar el nom a pg_wal_lsn_diff(). En general, en totes les funcions, vistes, utilitats, on es va trobar la paraula "xlog", es va substituir pel valor "wal". Això és tant en vistes com en funcions. Aquesta és una innovació tan gran.

A més, a la 10a versió, es van afegir línies que mostren específicament el retard. Aquests són el retard d'escriptura, el retard al ras, el retard de reproducció. És a dir, és important controlar aquestes coses. Si veiem que tenim un retard de rèplica, hem d'investigar per què va aparèixer, d'on prové i solucionar el problema.

Amb les mètriques del sistema, gairebé tot està en ordre. Quan neix qualsevol monitorització, comença amb mètriques del sistema. Aquesta és la utilització de processadors, memòria, intercanvi, xarxa i disc. Però, tanmateix, molts paràmetres no hi són per defecte.

Si tot està en ordre amb l'eliminació del procés, hi ha problemes amb l'eliminació del disc. Per regla general, els desenvolupadors de monitoratge afegeixen informació sobre l'ample de banda. Pot ser en iops o bytes. Però s'obliden de la latència i l'ús del dispositiu de disc. Aquests són paràmetres més importants que ens permeten avaluar com de carregats estan els nostres discs i quant es frenen. Si tenim una latència alta, això vol dir que hi ha alguns problemes amb els discs. Si tenim una gran utilització, això significa que els discs no poden fer front. Aquestes són característiques més qualitatives que l'ample de banda.

Tanmateix, aquestes estadístiques també es poden obtenir des del sistema de fitxers /proc, com es fa per al reciclatge del processador. Per què aquesta informació no s'afegeix al seguiment, no ho sé. Però encara és important tenir-lo al vostre seguiment.

El mateix passa amb les interfícies de xarxa. Hi ha informació sobre l'ample de banda de la xarxa en paquets, en bytes, però, tanmateix, no hi ha informació sobre la latència ni informació sobre la utilització, encara que també és informació útil.

Qualsevol seguiment té els seus inconvenients. I, independentment del tipus de control que feu, sempre no complirà certs criteris. Però, tanmateix, es desenvolupen, s'afegeixen noves funcions, coses noves, així que trieu alguna cosa i acabeu-la.

I per acabar, sempre has de tenir una idea del que significa l'estadística donada i de com pots resoldre els problemes amb ella.

I alguns punts clau:

• Sempre cal vigilar la disponibilitat, disposar de taulers per poder valorar ràpidament que tot està en ordre amb la base.
• Sempre heu de tenir una idea de quins clients estan treballant amb la vostra base de dades per eliminar els clients dolents i disparar-los.
• És important avaluar com treballen aquests clients amb les dades. Heu de tenir una idea de la vostra càrrega de treball.
• És important avaluar com es forma aquesta càrrega de treball, amb l'ajuda de quines consultes. Podeu avaluar consultes, optimitzar-les, refactoritzar-les, crear-hi índexs. És molt important.
• Els processos en segon pla poden afectar negativament les sol·licituds dels clients, per la qual cosa és important assegurar-se que no utilitzen massa recursos.
• Les mètriques del sistema us permeten fer plans per escalar, per augmentar la capacitat dels vostres servidors, per la qual cosa també és important fer-ne un seguiment i avaluar-los.

Si esteu interessats en aquest tema, podeu seguir aquests enllaços.
http://bit.do/stats_collector és la documentació oficial del col·lector d'estadístiques. Hi ha una descripció de totes les visualitzacions estadístiques i una descripció de tots els camps. Podeu llegir-los, entendre-los i analitzar-los. I sobre la base d'ells, creeu els vostres propis gràfics, afegiu-lo al vostre seguiment.

Sol·liciteu exemples:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Aquest és el nostre repositori corporatiu i el meu. Tenen sol·licituds de mostres. No hi ha consultes de la selecció* de la sèrie, alguna cosa allà. Ja hi ha sol·licituds ja fetes amb unions, utilitzant funcions interessants que permeten fer valors llegibles i convenients a partir de números en brut, és a dir, són bytes, temps. Podeu triar-los, mirar-los, analitzar-los, afegir-los als vostres monitors, crear els vostres propis monitoratges basats en ells.

Les vostres preguntes

Pregunta: vau dir que no anunciaríeu marques, però encara em pregunto: quin tipus de taulers feu servir als vostres projectes?
Resposta: De diferents maneres. Passa que arribem al client i ja té el seu propi seguiment. I assessorem el client sobre què cal afegir al seu seguiment. La pitjor situació és amb Zabbix. Perquè no té la capacitat de crear TopN-graphics. Nosaltres mateixos fem servir Okmetreperquè vam consultar aquests nois sobre el seguiment. Van fer un seguiment PostgreSQL basat en el nostre TOR. Estic escrivint el meu propi projecte per a mascotes, que recull dades a través de Prometheus i les incorpora Grafana. La meva tasca és fer el meu propi exportador a Prometeu i després dibuixar-ho tot a Grafana.

Pregunta: Hi ha algun anàleg d'informes AWR o... agregacions? Ets conscient d'alguna cosa així?
Resposta: Sí, sé què és AWR, és una cosa genial. De moment, hi ha una varietat de bicicletes que implementen aproximadament el següent model. En algun interval de temps, algunes línies de base s'escriuen al mateix PostgreSQL o a un emmagatzematge independent. Podeu buscar-los a Google a Internet, ho són. Un dels desenvolupadors d'aquesta cosa es troba al fòrum sql.ru al fil PostgreSQL. Pots agafar-lo allà. Sí, hi ha coses així, es poden utilitzar. més en el seu pgCenter També escric una cosa que et permet fer el mateix.

PS1 Si utilitzeu postgres_exporter, quin quadre de comandament feu servir? N'hi ha diversos. Ja estan obsolets. Pot la comunitat crear una plantilla actualitzada?

PS2 S'ha eliminat pganalyze ja que és una oferta SaaS patentada que se centra en el seguiment del rendiment i els suggeriments d'ajust automàtic.

Només els usuaris registrats poden participar en l'enquesta. Inicia sessiósi us plau.

Quin monitoratge postgresql autoallotjat (amb tauler) creus que és el millor?

• 30,0%Zabbix + addicions d'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 és un SaaS propietari: no es pot eliminar1

• 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

Han votat 10 usuaris. 26 usuaris es van abstenir.

Font: www.habr.com