Résoudre les problèmes d’utilisation élevée du processeur dans Azure Database pour PostgreSQL - Serveur flexible
S’APPLIQUE À :
Azure Database pour PostgreSQL - Serveur flexible
Cet article explique comment identifier rapidement la cause racine de l’utilisation élevée du processeur et les actions correctives possibles pour contrôler l’utilisation du processeur lors de l’utilisation de Azure Database pour PostgreSQL serveur flexible.
Cet article porte sur les points suivants :
- À propos des guides de résolution des problèmes pour identifier et obtenir des recommandations afin d’atténuer les causes racines.
- Présentation des outils permettant d’identifier une utilisation élevée du processeur, comme les métriques Azure, le magasin des requêtes et pg_stat_statements.
- Comment identifier les causes racines, comme les requêtes longues et le nombre total de connexions.
- Comment résoudre l’utilisation élevée du processeur à l’aide des tables d’analyse, le regroupement de connexions et le nettoyage.
Guides de résolution des problèmes
L’utilisation des guides de résolution des problèmes de fonctionnalités disponibles sur le portail de serveur flexible Azure Database pour PostgreSQL la cause racine probable et les recommandations pour atténuer le scénario de processeur élevé sont disponibles. Pour savoir comment configurer les guides de résolution des problèmes, consultez Configurer des guides de résolution des problèmes.
Outils permettant d’identifier une utilisation élevée du processeur
Tenez compte de ces outils pour identifier une utilisation élevée du processeur.
Métriques Azure
Les métriques Azure constituent un bon point de départ pour vérifier l’utilisation du processeur pour la date et la période définies. Les métriques fournissent des informations sur la durée pendant laquelle l’utilisation du processeur est élevée. Comparez les graphiques d’E/S par seconde d’écriture, d’E/S de lecture, de débit de lecture et de débit d’écriture avec l’utilisation du processeur pour déterminer les heures où la charge de travail a provoqué une utilisation élevée du processeur. Pour une surveillance proactive, vous pouvez configurer des alertes sur les métriques. Pour obtenir des instructions pas à pas, consultez Métriques Azure.
Magasin des requêtes
Le Magasin des requêtes capture automatiquement l’historique des requêtes et des statistiques d’exécution, et les conserve pour que vous les passiez en revue. Il découpe les données par heure de façon à ce que vous puissiez voir des modèles d’utilisation temporelle. Les données de tous les utilisateurs, bases de données et requêtes sont stockées dans une base de données nommée azure_sys dans l’instance de serveur flexible Azure Database pour PostgreSQL. Pour des conseils étape par étape, consultez Magasin de requêtes.
pg_stat_statements
L’extension pg_stat_statements permet d’identifier les requêtes qui consomment du temps sur le serveur.
Durée moyenne d’exécution
Pour Postgres versions 13 et ultérieures, utilisez l’instruction suivante pour afficher les cinq premières instructions SQL par durée moyenne d’exécution :
SELECT userid::regrole, dbid, query, mean_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time
DESC LIMIT 5;
Durée d'exécution totale
Exécutez les instructions suivantes pour afficher les cinq premières instructions SQL par durée d’exécution totale.
Pour Postgres versions 13 et ultérieures, utilisez l’instruction suivante pour afficher les cinq premières instructions SQL par durée totale d’exécution :
SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY total_exec_time
DESC LIMIT 5;
Identifier les causes racines
Si les niveaux de consommation du processeur sont élevés en général, les causes racines peuvent être les suivantes :
Transactions de longue durée
Les transactions de longue durée peuvent consommer des ressources processeur, ce qui peut entraîner une utilisation élevée du processeur.
La requête suivante permet d’identifier les connexions s’exécutant le plus longtemps :
SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;
Nombre total de connexions et nombre de connexions par état
Un grand nombre de connexions à la base de données est également un autre problème qui peut entraîner une augmentation de l’utilisation du processeur et de la mémoire.
La requête suivante fournit des informations sur le nombre de connexions par état :
SELECT state, count(*)
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
GROUP BY 1 ORDER BY 1;
Résoudre l’utilisation élevée de l’UC
Utilisez l’analyse EXPLAIN, PG Bouncer, le regroupement de connexions et arrêtez les transactions de longue durée pour résoudre une utilisation élevée du processeur.
Utiliser l’analyse de l’explication
Une fois que vous connaissez la requête de longue durée, utilisez EXPLAIN pour approfondir l’examen de la requête et l’ajuster.
Pour plus d’informations sur la commande EXPLAIN, passez en revue EXPLAIN PLAN.
PGBouncer et regroupement de connexions
Dans les situations où il existe un grand nombre de connexions inactives ou de nombreuses connexions qui consomment des ressources processeur, envisagez d’utiliser un pool de connexions comme PgBouncer.
Pour plus d’informations sur PgBouncer, consultez :
Azure Database pour PostgreSQL serveur flexible offre PgBouncer comme solution de regroupement de connexions intégrée. Pour plus d’informations, consultez la section PgBouncer
Mettre fin aux transactions durables
Vous pouvez envisager de tuer une transaction longue en tant qu’option.
Pour terminer le PID d’une session, vous devez détecter le PID à l’aide de la requête suivante :
SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;
Vous pouvez également filtrer par d’autres propriétés comme usename (nom d’utilisateur), datname (nom de la base de données), etc.
Une fois que vous disposez du PID de la session, vous pouvez la terminer à l’aide de la requête suivante :
SELECT pg_terminate_backend(pid);
Surveiller des statistiques de vide et de table
La mise à jour des statistiques de table permet d’améliorer les performances des requêtes. Vérifiez si le nettoyage automatique régulier est effectué.
La requête suivante permet d’identifier les tables qui ont besoin d’un nettoyage :
select schemaname,relname,n_dead_tup,n_live_tup,last_vacuum,last_analyze,last_autovacuum,last_autoanalyze
from pg_stat_all_tables where n_live_tup > 0;
Les colonnes last_autovacuum et last_autoanalyze indiquent la date et l’heure auxquelles la table a été analysée ou nettoyée pour la dernière fois. Si les tables ne sont pas nettoyées régulièrement, prenez des mesures pour régler le nettoyage automatique. Pour plus d’informations sur la résolution des problèmes et le réglage du nettoyage automatique, consultez Résolution des problèmes de nettoyage automatique.
Une solution à court terme consisterait à effectuer une analyse manuelle du nettoyage des tables où les requêtes lentes sont observées :
vacuum analyze <table_name>;