Comment résoudre les problèmes liés à l’utilisation élevée du processeur pour Amazon RDS ou Amazon Aurora PostgreSQL ?

Dernière mise à jour : 01/02/2020
Comment identifier et résoudre la cause de problèmes d'utilisation intensive du processeur dans Amazon Relational Database Service (Amazon RDS) ou Amazon Aurora PostgreSQL ?

Brève description

Si vous voyez que votre charge entraîne une utilisation intensive du processeur, vous pouvez utiliser une combinaison des outils suivants pour identifier la cause :

Résolution

Métriques Amazon CloudWatch

Vous pouvez utiliser les métriques CloudWatch pour identifier les modèles de processeur pendant des périodes prolongées. Comparez les graphiques WriteIOPs, ReadIOPs, ReadThroughput et WriteThroughput avec l'utilisation du processeur (CPU) pour déterminer les heures auxquelles la charge de travail a entraîné une utilisation intensive du processeur (CPU).

Une fois que vous avez identifié le délai, vous pouvez consulter les données Enhanced Monitoring (Surveillance améliorée) associées à votre instance de base de données. Vous pouvez paramétrer Enhanced Monitoring (Surveillance améliorée) pour collecter des données à des intervalles de 1, 5, 10, 15, 30 ou 60 secondes. Cela vous permet de collecter des données à un niveau plus détaillé que CloudWatch. Pour plus d'informations, consultez la rubrique Différences entre les métriques CloudWatch et Enhanced Monitoring (Surveillance améliorée).

Enhanced Monitoring (Surveillance améliorée)

Enhanced Monitoring (Surveillance améliorée) fournit une vue au niveau du système d'exploitation, ce qui peut vous aider à identifier la cause d'une utilisation intensive du processeur à un niveau détaillé. Par exemple, vous pouvez consulter la charge moyenne, la distribution du CPU (system% ou nice%) et la liste de traitement du système d'exploitation.

En utilisant Enhanced Monitoring (Surveillance accrue), vous pouvez vérifier les données loadAverageMinute par intervalles de 1, 5 et 15 minutes. Si la charge moyenne est supérieure au nombre de vCPU, cela indique que l'instance est sous une lourde charge. En outre, si la charge moyenne est inférieure au nombre de vCPU pour la classe d'instance de base de données, la limitation du CPU peut ne pas être la cause de la latence des applications. Vérifiez la charge moyenne pour éviter les fausses erreurs lors du diagnostic de la cause de l'utilisation du processeur.

Par exemple, si vous avez une instance de base de données à l'aide d'une classe d'instance db.m5.2xlarge avec 3000 IOPS provisionnés qui atteint la limite de processeur (CPU), vous pouvez consulter l'exemple suivant de métriques pour identifier la cause racine de l'utilisation intensive du processeur (CPU). Dans l'exemple suivant, la classe d'instance dispose de huit vCPU qui lui sont associés. Pour la même classe d'instance, une charge moyenne supérieure à 170 indique que la machine est sous une charge importante au cours de la période mesurée :

Minute de la charge moyenne
 
Quinze 170,25
Cinq 391,31
Un 596,74
Utilisation du CPU  
Utilisateur (%) 0,71
Système (%) 4,9
Nice (%) 93,92
Total (%) 99,97

Remarque : Amazon RDS donne la priorité à votre charge de travail par rapport à d'autres tâches qui sont en cours d'exécution sur l'instance de base de données. Pour hiérarchiser ces tâches, les tâches de la charge de travail possèdent une valeur Nice supérieure. Par conséquent, dans Enhanced Monitoring (Surveillance accrue), Nice% représente la quantité de CPU utilisée par votre charge de travail par rapport à la base de données.

Après avoir activé Enhanced Monitoring (Surveillance améliorée), vous pouvez également vérifier la liste de traitement du système d'exploitation associé à l'instance de base de données. La surveillance améliorée montre un maximum de 100 processus. Cela peut vous aider à identifier les processus ayant le plus d'impact sur les performances en fonction de l'utilisation du processeur (CPU) et de la mémoire.

Vous pouvez mettre en association les résultats de Enhanced Monitoring (Surveillance améliorée) avec les résultats pg_stat_activity pour vous aider à identifier l'utilisation des ressources des requêtes.

Performance Insights (Analyse des performances)

Vous pouvez utiliser Amazon RDS Performance Insights pour identifier la requête responsable de la charge de la base de données après avoir vérifié l'onglet SQL qui correspond à une période donnée.

Affichage et catalogues PostgreSQL natif

Au niveau du moteur de base de données, si le problème se produit en temps réel, vous pouvez utiliser pg_stat_activity ou pg_stat_statements. Cela peut vous aider à regrouper les machines, les clients, et les adresses IP avec le trafic le plus important. Vous pouvez également utiliser ces données pour voir s'il y a des augmentations au fil du temps, les augmentations des serveurs d'application ou si un serveur d'application a des sessions bloquées ou des problèmes de verrouillage. Pour plus d'informations, consultez la documentation PostgreSQL pour pg_stat_activity et pg_stat_statements. Pour activer pg_stat_statements, modifiez le groupe de paramètres personnalisés existants et définissez les valeurs suivantes :

  • Ajoutez pg_stat_statements à shared_preload_libraries
  • track_activity_query_size = 4096
  • pg_stat_statements.track = ALL
  • pg_stat_statements.max = 10000

Choisissez Apply Immediately (Appliquer immédiatement), puis redémarrez l'instance de base de données. Ensuite, exécutez une commande semblable à la commande suivante sur la base de données que vous souhaitez surveiller :

Remarque : l'exemple suivant installe l'extension dans la base de données « démo ».

demo=> select current_database();
current_database
------------------
demo
(1 row)
     
demo=> CREATE EXTENSION pg_stat_statements;

Une fois pg_stat_statements configuré, vous pouvez surveiller la sortie en utilisant l'une des méthodes suivantes :

  • Répertorier des requêtes par total_time et voir quelle requête consacre la plupart du temps dans la base de données :
SELECT round(total_time*1000)/1000 AS total_time,query
FROM pg_stat_statements
ORDER BY total_time DESC limit 2;
  • Répertorier des requêtes avec le nombre total d'appels, le total de lignes et des lignes retournées :
SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit /
nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;
  • Répertorier des requêtes sur base par exécution pour essayer des requêtes au fil du temps :
SELECT query, calls, total_time/calls as avg_time_ms, rows/calls as avg_rows,
temp_blks_read/calls as avg_tmp_read, temp_blks_written/calls as avg_temp_written
FROM pg_stat_statements
WHERE calls != 0
ORDER BY total_time DESC LIMIT 5;

Paramètres de journalisation PostgreSQL

Activez la journalisation des requêtes à l'aide d'Amazon RDS for PostgreSQL. Ensuite, vérifiez les journaux des erreurs PostgreSQL afin de confirmer que vos paramètres log_min_duration_statement et log_statement sont définis sur les valeurs appropriées. Pour plus d'informations, consultez la documentation PostgreSQL pour Signalement et journalisation des erreurs.

Réduction de l'utilisation du processeur (CPU)

Une fois que vous avez identifié les requêtes entraînant une utilisation élevée du processeur (CPU), vous pouvez utiliser les méthodes suivantes pour réduire l'utilisation du processeur (CPU) :

  1. S'il y a des occasions de réglage, utilisez EXPLAIN (EXPLIQUER) and EXPLAIN ANALYZE (EXPLIQUER L'ANALYSE) pour identifier les mises en garde. Pour plus d'informations, consultez la documentation PostgreSQL relative à EXPLAIN (EXPLIQUER).
  2. S'il y a une requête en cours d'exécution répétée, utilisez les instructions préparées pour réduire la pression sur votre processeur.

Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?