Pourquoi l'instance de base de données Amazon RDS utilise-t-elle l'espace d'échange alors que la quantité de mémoire est suffisante ?

Date de la dernière mise à jour : 13/05/2020

J'exécute une instance de base de données Amazon Relational Database Service (Amazon RDS) et elle utilise de grandes quantités d'espace d'échange alors même que la mémoire libre allouée est suffisante. Pourquoi l'espace d'échange est-il utilisé alors que je dispose de suffisamment de mémoire ?

Brève description

Les instances Amazon Elastic Compute Cloud (Amazon EC2) qui exécutent Linux utilisent l'espace d'échange quand un système nécessite plus de mémoire que ce qui est alloué. Pour plus d'informations, consultez la rubrique Volumes d'échange de stockage d'instance. Étant donné que la plupart des instances de base de données RDS utilisent Linux (à l'exception de SQL Server), votre base de données peut parfois utiliser l'espace d'échange.

Les instances de base de données RDS doivent avoir des pages dans la mémoire RAM uniquement lorsque l'accès aux pages est en cours, par exemple, lors de l'exécution de requêtes. Les autres pages introduites dans la mémoire RAM par les requêtes précédemment exécutées sont vidées dans l'espace d'échange si elles n'ont pas été utilisées récemment. Il est recommandé de laisser le système d'exploitation permuter les anciennes pages au lieu de le forcer à conserver les pages en mémoire. Cela garantit de disposer d'une quantité de mémoire RAM disponible suffisante pour les requêtes à venir.

L'utilisation de l'espace d'échange Linux n'est pas souvent effacée, car son effacement nécessite une charge supplémentaire pour réallouer l'espace d'échange lorsqu'il est nécessaire et lors du rechargement de pages. Par conséquent, si l'espace d'échange est utilisé sur votre instance de base de données RDS, même si cet espace n'a été utilisé qu'une seule fois, la métrique SwapUsage ne revient pas à zéro. L'espace d'échange peut être également utilisé si vous employez des HugePages prises en charge par Amazon RDS Oracle et des HugePages sur Amazon RDS for PostgreSQL. La taille des HugePages est supérieure à la taille par défaut Linux de deux mégaoctets.

Solution

Pour comprendre le comportement d'utilisation de l'espace d'échange pour l'instance de base de données RDS, commencez par vérifier les métriques de performance de base de données par rapport à la charge de travail de l'application. Vérifiez les métriques FreeableMemory et SwapUsage Amazon CloudWatch pour comprendre le modèle d'utilisation de la mémoire globale de l'instance de base de données RDS. Vérifiez ces métriques pour identifier une diminution de la métrique FreeableMemory qui se produit en même temps qu'une augmentation de la métrique SwapUsage. Cela peut indiquer qu'il existe une pression sur la mémoire de l'instance de base de données RDS. Pour plus d'informations, consultez la rubrique Comment résoudre les problèmes de faible quantité de mémoire libérable dans une base de données Amazon RDS for MySQL ou MariaDB ? S'il existe une quantité de mémoire suffisante libérable, l'utilisation de l'espace d'échange ne devrait pas affecter les performances de l'instance de base de données RDS. Si la quantité de mémoire libérable demeure faible, vous pouvez remplacer la taille de l'instance de base de données RDS par une taille d'instance supérieure disposant d'une plus grande quantité de mémoire.

Pour surveiller l'espace d'échange, activez Enhanced Monitoring afin de vérifier les métriques par intervalles avec une granularité de seulement une seconde. Enhanced Monitoring collecte des statistiques au niveau de l'hôte et CloudWatch collecte des données au niveau de l'hyperviseur toutes les 60 secondes. Vous pouvez utiliser Enhanced Monitoring pour identifier les augmentations ou les diminutions qui ne se produisent que pendant une seconde, ainsi que le processeur et la mémoire utilisés par des processus individuels. Pour plus d'informations, consultez la rubrique Différences entre les métriques CloudWatch et Enhanced Monitoring.

Vous pouvez également activer Analyse des performances pour identifier les événements SQL et d'attente qui consomment une quantité excessive d'espace d'échange ou de mémoire sur l'instance de base de données RDS. L'Analyse des performances collecte les données au niveau de la base de données et les affiche dans le tableau de bord d'Analyse des performances. L’Analyse des performances peut vous aider à résoudre les problèmes liés aux performances de base de données. Pour plus d'informations, consultez Utilisation de l’Analyse des performances Amazon RDS.

Amazon RDS MySQL

Si vous disposez d'une faible quantité de mémoire libérable, exécutez SHOW FULL PROCESSLIST ; (AFFICHER LA LISTE COMPLÈTE DE PROCESSUS) pour vérifier tous les threads en cours d'exécution sur votre base de données. Pour plus d'informations, consultez la documentation MySQL qui contient La table des threads. L'ID de processus de la sortie de SHOW FULL PROCESSLIST (AFFICHER LA LISTE COMPLÈTE DE PROCESSUS) ne correspondra pas à l'ID de processus affiché par Enhanced Monitoring. Pour afficher l'ID de processus correct, modifiez le groupe de paramètres de la base de données associé à la base de données pour activer le paramètre Performance_Schema. Il s'agit d'un paramètre statique. Par conséquent, vous devez redémarrer l'instance de base de données RDS. Pour éviter les interruptions, modifiez le paramètre et redémarrez la base de données en dehors des heures de pointe. Une fois que la mémoire a atteint l'utilisation souhaitée, procédez comme suit :

1.    Triez les ID de processus dans la page Enhanced Monitoring pour identifier l'ID des processus qui consomment le CPU maximum.

2.    Exécutez la requête suivante en tant qu'utilisateur principal :

select * from performance_schema.threads where THREAD_OS_ID in (ID shown in the Enhanced Monitoring window)\G

Par exemple, si la mémoire maximale a été consommée par Thread_OS_Id 10374 et 1432, exécutez la requête suivante :

select * from performance_schema.threads where THREAD_OS_ID in (10374, 1432)\G

3.    Obtenez la colonne PROCESSLIST_ID de la sortie de cette requête. Vous disposez ainsi de l'ID de processus qui correspond à la valeur de l'ID de processus de SHOW FULL PROCESSLIST (AFFICHER LA LISTE COMPLÈTE DE PROCESSUS).

Une fois que vous disposez de l'ID de processus correct, vous pouvez l'associer à la requête. Vous pouvez utiliser l'ID pour identifier la principale cause de l'utilisation élevée de la mémoire et du CPU. Vous pouvez afficher le processus du système d'exploitation à l’aide de l’option Enhanced Monitoring. Pour plus d’informations, consultez Affichage de Enhanced Monitoring.

Amazon RDS PostgreSQL

Pour identifier le processus qui consomme beaucoup de mémoire, associez l'ID de processus qui se trouve dans la liste des processus Enhanced Monitoring à la requête exacte en utilisant la vue pg_stat_activity suivante :

select * from pg_stat_activity where pid=(the PID of your process);

Ensuite, réglez les requêtes pour qu'elles consomment mois de ressources de calcul.

Amazon RDS SQL Server

Enhanced Monitoring peut identifier un ID de thread spécifique qui consomme de grandes quantités de mémoire. L'ID de thread correspond à ce que SQL Server appelle le KPID (ID du processus du noyau).

Dans Amazon RDS for SQL Server, exécutez la requête suivante pour obtenir le SPID (ID du processus du serveur) qui correspond au KPID :

select * from sys.sysprocesses where kpid = '<Value of Thread ID from Enhanced Monitoring>' ;

Lorsque vous disposez du SPID, par exemple 69, exécutez la commande suivante pour identifier ce que fait SPID 69 :

dbcc inputbuffer(69)

Amazon RDS Oracle

En utilisant l'ID de processus du système d'exploitation à partir de Enhanced Monitoring, vous pouvez identifier le processus qui consomme le plus de mémoire. Ensuite, exécutez la requête suivante pour obtenir l'adresse du processus de la session :

select ADDR from v$process where SPID=OS_PID;

Vous pouvez utiliser l'adresse du processus pour identifier la session dans la base de données en exécutant la requête suivante :

select sid,serial#,username, status from v$session where PADDR='<ADDR from above query>';

Cette page vous a-t-elle été utile ?

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


Vous avez besoin d'aide ?