{"id":56075,"date":"2020-02-04T00:00:00","date_gmt":"2020-02-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/osnovy-monitoringa-postgresql-aleksej-lesovskij"},"modified":"2020-02-18T14:04:16","modified_gmt":"2020-02-18T11:04:16","slug":"osnovy-monitoringa-postgresql-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"Les bases de la surveillance de PostgreSQL. Alexey Lesovski","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Je vous invite \u00e0 consulter la transcription de la pr\u00e9sentation d'Alexey Lesovski de Data Egret \"Fondamentaux de la surveillance de PostgreSQL\"<\/strong><\/p>\n

<\/p>\n

Dans cette pr\u00e9sentation, Alexey Lesovski abordera les points cl\u00e9s des statistiques PostgreSQL, leur signification et pourquoi elles doivent faire partie de la surveillance ; quels graphiques devraient \u00eatre inclus dans la surveillance, comment les ajouter et comment les interpr\u00e9ter. Cette pr\u00e9sentation sera utile pour les administrateurs de bases de donn\u00e9es, les administrateurs syst\u00e8me et les d\u00e9veloppeurs int\u00e9ress\u00e9s par le d\u00e9pannage de PostgreSQL.<\/p>\n

\n

\r\n \"Lire\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"Les<\/p>\n

<\/p>\n

Je m'appelle Alexey Lesovski, je repr\u00e9sente la soci\u00e9t\u00e9 Data Egret. <\/p>\n

<\/p>\n

Quelques mots sur moi. J'ai commenc\u00e9 il y a longtemps en tant qu'administrateur syst\u00e8me. <\/p>\n

<\/p>\n

J'ai administr\u00e9 divers syst\u00e8mes Linux, travaill\u00e9 sur diff\u00e9rentes t\u00e2ches li\u00e9es \u00e0 Linux, c'est-\u00e0-dire la virtualisation, la surveillance, j'ai travaill\u00e9 avec des proxys, etc. Mais \u00e0 un moment donn\u00e9, je me suis tourn\u00e9 vers les bases de donn\u00e9es, PostgreSQL. J'ai beaucoup aim\u00e9 ce syst\u00e8me. Et petit \u00e0 petit, je me suis consacr\u00e9 \u00e0 PostgreSQL la majeure partie de mon temps de travail. Ainsi, progressivement, je suis devenu DBA PostgreSQL.<\/p>\n

<\/p>\n

Tout au long de ma carri\u00e8re, j'ai toujours \u00e9t\u00e9 int\u00e9ress\u00e9 par les th\u00e8mes de la statistique, de la surveillance, et de la collecte de t\u00e9l\u00e9m\u00e9trie. Lorsque j'\u00e9tais administrateur syst\u00e8me, j'ai travaill\u00e9 de pr\u00e8s sur Zabbix. J'ai \u00e9crit un petit ensemble de scripts comme zabbix-extensions<\/a><\/noindex>. Il \u00e9tait assez populaire \u00e0 l'\u00e9poque. On pouvait y surveiller de nombreuses choses importantes, pas seulement Linux, mais aussi diff\u00e9rents composants.<\/p>\n

<\/p>\n

Maintenant, je me concentre sur PostgreSQL. J'\u00e9cris un autre outil qui permet de travailler avec la statistique PostgreSQL. Il s'appelle pgCenter<\/a><\/noindex> (article sur Habr \u2014 Statistiques PostgreSQL sans stress ni effort<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Une br\u00e8ve introduction. Quelles sont les situations que rencontrent nos clients ? Un incident survient dans la base de donn\u00e9es. Et une fois que la base de donn\u00e9es est restaur\u00e9e, le responsable ou le chef de d\u00e9veloppement arrive et dit : \u00ab Les amis, il nous faut surveiller la base de donn\u00e9es, car quelque chose de grave s'est produit et nous devons \u00e9viter que cela ne se reproduise \u00e0 l'avenir \u00bb. C'est alors que commence un int\u00e9ressant processus de s\u00e9lection d'un syst\u00e8me de surveillance ou d'adaptation du syst\u00e8me de surveillance existant pour pouvoir monitorer sa base de donn\u00e9es \u2013 PostgreSQL, MySQL ou d'autres. Les coll\u00e8gues commencent \u00e0 sugg\u00e9rer : \u00ab J'ai entendu parler d'une telle base de donn\u00e9es. Utilisons-la \u00bb. Les coll\u00e8gues commencent \u00e0 d\u00e9battre. En fin de compte, nous choisissons une base de donn\u00e9es, mais la surveillance de PostgreSQL est plut\u00f4t limit\u00e9e et il est toujours n\u00e9cessaire de faire des ajustements. Il faut r\u00e9cup\u00e9rer des d\u00e9p\u00f4ts depuis GitHub, les cloner, adapter les scripts, faire des r\u00e9glages. Finalement, cela se traduit par un travail manuel. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Dans cette pr\u00e9sentation, je vais essayer de vous fournir des connaissances sur la fa\u00e7on de choisir un syst\u00e8me de surveillance non seulement pour PostgreSQL, mais aussi pour d'autres bases de donn\u00e9es. Et donner les informations qui vous permettront d'am\u00e9liorer votre surveillance, afin d'en retirer une certaine utilit\u00e9, pour suivre votre base de donn\u00e9es de mani\u00e8re efficace, afin de pr\u00e9venir \u00e0 temps des situations d'urgence potentielles qui pourraient survenir. <\/p>\n

<\/p>\n

Les id\u00e9es que je vais pr\u00e9senter dans ce rapport peuvent \u00eatre directement adapt\u00e9es \u00e0 n'importe quelle base de donn\u00e9es, qu'il s'agisse d'un SGBD ou d'une base noSQL. Ainsi, il ne s'agit pas seulement de PostgreSQL, mais il y aura de nombreuses recettes sur la mani\u00e8re d'op\u00e9rer sur PostgreSQL. Des exemples de requ\u00eates, des exemples d'entit\u00e9s disponibles dans PostgreSQL pour la surveillance. Et si votre SGBD dispose de fonctionnalit\u00e9s similaires qui vous permettent de les int\u00e9grer dans la surveillance, vous pouvez \u00e9galement les adapter, les ajouter et cela fonctionnera bien.<\/p>\n

<\/p>\n

\"LesDans cette pr\u00e9sentation, je ne vais pas
\nparler de la fa\u00e7on de collecter et de stocker des m\u00e9triques. Je ne vais pas aborder la post-traitement des donn\u00e9es et la pr\u00e9sentation \u00e0 l'utilisateur. Et je ne vais pas parler d'alerte.
\nAu fil de la narration, je vais montrer diff\u00e9rents exemples de surveillance, et je vais les critiquer d'une mani\u00e8re ou d'une autre. N\u00e9anmoins, je vais essayer de ne pas nommer de marques pour ne pas faire de la publicit\u00e9 ou de l'anti-publicit\u00e9 \u00e0 ces produits. Par cons\u00e9quent, toute co\u00efncidence est purement fortuite et laisse place \u00e0 votre imagination.
\n\"Les
\nCommen\u00e7ons par comprendre ce qu'est la surveillance. La surveillance est quelque chose de tr\u00e8s important \u00e0 avoir. Tout le monde le comprend. Mais en m\u00eame temps, la surveillance n'est pas consid\u00e9r\u00e9e comme un produit commercial et n'affecte pas directement les b\u00e9n\u00e9fices de l'entreprise, c'est pourquoi on y consacre du temps de mani\u00e8re r\u00e9siduelle. Si nous avons du temps, nous faisons de la surveillance ; si nous n'en avons pas, tant pis, nous mettrons cela dans notre backlog et reviendrons \u00e0 ces t\u00e2ches un jour. <\/p>\n

<\/p>\n

Ainsi, d'apr\u00e8s notre exp\u00e9rience, lorsque nous arrivons chez nos clients, la surveillance est souvent sous-d\u00e9velopp\u00e9e et ne contient pas les \u00e9l\u00e9ments int\u00e9ressants qui pourraient nous aider \u00e0 travailler mieux avec la base de donn\u00e9es. C'est pourquoi la surveillance doit toujours \u00eatre am\u00e9lior\u00e9e. <\/p>\n

<\/p>\n

Les bases de donn\u00e9es sont des syst\u00e8mes complexes qui doivent \u00e9galement \u00eatre surveill\u00e9s, car elles constituent un r\u00e9f\u00e9rentiel d'informations. Ces informations sont extr\u00eamement importantes pour l'entreprise et ne doivent pas \u00eatre perdues. Cependant, les bases de donn\u00e9es sont \u00e9galement des morceaux de logiciels tr\u00e8s complexes. Elles se composent de nombreux composants, dont beaucoup doivent \u00eatre surveill\u00e9s. <\/p>\n

<\/p>\n

\"LesSi nous parlons sp\u00e9cifiquement de PostgreSQL, nous pouvons le repr\u00e9senter sous la forme d'un sch\u00e9ma compos\u00e9 de nombreux composants. Ces composants interagissent entre eux. En m\u00eame temps, PostgreSQL dispose d'un sous-syst\u00e8me appel\u00e9 Stats Collector, qui permet de collecter des statistiques sur le fonctionnement de ces sous-syst\u00e8mes et de fournir une interface \u00e0 l'administrateur ou \u00e0 l'utilisateur pour qu'il puisse consulter ces statistiques. <\/p>\n

<\/p>\n

Ces statistiques sont pr\u00e9sent\u00e9es sous la forme d'un ensemble de fonctions et de vues. On peut \u00e9galement les appeler des tables. C'est-\u00e0-dire qu'avec un client psql classique, vous pouvez vous connecter \u00e0 la base de donn\u00e9es, faire une s\u00e9lection sur ces fonctions et vues, et obtenir des chiffres sp\u00e9cifiques sur le fonctionnement des sous-syst\u00e8mes de PostgreSQL. <\/p>\n

<\/p>\n

Vous pouvez int\u00e9grer ces chiffres dans votre syst\u00e8me de surveillance pr\u00e9f\u00e9r\u00e9, cr\u00e9er des graphiques, ajouter des fonctions et obtenir des analyses \u00e0 long terme. <\/p>\n

<\/p>\n

Cependant, dans ce rapport, je ne vais pas examiner toutes ces fonctions en d\u00e9tail, car cela pourrait prendre une journ\u00e9e enti\u00e8re. Je vais aborder litt\u00e9ralement deux \u00e0 quatre \u00e9l\u00e9ments et expliquer comment ils aident \u00e0 am\u00e9liorer la surveillance.
\n\"Les
\nEt en parlant de la surveillance de la base de donn\u00e9es, que faut-il surveiller ? En premier lieu, il est essentiel de surveiller la disponibilit\u00e9, car la base est un service qui fournit un acc\u00e8s aux donn\u00e9es pour les clients, et nous devons surveiller la disponibilit\u00e9, ainsi que certaines de ses caract\u00e9ristiques qualitatives et quantitatives. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Il est \u00e9galement n\u00e9cessaire de surveiller les clients qui se connectent \u00e0 notre base de donn\u00e9es, car ils peuvent \u00eatre \u00e0 la fois des clients normaux ou des clients nuisibles qui pourraient nuire \u00e0 la base de donn\u00e9es. Ils doivent \u00e9galement \u00eatre surveill\u00e9s et leur activit\u00e9 suivie.<\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Lorsque les clients se connectent \u00e0 la base de donn\u00e9es, il est \u00e9vident qu'ils commencent \u00e0 travailler avec nos donn\u00e9es. Nous devons donc surveiller comment les clients interagissent avec les donn\u00e9es : avec quelles tables, et dans une moindre mesure, avec quels index. En d'autres termes, nous devons \u00e9valuer la charge de travail (workload) g\u00e9n\u00e9r\u00e9e par nos clients.<\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Mais cette charge de travail consiste \u00e9videmment en des requ\u00eates. Les applications se connectent \u00e0 la base de donn\u00e9es et acc\u00e8dent aux donn\u00e9es via des requ\u00eates, il est donc important d'\u00e9valuer les requ\u00eates dans notre base de donn\u00e9es, de suivre leur pertinence pour s'assurer qu'elles ne sont pas mal \u00e9crites, et que certaines options doivent \u00eatre r\u00e9\u00e9crites pour fonctionner plus rapidement et de mani\u00e8re plus performante. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Et puisque nous parlons de base de donn\u00e9es, il est important de noter que la base de donn\u00e9es est toujours accompagn\u00e9e de processus en arri\u00e8re-plan. Ces processus en arri\u00e8re-plan permettent de maintenir la performance de la base de donn\u00e9es \u00e0 un bon niveau, et pour fonctionner, ils n\u00e9cessitent une certaine quantit\u00e9 de ressources. En m\u00eame temps, ils peuvent entrer en conflit avec les ressources des requ\u00eates clients, donc un fonctionnement gourmand des processus en arri\u00e8re-plan peut directement affecter la performance des requ\u00eates des clients. Par cons\u00e9quent, ils doivent \u00e9galement \u00eatre surveill\u00e9s et il faut s'assurer qu'il n'y a pas de d\u00e9s\u00e9quilibres concernant les processus en arri\u00e8re-plan. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Toutes les informations concernant la surveillance de la base de donn\u00e9es restent dans les m\u00e9triques syst\u00e8mes. Cependant, \u00e9tant donn\u00e9 que notre infrastructure est principalement migr\u00e9e vers le cloud, les m\u00e9triques syst\u00e8mes d'un h\u00f4te individuel passent souvent au second plan. Pourtant, elles restent pertinentes pour les bases de donn\u00e9es, et il est \u00e9galement n\u00e9cessaire de surveiller ces m\u00e9triques syst\u00e8mes. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Les m\u00e9triques syst\u00e8mes sont globalement bien couvertes, toutes les syst\u00e8mes de surveillance modernes les prennent en charge. Toutefois, certaines composantes restent insuffisantes et il est n\u00e9cessaire d'ajouter certaines informations. J'aborderai \u00e9galement ce sujet, quelques diapositives seront consacr\u00e9es \u00e0 cela. <\/p>\n

<\/p>\n

\"Les
\nLe premier point du plan est la disponibilit\u00e9. Qu'est-ce que la disponibilit\u00e9 ? \u00c0 mon avis, la disponibilit\u00e9 se r\u00e9f\u00e8re \u00e0 la capacit\u00e9 d'une base de donn\u00e9es \u00e0 traiter des connexions, c'est-\u00e0-dire que la base est op\u00e9rationnelle et accepte les connexions des clients. On peut \u00e9valuer cette disponibilit\u00e9 \u00e0 l'aide de certaines caract\u00e9ristiques. Ces caract\u00e9ristiques sont tr\u00e8s pratiques \u00e0 afficher sur des tableaux de bord. <\/p>\n

<\/p>\n

\"Les
\nTout le monde sait ce que sont des tableaux de bord. C'est lorsque vous jetez un \u0153il \u00e0 l'\u00e9cran o\u00f9 les informations n\u00e9cessaires sont centralis\u00e9es. Vous pouvez imm\u00e9diatement d\u00e9terminer s'il y a un probl\u00e8me dans la base ou non.
\nIl est donc essentiel d'afficher la disponibilit\u00e9 de la base de donn\u00e9es ainsi que d'autres caract\u00e9ristiques cl\u00e9s sur des tableaux de bord, afin que ces informations soient \u00e0 port\u00e9e de main, toujours \u00e0 votre disposition. Certains d\u00e9tails suppl\u00e9mentaires, qui aident lors d'enqu\u00eates d'incidents ou de situations d'urgence, doivent plut\u00f4t \u00eatre affich\u00e9s sur des sous-tableaux de bord, ou dissimul\u00e9s dans des liens de drilldown menant \u00e0 d'autres syst\u00e8mes de surveillance. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Voici un exemple d'un syst\u00e8me de surveillance bien connu. C'est un syst\u00e8me de surveillance tr\u00e8s performant. Il collecte une multitude de donn\u00e9es, mais \u00e0 mon sens, il a une conception \u00e9trange des tableaux de bord. Il y a un lien \u00ab cr\u00e9er un tableau de bord \u00bb. Toutefois, lorsque vous cr\u00e9ez un tableau de bord, vous r\u00e9alisez une sorte de liste compos\u00e9e de deux colonnes, une liste de graphiques. Lorsque vous avez besoin de consulter quelque chose, vous commencez \u00e0 cliquer, \u00e0 faire d\u00e9filer, \u00e0 chercher le graphique souhait\u00e9. Cela prend du temps, c'est-\u00e0-dire qu'il n'y a pas de v\u00e9ritables tableaux de bord. Il n'y a que des listes de graphiques.<\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Que faut-il ajouter \u00e0 ces tableaux de bord ? On peut commencer par une caract\u00e9ristique telle que le temps de r\u00e9ponse. Dans PostgreSQL, il existe une vue pg_stat_statements. Par d\u00e9faut, elle est d\u00e9sactiv\u00e9e, mais c'est l'une des vues syst\u00e8me importantes qui doit toujours \u00eatre activ\u00e9e et utilis\u00e9e. Elle contient des informations sur toutes les requ\u00eates ex\u00e9cut\u00e9es dans la base de donn\u00e9es. <\/p>\n

<\/p>\n

Par cons\u00e9quent, nous pouvons partir de l'id\u00e9e qu'il est possible de prendre le temps total d'ex\u00e9cution de toutes les requ\u00eates et de le diviser par le nombre de requ\u00eates \u00e0 l'aide des champs mentionn\u00e9s ci-dessus. Mais cela reste une mesure g\u00e9n\u00e9rale. Nous pouvons \u00e9galement nous baser sur d'autres champs : le temps d'ex\u00e9cution minimal, maximal et m\u00e9dian. Nous pouvons m\u00eame construire des percentiles, PostgreSQL dispose de fonctions correspondantes pour cela. Et nous pouvons obtenir des chiffres qui caract\u00e9risent le temps de r\u00e9ponse de notre base de donn\u00e9es sur les requ\u00eates d\u00e9j\u00e0 ex\u00e9cut\u00e9es, c'est-\u00e0-dire que nous n'ex\u00e9cutons pas une requ\u00eate fictive 'select 1' et regardons le temps de r\u00e9ponse, mais nous analysons le temps des r\u00e9ponses des requ\u00eates d\u00e9j\u00e0 ex\u00e9cut\u00e9es et nous les repr\u00e9sentons soit par un chiffre distinct, soit en construisant un graphique. <\/p>\n

<\/p>\n

Il est \u00e9galement important de suivre le nombre d'erreurs g\u00e9n\u00e9r\u00e9es par le syst\u00e8me \u00e0 l'heure actuelle. Pour cela, on peut utiliser la vue pg_stat_database. Nous nous concentrons sur le champ xact_rollback. Ce champ montre non seulement le nombre de rollbacks se produisant dans la base, mais prend \u00e9galement en compte le nombre d'erreurs. Pour dire les choses simplement, nous pouvons afficher ce chiffre sur notre tableau de bord et voir combien d'erreurs nous avons en ce moment. Si le nombre d'erreurs est \u00e9lev\u00e9, c'est d\u00e9j\u00e0 une bonne raison d'examiner les journaux et de voir quelles sont ces erreurs et pourquoi elles se produisent, puis d'investiguer et de r\u00e9soudre le probl\u00e8me.<\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

On peut ajouter quelque chose comme un tachym\u00e8tre. C'est le nombre de transactions par seconde et le nombre de requ\u00eates par seconde. En d'autres termes, vous pouvez utiliser ces chiffres comme performance actuelle de votre base de donn\u00e9es et observer s'il y a des pics de requ\u00eates, des pics de transactions ou, au contraire, si la base est sous-utilis\u00e9e parce qu'un certains backends sont tomb\u00e9s en panne. Ce chiffre est toujours important \u00e0 surveiller et il faut se rappeler que, pour notre projet, une telle performance est consid\u00e9r\u00e9e comme normale, tandis que des valeurs plus \u00e9lev\u00e9es ou plus basses sont probl\u00e9matiques et difficiles \u00e0 comprendre, ce qui signifie qu'il faut examiner pourquoi ces chiffres sont l\u00e0.<\/p>\n

<\/p>\n

Pour \u00e9valuer le nombre de transactions, nous pouvons \u00e0 nouveau nous tourner vers la vue pg_stat_database. Nous pouvons additionner le nombre de commits et le nombre de rollbacks pour obtenir le nombre de transactions par seconde. <\/p>\n

<\/p>\n

Tout le monde comprend qu'une transaction peut comprendre plusieurs requ\u00eates ? C'est pourquoi le TPS et le QPS sont l\u00e9g\u00e8rement diff\u00e9rents. <\/p>\n

<\/p>\n

Le nombre de requ\u00eates par seconde peut \u00eatre obtenu via pg_stat_statements en faisant simplement la somme de toutes les requ\u00eates ex\u00e9cut\u00e9es. Il est clair que nous comparons la valeur actuelle avec la pr\u00e9c\u00e9dente, nous soustrayons, nous obtenons la diff\u00e9rence, et ainsi le nombre.<\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Il est possible d'ajouter d'autres m\u00e9triques si voulu, qui aident \u00e9galement \u00e0 \u00e9valuer la disponibilit\u00e9 de notre base de donn\u00e9es et \u00e0 suivre les p\u00e9riodes de downtime. <\/p>\n

<\/p>\n

L'une de ces m\u00e9triques est le uptime. Mais le uptime dans PostgreSQL est un peu un sujet d\u00e9licat. Voici pourquoi. Lorsque PostgreSQL est lanc\u00e9, le uptime commence \u00e0 \u00eatre compt\u00e9. Mais si \u00e0 un moment donn\u00e9, par exemple la nuit, une t\u00e2che est ex\u00e9cut\u00e9e, et que l'OOM-killer termine de force un processus fils de PostgreSQL, dans ce cas PostgreSQL ferme les connexions de tous les clients, vide l'espace de m\u00e9moire shard\u00e9e et commence la r\u00e9cup\u00e9ration depuis le dernier point de contr\u00f4le. Et tant que cette r\u00e9cup\u00e9ration depuis le point de contr\u00f4le dure, la base n'accepte pas de connexions, c'est-\u00e0-dire que cette situation peut \u00eatre consid\u00e9r\u00e9e comme un downtime. Cependant, le compteur de uptime ne se r\u00e9initialisera pas, car il prend en compte le temps depuis le premier moment du d\u00e9marrage du postmaster. Donc, ces situations peuvent \u00eatre n\u00e9glig\u00e9es.<\/p>\n

<\/p>\n

Il convient \u00e9galement de surveiller le nombre de workers de vacuum. Tout le monde sait ce qu'est l'autovacuum dans PostgreSQL ? C'est un sous-syst\u00e8me int\u00e9ressant dans PostgreSQL. Beaucoup d'articles ont \u00e9t\u00e9 \u00e9crits \u00e0 son sujet, de nombreuses pr\u00e9sentations ont \u00e9t\u00e9 faites. Il y a beaucoup de discussions sur le vacuum, sur son fonctionnement. Beaucoup le consid\u00e8rent comme un mal in\u00e9vitable. Mais c'est le cas. C'est un \u00e9quivalent du ramasseur de d\u00e9chets, qui nettoie les anciennes versions de lignes qui ne sont n\u00e9cessaires \u00e0 aucune des transactions et lib\u00e8re de l'espace dans les tables et les index pour de nouvelles lignes. <\/p>\n

<\/p>\n

Pourquoi faut-il le surveiller ? Parce que le vacuum peut parfois causer beaucoup de douleur. Il consomme une grande quantit\u00e9 de ressources et les requ\u00eates clients en souffrent. <\/p>\n

<\/p>\n

Il convient de le surveiller via la vue pg_stat_activity, dont je vais parler dans la section suivante. Cette vue montre l'activit\u00e9 actuelle dans la base de donn\u00e9es. Gr\u00e2ce \u00e0 cette activit\u00e9, nous pouvons suivre le nombre de processus de vide qui fonctionnent en ce moment. Nous pouvons surveiller les processus de vide et constater que si nous d\u00e9passons la limite, cela nous incite \u00e0 examiner les param\u00e8tres de PostgreSQL et \u00e0 optimiser le fonctionnement du vide. <\/p>\n

<\/p>\n

Une autre caract\u00e9ristique de PostgreSQL est que le syst\u00e8me souffre consid\u00e9rablement des longues transactions. Surtout, des transactions qui restent ouvertes sans rien faire. Ce sont ce que l'on appelle des stat idle-in-transaction. Une telle transaction maintient des verrouillages, elle emp\u00eache le processus de vide de fonctionner. Par cons\u00e9quent, les tables gonflent et augmentent en taille. Les requ\u00eates qui traitent ces tables commencent alors \u00e0 fonctionner plus lentement, car il faut triompher toutes les anciennes versions des lignes de la m\u00e9moire vers le disque et vice versa.<\/strong> Par cons\u00e9quent, il est \u00e9galement n\u00e9cessaire de surveiller la dur\u00e9e des transactions les plus longues, des requ\u00eates de vide les plus longues. Et si nous voyons des processus qui fonctionnent d\u00e9j\u00e0 tr\u00e8s longtemps, plus de 10-20-30 minutes pour une charge OLTP, il faut y pr\u00eater attention et les terminer de force, ou optimiser l'application pour qu'elles ne soient pas appel\u00e9es et ne restent pas suspendues si longtemps.<\/strong> Pour une charge analytique, 10-20-30 minutes, c'est normal, il peut m\u00eame y en avoir de plus longues. <\/p>\n

<\/p>\n

\"Les
\nEnsuite, nous avons la possibilit\u00e9 de voir les clients connect\u00e9s. Une fois que nous avons form\u00e9 le tableau de bord et affich\u00e9 les indicateurs cl\u00e9s de disponibilit\u00e9, nous pouvons \u00e9galement ajouter des informations compl\u00e9mentaires sur les clients connect\u00e9s. <\/p>\n

<\/p>\n

Les informations sur les clients connect\u00e9s sont importantes, car, du point de vue de PostgreSQL, les clients peuvent \u00eatre diff\u00e9rents. Il y a de bons clients et de mauvais clients. <\/p>\n

<\/p>\n

Un exemple simple. Par client, j'entends une application. L'application s'est connect\u00e9e \u00e0 la base de donn\u00e9es et commence imm\u00e9diatement \u00e0 y envoyer ses requ\u00eates, la base de donn\u00e9es les traite et les ex\u00e9cute, et renvoie les r\u00e9sultats au client. Ce sont de bons et de bons clients. <\/p>\n

<\/p>\n

Il arrive que le client se connecte, maintienne la connexion, mais ne fasse rien. Il est dans un \u00e9tat d'inactivit\u00e9. <\/p>\n

<\/p>\n

Mais il y a des mauvais clients. Par exemple, ce client s'est connect\u00e9, a ouvert une transaction, a fait quelque chose dans la base puis est all\u00e9 dans le code, disons, pour acc\u00e9der \u00e0 une source externe ou pour traiter les donn\u00e9es obtenues. Cependant, il n'a pas ferm\u00e9 la transaction. Et la transaction reste en attente dans la base et bloque certaines lignes. C'est une mauvaise situation. Et si l'application \u00e9choue quelque part avec une exception, la transaction peut rester ouverte tr\u00e8s longtemps. Cela a un impact direct sur les performances de PostgreSQL. PostgreSQL fonctionnera plus lentement. Il est donc important de surveiller ces clients et de forcer la fin de leur travail en temps voulu. Il est \u00e9galement n\u00e9cessaire d'optimiser votre application pour \u00e9viter de telles situations. <\/p>\n

<\/p>\n

Un autre type de mauvais client est celui des clients en attente. Mais ils deviennent mauvais en raison des circonstances. Par exemple, une transaction simple qui reste inactive : elle peut ouvrir une transaction, prendre des verrous sur certaines lignes, puis \u00e9chouer quelque part dans le code, laissant une transaction en attente. Un autre client viendra, demandera les m\u00eames donn\u00e9es, mais il se heurtera \u00e0 un verrou, car cette transaction en attente d\u00e9tient d\u00e9j\u00e0 des verrous sur certaines lignes n\u00e9cessaires. Ainsi, la seconde transaction restera en attente jusqu'\u00e0 ce que la premi\u00e8re transaction se termine ou que son administrateur la ferme de force. Par cons\u00e9quent, les transactions en attente peuvent s'accumuler et d\u00e9passer la limite de connexions \u00e0 la base de donn\u00e9es. Lorsque cette limite est d\u00e9pass\u00e9e, l'application ne peut plus fonctionner avec la base. C'est une situation d'urgence pour le projet. C'est pourquoi il est important de surveiller ces mauvais clients et de r\u00e9agir rapidement. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Un autre exemple de surveillance. Ici, nous avons un tableau de bord d\u00e9cent. Il contient des informations sur les connexions. DB connection - 8. Et c'est tout. Nous n'avons pas d'informations sur les clients actifs, ni sur ceux qui sont simplement inactifs et ne font rien. Il n'y a pas d'informations sur les transactions en attente ni sur les connexions en attente, c'est-\u00e0-dire que ce chiffre montre simplement le nombre de connexions et c'est tout. Ensuite, \u00e0 vous de deviner.
\n\"Les
\nPour ajouter cette information \u00e0 la surveillance, il faut se r\u00e9f\u00e9rer \u00e0 la vue syst\u00e8me pg_stat_activity. Si vous passez beaucoup de temps dans PostgreSQL, cette vue est tr\u00e8s utile et devrait devenir votre alli\u00e9e, car elle montre l'activit\u00e9 actuelle dans PostgreSQL, c'est-\u00e0-dire ce qui s'y passe. Chaque processus dispose d'une ligne distincte qui montre des informations sur ce processus : depuis quel h\u00f4te la connexion a \u00e9t\u00e9 effectu\u00e9e, sous quel utilisateur, sous quel nom, quand la transaction a \u00e9t\u00e9 lanc\u00e9e, quelle requ\u00eate est actuellement ex\u00e9cut\u00e9e et quelle \u00e9tait la derni\u00e8re requ\u00eate ex\u00e9cut\u00e9e. En fonction de cela, nous pouvons \u00e9valuer l'\u00e9tat du client \u00e0 partir du champ stat. En gros, nous pouvons grouper par ce champ et obtenir les stats actuellement pr\u00e9sentes dans la base de donn\u00e9es ainsi que le nombre de connexions associ\u00e9es \u00e0 ce stat dans la base de donn\u00e9es. Les chiffres ainsi obtenus peuvent \u00eatre envoy\u00e9s \u00e0 notre syst\u00e8me de surveillance pour visualiser des graphiques.
\nIl est \u00e9galement important d'\u00e9valuer la dur\u00e9e des transactions. J'ai d\u00e9j\u00e0 mentionn\u00e9 l'importance d'\u00e9valuer la dur\u00e9e des op\u00e9rations de vidage, mais les transactions doivent \u00e9galement \u00eatre \u00e9valu\u00e9es de la m\u00eame mani\u00e8re. Les champs xact_start et query_start montrent respectivement l'heure de d\u00e9but de la transaction et l'heure de d\u00e9but de la requ\u00eate. Nous utilisons la fonction now(), qui affiche le timestamp actuel, et nous soustrayons le timestamp de la transaction et de la requ\u00eate. Cela nous donne la dur\u00e9e de la transaction et la dur\u00e9e de la requ\u00eate. <\/p>\n

<\/p>\n

Si nous constatons des transactions longues, nous devons les annuler. Pour une charge OLTP, des transactions longues sont consid\u00e9r\u00e9es comme celles d\u00e9passant 1 \u00e0 2 \u00e0 3 minutes.<\/strong>. Pour une charge OLAP, des transactions longues sont normales, mais si elles durent plus de deux heures, cela indique \u00e9galement qu'il y a un d\u00e9s\u00e9quilibre quelque part.<\/strong> <\/p>\n

<\/p>\n

\"Les
\nLorsque les clients se connectent \u00e0 la base de donn\u00e9es, ils commencent \u00e0 interagir avec nos donn\u00e9es. Ils acc\u00e8dent aux tables et aux index pour extraire des informations de la table. Il est important d'\u00e9valuer comment les clients interagissent avec ces donn\u00e9es.<\/p>\n

<\/p>\n

Cela est n\u00e9cessaire pour \u00e9valuer notre charge de travail et comprendre quelles tables sont les plus \u00ab chaudes \u00bb. Par exemple, il est utile de savoir quelles tables \u00ab chaudes \u00bb placer sur un stockage SSD rapide. Des tables d'archive, que nous n'utilisons plus depuis longtemps, peuvent \u00eatre d\u00e9plac\u00e9es vers un \u00ab froid \u00bb archive, sur des disques SATA, o\u00f9 elles peuvent rester, et leur acc\u00e8s se fera au besoin. <\/p>\n

<\/p>\n

C'est \u00e9galement utile pour d\u00e9tecter les anomalies apr\u00e8s divers d\u00e9ploiements et mises \u00e0 jour. Imaginons qu'un projet d\u00e9ploie une nouvelle fonctionnalit\u00e9. Par exemple, une nouvelle fonctionnalit\u00e9 pour travailler avec la base de donn\u00e9es. Si nous construisons des graphiques d'utilisation des tables, nous pourrons facilement identifier ces anomalies sur ces graphiques. Par exemple, des pics d'update ou des pics de delete. Cela sera tr\u00e8s visible.<\/p>\n

<\/p>\n

Il est \u00e9galement possible de d\u00e9tecter les anomalies d'une statistique \u00ab floue \u00bb. Qu'est-ce que cela signifie ? PostgreSQL dispose d'un planificateur de requ\u00eates tr\u00e8s performant. Les d\u00e9veloppeurs consacrent beaucoup de temps \u00e0 son d\u00e9veloppement. Comment cela fonctionne-t-il ? Pour construire de bons plans, PostgreSQL collecte p\u00e9riodiquement des statistiques sur la r\u00e9partition des donn\u00e9es dans les tables. Cela inclut les valeurs les plus fr\u00e9quentes : le nombre de valeurs uniques, les informations sur les NULL dans la table, et de nombreuses autres informations. <\/p>\n

<\/p>\n

Sur la base de ces statistiques, le planificateur construit plusieurs requ\u00eates, s\u00e9lectionne la plus optimale et utilise ce plan de requ\u00eate pour ex\u00e9cuter la requ\u00eate elle-m\u00eame et renvoyer les donn\u00e9es. <\/p>\n

<\/p>\n

Il arrive que les statistiques \u00ab flottent \u00bb. La qualit\u00e9 et la quantit\u00e9 des donn\u00e9es dans la table ont chang\u00e9, mais les statistiques n'ont pas \u00e9t\u00e9 mises \u00e0 jour. Les plans g\u00e9n\u00e9r\u00e9s peuvent donc ne pas \u00eatre optimaux. Si nos plans s'av\u00e8rent non optimaux selon le monitoring collect\u00e9, sur les tables, nous pourrons observer ces anomalies. Par exemple, si les donn\u00e9es ont chang\u00e9 qualitativement et qu'un acc\u00e8s s\u00e9quentiel \u00e0 la table est utilis\u00e9 \u00e0 la place de l'index, c'est-\u00e0-dire que si la requ\u00eate doit renvoyer seulement 100 lignes (avec une limitation de 100), alors une recherche compl\u00e8te sera effectu\u00e9e. Cela affecte toujours n\u00e9gativement les performances. <\/p>\n

<\/p>\n

Et nous pourrons le voir dans la surveillance. Nous pourrons \u00e9galement examiner cette requ\u00eate, effectuer un explain, recueillir des statistiques et construire un nouvel index suppl\u00e9mentaire. Et d\u00e9j\u00e0 r\u00e9agir \u00e0 ce probl\u00e8me. C'est pourquoi c'est important. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Un autre exemple de surveillance. Je pense que beaucoup l'ont reconnu, car il est tr\u00e8s populaire. Qui l'utilise dans ses projets Prometheus<\/a><\/noindex>? \u0410 \u043a\u0442\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e \u0441 Prometheus? \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u0432 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u043e\u043c \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438 \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0435\u0441\u0442\u044c \u0434\u0430\u0448\u0431\u043e\u0440\u0434 \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441 PostgreSQL \u2013 postgres_exporter<\/a><\/noindex> Prometheus. Mais il y a un petit inconv\u00e9nient ici. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Il y a plusieurs graphiques. Et en tant qu'unit\u00e9, on indique des octets, c'est-\u00e0-dire qu'il y a 5 graphiques. Cela inclut Insert data, Update data, Delete data, Fetch data et Return data. En tant qu'unit\u00e9 de mesure, on indique des octets. Mais le fait est que les statistiques dans PostgreSQL retournent les donn\u00e9es sous forme de tuples (lignes). Par cons\u00e9quent, ces graphiques sont un tr\u00e8s bon moyen de sous-estimer votre charge de travail plusieurs fois, par dizaines, car un tuple ce n'est pas un octet, un tuple c'est une ligne, c'est beaucoup d'octets, et elle a toujours une longueur variable. Donc, calculer la charge de travail en octets en utilisant des tuples est une t\u00e2che irr\u00e9aliste ou tr\u00e8s compliqu\u00e9e. C'est pourquoi, lorsque vous utilisez un tableau de bord ou une surveillance int\u00e9gr\u00e9e, il est toujours important de comprendre qu'il fonctionne correctement et vous retourne des donn\u00e9es \u00e9valu\u00e9es correctement. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Comment obtenir des statistiques sur ces tables ? Pour cela, PostgreSQL dispose d'une certaine famille de vues. Et la vue principale est pg_stat_user_tables<\/a><\/noindex>. User_tables signifie que les tables ont \u00e9t\u00e9 cr\u00e9\u00e9es au nom de l'utilisateur. En revanche, il y a les vues syst\u00e8me qui sont utilis\u00e9es par PostgreSQL lui-m\u00eame. Et il y a une table r\u00e9capitulative Alltables, qui inclut \u00e0 la fois les syst\u00e8mes et les utilisateurs. Vous pouvez vous baser sur l'une d'elles, celle que vous pr\u00e9f\u00e9rez.<\/p>\n

<\/p>\n

\u00c0 partir des champs mentionn\u00e9s ci-dessus, on peut \u00e9valuer le nombre d'inserts, de mises \u00e0 jour et de suppressions. L'exemple de tableau de bord que j'ai utilis\u00e9 utilise pr\u00e9cis\u00e9ment ces champs pour \u00e9valuer les caract\u00e9ristiques de la charge de travail. Donc, nous pouvons \u00e9galement nous en baser. Mais il convient de se rappeler que ce sont des tuples, et non des octets, donc nous ne pouvons pas simplement le convertir en octets.<\/p>\n

<\/p>\n

Sur la base de ces donn\u00e9es, nous pouvons construire ce que l'on appelle des tables TopN. Par exemple, Top-5, Top-10. Et nous pouvons suivre les tables chaudes qui sont utilis\u00e9es plus que les autres. Par exemple, les 5 \u00ab chaudes \u00bb en termes d'insertion. Et \u00e0 partir de ces tables TopN, nous \u00e9valuons notre charge de travail et pouvons \u00e9valuer les pics de charge apr\u00e8s chaque release, mise \u00e0 jour et d\u00e9ploiement. <\/p>\n

<\/p>\n

Il est \u00e9galement important d'\u00e9valuer les tailles des tables, car parfois les d\u00e9veloppeurs d\u00e9ploient une nouvelle fonctionnalit\u00e9 et nos tables commencent \u00e0 gonfler en taille, car ils d\u00e9cident d'ajouter un volume de donn\u00e9es suppl\u00e9mentaire sans pr\u00e9voir comment cela affectera la taille de la base de donn\u00e9es. De tels cas peuvent aussi \u00eatre des surprises pour nous. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Et maintenant, une petite question pour vous. Quelle est la question qui vous vient \u00e0 l'esprit quand vous remarquez une charge sur le serveur de base de donn\u00e9es ? Quelle est la prochaine question qui vous vient ? <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Mais en r\u00e9alit\u00e9, la question suivante se pose. Quelles requ\u00eates provoquent la charge ? C'est-\u00e0-dire qu'il n'est pas int\u00e9ressant de regarder les processus qui causent la charge. Il est \u00e9vident que si le host a la base de donn\u00e9es, alors une base de donn\u00e9es y est en cours d'ex\u00e9cution et il est \u00e9vident que seules les bases de donn\u00e9es l'utiliseront. Si nous ouvrons Top, nous verrons une liste de processus dans PostgreSQL qui font quelque chose. Avec Top, on ne peut pas comprendre ce qu'ils font. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Par cons\u00e9quent, il est n\u00e9cessaire de d\u00e9tecter les requ\u00eates qui provoquent la charge la plus importante, car le tuning des requ\u00eates, en g\u00e9n\u00e9ral, offre plus de profits que le tuning de la configuration de PostgreSQL ou du syst\u00e8me d'exploitation, voire du mat\u00e9riel. \u00c0 mon avis, cela repr\u00e9sente environ 80-85-90 %. Et cela se fait beaucoup plus rapidement. Il est plus rapide de corriger une requ\u00eate que d'ajuster la configuration, de planifier un red\u00e9marrage, surtout si la base ne peut pas \u00eatre red\u00e9marr\u00e9e, ou d'ajouter du mat\u00e9riel. Il est plus simple de r\u00e9\u00e9crire une requ\u00eate ou d'ajouter un index pour obtenir de meilleurs r\u00e9sultats. <\/p>\n

<\/p>\n

\"Les
\nPar cons\u00e9quent, il est n\u00e9cessaire de surveiller les requ\u00eates et leur ad\u00e9quation. Prenons un autre exemple de surveillance. Ici aussi, c'est un bon monitoring. Il y a des informations sur la r\u00e9plication, des informations sur la bande passante, les verrouillages, l'utilisation des ressources. Tout est parfait, mais il manque des informations sur les requ\u00eates. Il n'est pas clair quelles requ\u00eates s'ex\u00e9cutent dans notre base de donn\u00e9es, combien de temps elles prennent, combien il y en a. Nous avons toujours besoin de ces informations dans le monitoring. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Et pour obtenir ces informations, nous pouvons utiliser le module pg_stat_statements. Sur cette base, il est possible de construire divers graphiques. Par exemple, nous pouvons obtenir des informations sur les requ\u00eates les plus fr\u00e9quentes, c'est-\u00e0-dire celles qui sont ex\u00e9cut\u00e9es le plus souvent. Oui, apr\u00e8s les d\u00e9ploiements, il est \u00e9galement tr\u00e8s utile de le consulter pour comprendre s'il y a eu une augmentation soudaine des requ\u00eates. <\/p>\n

<\/p>\n

Nous pouvons surveiller les requ\u00eates les plus longues, c'est-\u00e0-dire celles qui prennent le plus de temps \u00e0 s'ex\u00e9cuter. Elles sollicitent le processeur et consomment des entr\u00e9es-sorties. Nous pouvons \u00e9galement \u00e9valuer cela \u00e0 partir des champs total_time, mean_time, blk_write_time et blk_read_time. <\/p>\n

<\/p>\n

Nous pouvons \u00e9valuer et surveiller les requ\u00eates les plus lourdes en termes d'utilisation des ressources, celles qui lisent depuis le disque, qui fonctionnent avec la m\u00e9moire ou, au contraire, qui cr\u00e9ent une charge d'\u00e9criture.<\/p>\n

<\/p>\n

Nous pouvons \u00e9valuer les requ\u00eates les plus g\u00e9n\u00e9reuses. Ce sont celles qui retournent un grand nombre de lignes. Par exemple, il peut s'agir d'une requ\u00eate o\u00f9 il a \u00e9t\u00e9 oubli\u00e9 de d\u00e9finir une limite. Elle renvoie alors tout le contenu de la table ou des tables demand\u00e9es.<\/p>\n

<\/p>\n

Il est \u00e9galement possible de surveiller les requ\u00eates qui utilisent des fichiers temporaires ou des tables temporaires. <\/p>\n

<\/p>\n

\"Les
\nEt il nous reste des processus en arri\u00e8re-plan. Les processus en arri\u00e8re-plan sont d'abord les checkpoints, \u00e9galement appel\u00e9s points de contr\u00f4le, ainsi que l'autovacuum et la r\u00e9plication. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Un autre exemple de surveillance. Il y a un onglet Maintenance \u00e0 gauche, nous y acc\u00e9dons en esp\u00e9rant voir quelque chose d'utile. Mais ici, il n'y a que le temps de fonctionnement du vacuum et de collecte des statistiques, rien de plus. C'est une information tr\u00e8s pauvre, donc il est toujours n\u00e9cessaire d'avoir des informations sur le fonctionnement de nos processus en arri\u00e8re-plan et s'il n'y a pas de probl\u00e8mes li\u00e9s \u00e0 leur activit\u00e9. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Lorsque nous examinons les points de contr\u00f4le, il est important de rappeler que les points de contr\u00f4le r\u00e9initialisent les pages \u00ab sales \u00bb de la m\u00e9moire shard\u00e9e sur le disque, puis cr\u00e9ent un point de contr\u00f4le. Ce point de contr\u00f4le peut ensuite \u00eatre utilis\u00e9 comme un moyen de restauration, si jamais PostgreSQL a \u00e9t\u00e9 arr\u00eat\u00e9 de mani\u00e8re inattendue. <\/p>\n

<\/p>\n

Par cons\u00e9quent, pour vider toutes les pages \u00ab sales \u00bb sur le disque, il faut effectuer un certain volume d'\u00e9criture. Et, en r\u00e8gle g\u00e9n\u00e9rale, sur les syst\u00e8mes avec une grande capacit\u00e9 m\u00e9moire, cela repr\u00e9sente beaucoup. Et si nos checkpoints sont effectu\u00e9s tr\u00e8s fr\u00e9quemment sur une courte p\u00e9riode, alors la performance du disque va chuter consid\u00e9rablement. Les requ\u00eates clients souffriront d'un manque de ressources. Elles se battront pour les ressources et leur performance sera insuffisante. <\/p>\n

<\/p>\n

Ainsi, \u00e0 travers pg_stat_bgwriter, nous pouvons surveiller le nombre de checkpoints qui se produisent en fonction des champs sp\u00e9cifi\u00e9s. Et si, sur une p\u00e9riode donn\u00e9e (par exemple, 10-15-20 minutes, une demi-heure), nous avons beaucoup de checkpoints, par exemple 3-4-5, cela peut d\u00e9j\u00e0 poser probl\u00e8me. Il est alors n\u00e9cessaire de v\u00e9rifier la base de donn\u00e9es, de regarder la configuration pour voir ce qui cause cette abondance de checkpoints. Peut-\u00eatre qu'il y a une grande transaction en cours. \u00c0 partir de la charge de travail, nous pouvons d\u00e9j\u00e0 \u00e9valuer, car nous avons les graphiques de charge de travail qui sont d\u00e9j\u00e0 ajout\u00e9s. Nous pouvons d\u00e9j\u00e0 ajuster les param\u00e8tres des points de contr\u00f4le de mani\u00e8re \u00e0 ce qu'ils n'impactent pas trop la performance des requ\u00eates.<\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Je reviens encore \u00e0 l'autovacuum, car c'est une fonctionnalit\u00e9, comme je l'ai d\u00e9j\u00e0 mentionn\u00e9, qui peut facilement affecter la performance tant des disques que des requ\u00eates. Il est donc toujours important d'\u00e9valuer le nombre d'autovacuum. <\/p>\n

<\/p>\n

Le nombre de travailleurs autovacuum dans la base de donn\u00e9es est limit\u00e9. Par d\u00e9faut, il y en a trois ; donc si nous avons toujours trois travailleurs qui fonctionnent dans la base, cela signifie que notre autovacuum est mal configur\u00e9, il faut augmenter les limites, revoir les param\u00e8tres de l'autovacuum et aller v\u00e9rifier la configuration.
\nIl est important d'\u00e9valuer quels travailleurs de vacuum sont actifs. Soit ils sont lanc\u00e9s par un utilisateur, le DBA est venu et a lanc\u00e9 manuellement un vacuum, ce qui a cr\u00e9\u00e9 une charge. Nous avons alors un probl\u00e8me. Soit c'est le nombre de vacuums qui r\u00e9initialisent le compteur de transactions. Pour certaines versions de PostgreSQL, ce sont des vacuums tr\u00e8s lourds. Et ils peuvent facilement impacter la performance, car ils parcourent toute la table dans son int\u00e9gralit\u00e9 et scannent tous les blocs de cette table. <\/p>\n

<\/p>\n

Et bien s\u00fbr, la dur\u00e9e des op\u00e9rations de vide. Si nous avons des longues op\u00e9rations de vide qui durent longtemps, cela signifie qu'il est \u00e0 nouveau temps de se pencher sur la configuration du vide et peut-\u00eatre de revoir ses param\u00e8tres. Parce qu'il peut y avoir une situation o\u00f9 le vide fonctionne sur une table pendant longtemps (3-4 heures), mais pendant que le vide fonctionne, un grand volume de lignes mortes peut s'accumuler de nouveau dans la table. Et d\u00e8s que le vide se termine, il doit \u00e0 nouveau effectuer une op\u00e9ration de vide sur cette table. Nous arrivons donc \u00e0 une situation de vide infini. Dans ce cas, le vide ne remplit pas son r\u00f4le, et les tables commencent progressivement \u00e0 gonfler en taille, m\u00eame si le volume de donn\u00e9es utiles reste le m\u00eame. Par cons\u00e9quent, lors de longues op\u00e9rations de vide, nous examinons toujours la configuration et essayons de l'optimiser, tout en veillant \u00e0 ce que les performances des requ\u00eates des clients ne souffrent pas. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Actuellement, il n'y a pratiquement aucune installation de PostgreSQL sans r\u00e9plication en continu. La r\u00e9plication est le processus de transfert de donn\u00e9es du ma\u00eetre vers la r\u00e9plique.<\/p>\n

<\/p>\n

La r\u00e9plication dans PostgreSQL fonctionne \u00e0 travers le journal des transactions. Le ma\u00eetre g\u00e9n\u00e8re le journal des transactions. Ce journal de transaction est envoy\u00e9 \u00e0 la r\u00e9plique via une connexion r\u00e9seau, puis il est reproduit sur la r\u00e9plique. C'est simple. <\/p>\n

<\/p>\n

En cons\u00e9quence, pour surveiller le retard de r\u00e9plication, on utilise la vue pg_stat_replication. Mais ce n'est pas toujours simple. Dans la version 10, la vue a subi plusieurs modifications. Tout d'abord, certains champs ont \u00e9t\u00e9 renomm\u00e9s. Et certains champs ont \u00e9t\u00e9 ajout\u00e9s. Dans la version 10, des champs permettant d'\u00e9valuer le retard de r\u00e9plication en secondes sont apparus. C'est tr\u00e8s pratique. Avant la version 10, il \u00e9tait possible d'\u00e9valuer le retard de r\u00e9plication en octets. Cette option est toujours disponible dans la version 10, c'est-\u00e0-dire que vous pouvez choisir ce qui vous convient le mieux - \u00e9valuer le retard en octets ou en secondes. Beaucoup font les deux.<\/p>\n

<\/p>\n

N\u00e9anmoins, pour \u00e9valuer le retard de r\u00e9plication, il est n\u00e9cessaire de conna\u00eetre la position du journal dans la transaction. Ces positions du journal de transaction se trouvent justement dans la vue pg_stat_replication. En d'autres termes, \u00e0 l'aide de la fonction pg_xlog_location_diff(), nous pouvons prendre deux points dans le journal des transactions. Calculer la diff\u00e9rence entre eux et obtenir le retard de r\u00e9plication en octets. C'est tr\u00e8s pratique et simple. <\/p>\n

<\/p>\n

Dans la version 10, cette fonction a \u00e9t\u00e9 renomm\u00e9e en pg_wal_lsn_diff(). En g\u00e9n\u00e9ral, dans toutes les fonctions, vues et utilitaires o\u00f9 le mot \u00ab xlog \u00bb \u00e9tait pr\u00e9sent, il a \u00e9t\u00e9 remplac\u00e9 par \u00ab wal \u00bb. Cela concerne tant les vues que les fonctions. C\u2019est une nouveaut\u00e9. <\/p>\n

<\/p>\n

De plus, dans la version 10, des lignes ont \u00e9t\u00e9 ajout\u00e9es pour indiquer sp\u00e9cifiquement le retard. Il s'agit de write lag, flush lag, replay lag. C'est-\u00e0-dire qu'il est important de surveiller ces \u00e9l\u00e9ments. Si nous constatons un retard de r\u00e9plication, il est n\u00e9cessaire d'explorer pourquoi il est apparu, d'o\u00f9 il vient et de r\u00e9soudre le probl\u00e8me. <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Les m\u00e9triques syst\u00e8me sont pratiquement toutes en ordre. Lorsqu'un syst\u00e8me de surveillance se met en place, il commence par des m\u00e9triques syst\u00e8mes. Cela inclut l'utilisation du processeur, de la m\u00e9moire, des swaps, du r\u00e9seau et du disque. Cependant, de nombreux param\u00e8tres ne figurent pas par d\u00e9faut. <\/p>\n

<\/p>\n

Si l'utilisation du processus est correcte, il y a des probl\u00e8mes avec l'utilisation du disque. En g\u00e9n\u00e9ral, les d\u00e9veloppeurs de syst\u00e8mes de surveillance ajoutent des informations sur la bande passante. Cela peut \u00eatre en IOPS ou en octets. Mais ils oublient la latence et l'utilisation des dispositifs de stockage. Ce sont des param\u00e8tres plus importants qui permettent d'\u00e9valuer \u00e0 quel point nos disques sont charg\u00e9s et combien ils ralentissent. Si nous avons une latence \u00e9lev\u00e9e, cela signifie qu'il y a des probl\u00e8mes avec les disques. Si nous avons une utilisation \u00e9lev\u00e9e, cela signifie que les disques ne fonctionnent pas correctement.<\/strong> Ce sont des caract\u00e9ristiques de qualit\u00e9 sup\u00e9rieure par rapport \u00e0 la bande passante.<\/p>\n

<\/p>\n

Bien que ces statistiques puissent \u00e9galement \u00eatre obtenues \u00e0 partir du syst\u00e8me de fichiers \/proc, comme c'est le cas pour l'utilisation du processeur. Je ne sais pas pourquoi cette information n'est pas ajout\u00e9e aux syst\u00e8mes de surveillance. Cependant, il est important de l'avoir dans votre syst\u00e8me de surveillance.<\/strong> <\/p>\n

<\/p>\n

Il en va de m\u00eame pour les interfaces r\u00e9seau. Il existe des informations sur la bande passante r\u00e9seau en paquets, en octets, mais il n'y a pas d'informations sur la latence et sur l'utilisation, bien que cela soit \u00e9galement utile.<\/strong> <\/p>\n

<\/p>\n

\"Les<\/p>\n

<\/p>\n

Tous les syst\u00e8mes de surveillance ont des inconv\u00e9nients. Quel que soit le syst\u00e8me de surveillance que vous choisissez, il ne correspondra toujours pas \u00e0 certains crit\u00e8res. Cependant, ils \u00e9voluent, de nouvelles fonctionnalit\u00e9s et \u00e9l\u00e9ments sont ajout\u00e9s, donc choisissez quelque chose et peaufinez-le. <\/p>\n

<\/p>\n

Et pour peaufiner, il est toujours n\u00e9cessaire d'avoir une id\u00e9e de ce que signifie la statistique fournie et comment l'utiliser pour r\u00e9soudre des probl\u00e8mes. <\/p>\n

<\/p>\n

Et quelques points cl\u00e9s :<\/p>\n

<\/p>\n