Comment puis-je résoudre les problèmes d'utilisation intensive du CPU pour Amazon RDS ou Amazon Aurora PostgreSQL ?

Dernière mise à jour : 18/06/2020

Comment puis-je identifier et résoudre la cause de problèmes d'utilisation intensive du CPU 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 CPU, vous pouvez utiliser une combinaison des outils suivants pour identifier la cause :

Cet article explique comment utiliser chacun de ces outils pour identifier la cause d'une utilisation intensive du CPU.

Résolution

Métriques Amazon CloudWatch

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

Une fois que vous avez identifié le délai, vous pouvez consulter les données Enhanced Monitoring (Surveillance accrue) associées à votre instance de base de données. Vous pouvez paramétrer Enhanced Monitoring (Surveillance accrue) 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 granulaire que CloudWatch. Pour plus d'informations, consultez la rubrique Différences entre les métriques CloudWatch et Enhanced Monitoring (Surveillance accrue).

Enhanced Monitoring (Surveillance accrue)

Enhanced Monitoring (Surveillance accrue) fournit une vue au niveau du système d'exploitation, ce qui peut vous aider à identifier la cause d'une utilisation intensive du CPU à un niveau granulaire. 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 CPU.

Par exemple, si vous avez une instance de base de données à l'aide d'une classe d'instance db.m4.2xlarge avec 3 000 IOPS provisionnés qui atteint la limite de CPU, vous pouvez consulter l'exemple suivant de métriques pour identifier la cause racine de l'utilisation intensive du 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 accrue), vous pouvez également vérifier la liste de traitement du système d'exploitation associé à l'instance de base de données. Enhanced Monitoring (Surveillance accrue) affiche uniquement les 50 principaux processus pour le CPU et la mémoire. Cela peut vous aider à identifier les processus ayant le plus d'impact sur les performances en fonction de l'utilisation du CPU et de la mémoire.

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

Analyse des performances

Vous pouvez utiliser Analyse des performances Amazon RDS 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. Ceci 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 :

  • shared_preload_libraries = pg_stat_statements
  • track_activity_query_size = 2048
  • 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

Activer 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 CPU

Une fois que vous avez identifié les requêtes entraînant une utilisation élevée du CPU, vous pouvez utiliser les méthodes suivantes pour réduire l'utilisation du 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 CPU.

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

Cette page peut-elle être améliorée ?


Vous avez besoin d'aide ?