Partager via

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

  • Article

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 :

  • À 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 de EXPLAIN ANALYZE, du regroupement de connexions et des tables de nettoyage.

Guides de résolution des problèmes

À l’aide des guides de résolution des problèmes, vous pouvez identifier la cause racine probable d’un scénario de processeur élevé et lire les recommandations pour atténuer le problème.

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.

Mesures 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 d’écriture, d’E/S par seconde de lecture, de débit de lecture en octets/s et de débit d’écriture en octets/s avec le pourcentage d’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 de 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 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énement 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 plus d’informations, consultez Magasin de requête.

pg_stat_statements

L’extension pg_stat_statements permet d’identifier les requêtes qui consomment du temps sur le serveur. Pour 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 peuvent également 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 de l’UC

Utilisez EXPLAIN ANALYZE, envisagez d’utiliser le regroupement de connexions PgBouncer intégré et arrêtez les transactions longues 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 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 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 arrêter 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 à 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>;

Partager vos suggestions et bogues avec l’équipe produit Azure Database pour PostgreSQL.