Partager via

Résoudre les problèmes d’utilisation élevée du processeur dans un serveur flexible Azure Database pour PostgreSQL

S’APPLIQUE À : Azure Database pour PostgreSQL – Serveur flexible

Cet article explique comment identifier la cause racine de l’utilisation élevée du processeur. Il fournit également des actions correctives possibles pour contrôler l’utilisation du processeur lors de l’utilisation du serveur flexible Azure Database pour PostgreSQL.

Cet article porte sur les points suivants :

  • Guides de résolution des problèmes pour identifier et obtenir des suggestions afin d’atténuer les causes racines.
  • 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 durables et le nombre total de connexions.
  • Comment résoudre l’utilisation élevée du processeur en utilisant EXPLAIN ANALYZE, le regroupement de connexions et les tables de nettoyage.

Guides de résolution des problèmes

L’utilisation des guides sur la résolution des problèmes vous permet d’identifier la cause racine probable d’un scénario de processeur élevé et de lire les suggestions pour atténuer le problème trouvé.

Pour savoir comment configurer et utiliser les guides de résolution des problèmes, suivez Configurer les guides de résolution des problèmes.

Outils permettant d’identifier une utilisation élevée du processeur

Envisagez d’utiliser la liste d’outils suivante 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 pendant une période spécifique. Les métriques fournissent des informations sur les ressources utilisées pendant la période pendant laquelle l’utilisation du processeur est élevée. Comparez les graphiques d’E/S par seconde en écriture, d’E/S par seconde en lecture, de débit de lecture en octets/s et de octets de débit en écriture/s avec le pourcentage du processeur pour déterminer les heures où la charge de travail a provoqué une utilisation élevée du processeur.

Pour avoir un monitoring proactif, 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 les 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 l’ensemble des utilisateurs, bases de données et requêtes sont stockées dans une base de données nommée azure_sys dans l’instance du serveur flexible Azure Database pour PostgreSQL.

Le magasin des requêtes peut mettre en corrélation les informations d’événements d’attente avec les statistiques d’exécution des requêtes. Utilisez le magasin des requêtes pour identifier les requêtes qui ont une consommation élevée de mémoire pendant la période d’intérêt.

Pour découvrir plus d’informations, consultez magasin des requêtes.

pg_stat_statements

L’extension pg_stat_statements permet d’identifier les requêtes qui consomment du temps sur le serveur. Pour découvrir plus d’informations sur cette extension, consultez sa documentation.

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 de manière générale, 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 sont également susceptibles d’entraîner une utilisation élevée 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 state
ORDER BY state ASC;

Résoudre l’utilisation élevée du processeur

Utilisez EXPLAIN ANALYZE, envisagez d’utiliser le regroupement de connexions PgBouncer intégré et arrêtez les transactions durables pour résoudre une utilisation élevée du processeur.

Utiliser EXPLAIN ANALYZE

Une fois que vous connaissez les requêtes qui augmentent l’utilisation du processeur, utilisez EXPLAIN ANALYZE pour les étudier plus en détail et les ajuster.

Pour plus d’informations sur la commande EXPLAIN ANALYZE, consultez sa documentation.

PgBouncer, un regroupement de connexions intégré

Dans les situations où il existe de nombreuses connexions de courte durée, ou de nombreuses connexions qui restent inactives pour la plupart de leur vie, envisagez d’utiliser un regroupement de connexions comme PgBouncer.

Pour découvrir plus d’informations sur PgBouncer, consultez Regroupement de connexions et les Meilleures pratiques de gestion des connexions avec PostgreSQL

Azure Database pour PostgreSQL – Serveur flexible offre PgBouncer comme solution de regroupement de connexions intégrée. Pour découvrir plus d’informations, consultez la section PgBouncer.

Terminer les transactions durables

Vous pouvez envisager de tuer une transaction durable en tant qu’option.

Pour terminer le PID d’une session, vous devez trouver son PID avec 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 en utilisant la requête suivante :

SELECT pg_terminate_backend(pid);

Monitorer statistiques de table et de nettoyage

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 découvrir 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 consistera à effectuer une analyse manuelle du nettoyage des tables où les requêtes lentes sont observées :

VACUUM ANALYZE <table>;

Contenu connexe