Voulez-vous savoir pourquoi une requête PostgreSQL est lente ? Alors EXPLAIN ANALYZE est un excellent point de départ. Mais les plans de requête peuvent dépendre d'autres activités du serveur, peuvent prendre un certain temps à s'exécuter et peuvent changer avec le temps, donc si vous voulez voir les plans d'exécution réels de vos requêtes les plus lentes, auto_explain est l'outil dont vous avez besoin. Dans cet article, nous verrons ce qu'il fait, comment le configurer et comment utiliser ces journaux pour accélérer vos requêtes.
Qu'est-ce que l'auto_explain ?
auto_explain est une extension PostgreSQL qui vous permet de consigner les plans de requête pour les requêtes plus lentes qu'un seuil (configurable). Ceci est incroyablement utile pour déboguer les requêtes lentes, en particulier celles qui ne posent que parfois problème. C'est l'un des modules de contribution, il peut donc être installé et configuré facilement sur PostgreSQL standard, et est si utile que nous l'avons activé par défaut sur ScaleGrid.
Un grand merci à Takahiro Itagaki, l'auteur principal de la première version d'auto_explain (commit, thread), Dean Rasheed, dont le correctif et la suggestion initiaux sont basés sur, et les nombreux contributeurs et réviseurs depuis.
Quels paramètres auto_explain dois-je utiliser ?
Ci-dessous, nous aborderons les paramètres les plus importants, mais veuillez consulter le tableau ci-dessous, ou la documentation officielle, pour plus d'informations sur l'éventail complet des éléments que vous pouvez suivre.
Le paramètre le plus important pour auto_explain est log_min_duration . Par défaut, il est défini sur -1 , ce qui signifie que rien ne sera enregistré - donc si nous voulons des journaux, nous devons les changer ! L'unité par défaut est ms, donc un paramètre de 100 enregistrera les plans de requête pour toutes les requêtes qui dépassent 100 ms. C'est ce que nous avons choisi par défaut dans ScaleGrid, mais il peut être configuré sous Admin -> Config. Si, pour une raison quelconque, vous souhaitez enregistrer le plan de requête pour chaque requête, vous pouvez le définir sur 0 - mais attention, cela peut avoir de graves conséquences sur les performances.
Étant donné que les requêtes sont déjà en cours d'exécution sur le serveur, vous souhaitez probablement également activer auto_explain.log_analyze . Cela rend la sortie équivalente à l'exécution de EXPLAIN ANALYZE . Par défaut, cela signifie également que les minutages par opération sont suivis. Cela s'accompagne d'une surcharge supplémentaire, qui peut être minimisée en désactivant auto_explain.log_timing (activé par défaut avec log_analyze ). Naturellement cependant, les minutages par opération sont très utiles lors du débogage de requêtes lentes ! Nos tests internes ont montré des frais généraux acceptables pour cela, il est donc activé par défaut dans ScaleGrid, mais comme toujours, veuillez tester votre charge de travail pour voir si les frais généraux sont acceptables dans votre cas. Il existe actuellement peu d'informations accessibles au public sur ce sujet, mais un article récent de l'équipe pgMustard a montré que, au moins sur une petite charge de travail transactionnelle, la surcharge peut être aussi faible que 2 %. Comme ils l'ont noté, cela pourrait être réduit avec le auto_explain.sample_rate paramètre, au prix de ne suivre qu'un sous-ensemble de vos requêtes.
Le dernier paramètre dont nous parlerons un peu en détail est auto_explain.log_format . La sortie par défaut est TEXT, ce qui est probablement ce que vous connaissez le mieux en utilisant EXPLAIN .
Voici un exemple simple de ce à quoi peut ressembler la sortie auto_explain au format TEXT :
2021-09-10 15:32:04.606 BST [22770] LOG: duration: 3184.383 ms plan: Query Text: select * from table1 order by column1; Sort (cost=12875.92..13125.92 rows=100000 width=37) (actual time=2703.799..3055.401 rows=100000 loops=1) Sort Key: column1 Sort Method: external merge Disk: 4696kB Buffers: shared hit=837, temp read=587 written=589 -> Seq Scan on table (cost=0.00..1834.01 rows=100000 width=37) (actual time=0.033..27.795 rows=100000 loops=1) Buffers: shared hit=834
Vous pouvez voir ici que vous obtenez la durée de la requête au début, ce que vous avez peut-être l'habitude de voir à la fin des plans de requête. Vous verrez également le texte de la requête, y compris tous les paramètres.
Les outils de visualisation populaires expliquer.depesz et expliquer.dalibo acceptent tous les deux les plans de requête au format TEXT, mais ils prennent également en charge le format JSON. Si certains membres de votre équipe préfèrent utiliser des outils tels que PEV et pgMustard, qui ne prennent en charge que le format JSON, vous souhaiterez peut-être le définir comme format. Pour les clients de ScaleGrid, nous avons opté pour le format JSON, en partie parce que nous voulions l'analyser plus facilement pour notre propre fonctionnalité d'analyse lente des requêtes.
Voici une liste complète des paramètres auto_explain et leurs valeurs par défaut :
| Paramètre | Paramètres par défaut de PostgreSQL | ScaleGrid par défaut |
|---|---|---|
| auto_explain.log_min_duration | -1 | 100 |
| auto_explain.log_analyze | Désactivé | Activé |
| auto_explain.log_timing | Activé (avec log_analyze) | Activé |
| auto_explain.log_buffers | Désactivé | Activé |
| auto_explain.log_verbose | Désactivé | Activé |
| auto_explain.log_triggers | Désactivé | Désactivé |
| auto_explain.log_nested_statements | Désactivé | Désactivé |
| auto_explain.log_settings (v12) | Désactivé | Désactivé |
| auto_explain.log_wal (v13) | Désactivé | Désactivé |
| auto_explain.log_format | TEXTE | JSON |
| auto_explain.log_level | LOG | LOG |
| auto_explain.sample_rate | 1 | 1 |
Installer auto_explain
Sur ScaleGrid, auto_explain est activé par défaut, avec un seuil de 100 ms. Vous pouvez le configurer sous Admin -> Config.
Sur vanilla PostgreSQL, vous pouvez installer auto_explain simplement en l'ajoutant à l'une des session_preload_libraries ou shared_preload_libraries . Le premier présente les avantages a) de ne pas nécessiter de redémarrage (mais il ne sera chargé que dans les nouvelles sessions) et b) de ne permettre de l'activer que pour certains utilisateurs (en définissant ce paramètre avec ALTER ROLE SET ).
Ainsi, une configuration de base pour auto_explain pourrait ressembler à ceci :
session_preload_libraries = auto_explain auto_explain.log_min_duration = 100 auto_explain.log_analyze = true auto_explain.log_buffers = true auto_explain.log_format = JSON
Si vous utilisez un autre fournisseur d'hébergement, il vaut la peine de vérifier s'il prend en charge auto_explain. Par exemple, RDS Postgres le fait, mais contrairement à ScaleGrid, il est désactivé par défaut, vous devrez donc modifier la configuration pour le faire fonctionner.
Charger auto_explain en une seule session
Si vous ne souhaitez pas que l'auto_explain s'exécute automatiquement dans les sessions, en tant que superutilisateur, vous avez également la possibilité de le charger dans une seule session :
LOAD 'auto_explain';
Cela peut être extrêmement utile pour les sessions de débogage ponctuelles, mais il est naturellement inutile si vous pouvez déjà l'exécuter.
limitations et pièges de l'explication automatique
Nous en avons déjà mentionné quelques-uns en passant, mais le moment semble opportun pour nous rappeler certains des inconvénients et des limites d'auto_explain.
Tout d'abord, en particulier lors du suivi des délais par opération, l'utilisation d'auto_explain peut entraîner une surcharge mesurable. Il peut être faible, même avec des chronométrages mesurés, mais comme toujours, cela vaut la peine de faire vos propres tests.
Deuxièmement, les délais d'auto_explain sont exclusifs du temps de planification des requêtes. Le temps de planification est souvent minime pour les requêtes lentes, mais dans des cas exceptionnels, il peut être responsable de la majorité du problème. En tant que tel, gardez à l'esprit que ces cas peuvent ne pas apparaître dans vos journaux, ou s'ils le font, un écart avec ce que vous voyez dans la latence totale peut être lié au temps de planification. Un manuel EXPLAIN ANALYZE vous aidera rapidement à le repérer.
Comment utiliser la sortie d'explication pour accélérer les requêtes
Une fois que vous avez la sortie d'explication pour vos requêtes les plus lentes, vous pouvez maintenant commencer à chercher à les accélérer !
Vous devrez extraire les plans de requête des journaux, pour lesquels vous pouvez utiliser pgBadger si vous n'utilisez pas un service géré qui le fait pour vous.
L'examen des plans EXPLAIN est un vaste sujet en soi. La documentation PostgreSQL comprend une bonne mais brève introduction à l'utilisation d'EXPLAIN, et l'article de Thoughbot sur la lecture d'EXPLAIN ANALYZE est une bonne prochaine étape. Si vous préférez une conversation d'une heure, EXPLAIN Explained de Josh Berkus était excellent. Pour plus d'informations, Depesz a une série d'articles intitulée Expliquer l'inexplicable et l'équipe de pgMustard a un glossaire EXPLAIN assez complet.
Si vous avez besoin de l'aide d'experts PostgreSQL pour gérer vos bases de données et accélérer vos requêtes lentes, essayez ScaleGrid. Nous fournissons une assistance professionnelle gratuite 24h/24 et 7j/7 qui peut vous guider dans ces requêtes lentes et vous aider à les optimiser. Notre essai gratuit de 30 jours vous donne amplement le temps d'essayer nos nombreuses fonctionnalités pour PostgreSQL et nos autres bases de données prises en charge.
Nous espérons que cela vous donne tout ce dont vous avez besoin pour démarrer avec auto_explain et commencer à accélérer toutes les requêtes lentes que vous avez. S'il y a autre chose que vous aimeriez savoir, contactez-nous.
