Comment puis-je résoudre les problèmes liés à une faible quantité de mémoire disponible dans une base de données Amazon RDS for MySQL ?
Je souhaite résoudre les problèmes de mémoire insuffisante lorsque j'exécute une instance Amazon Relational Database Service (Amazon RDS) pour MySQL. Ma mémoire disponible est faible, ma base de données manque de mémoire ou mon application connaît des problèmes de latence.
Résolution
Important : Performance Insights atteindra sa fin de vie le 30 juin 2026. Vous pouvez effectuer une mise à niveau vers le mode Avancé de Database Insights avant le 30 juin 2026. Si vous n'effectuez pas de mise à niveau, les clusters de base de données qui utilisent Performance Insights passeront par défaut au mode Standard de Database Insights. Seul le mode Avancé de Database Insights prendra en charge les plans d'exécution et l’analyse à la demande. Si vos clusters passent par défaut en mode Standard, il est possible que vous ne puissiez pas utiliser ces fonctionnalités sur la console. Pour activer le mode Avancé, consultez les sections Activation du mode Avancé de Database Insights pour Amazon RDS et Activation du mode Avancé de Database Insights pour Amazon Aurora.
Améliorer les performances de la base de données
Pour optimiser les performances de la base de données, optimisez et ajustez vos requêtes. Utilisez Analyse des performances d’Amazon RDS pour surveiller les instances de base de données et identifier les requêtes problématiques. Aussi, définissez une alarme CloudWatch sur la métrique FreeableMemory afin de recevoir une notification lorsque la mémoire disponible atteint 95 %. Il est recommandé de garder au moins 5 % de la mémoire de l'instance disponible.
Vérifier votre allocation de mémoire dans Amazon RDS for MySQL
Calculer votre allocation de mémoire
Pour calculer l'utilisation approximative de la mémoire pour votre instance de base de données RDS for MySQL, utilisez la formule suivante :
Utilisation totale de la mémoire = (innodb_additional_mem_pool_size + innodb_buffer_pool_size + innodb_log_buffer_size + key_buffer_size + query_cache_size + tmp_table_size) + max_connections (binlog_cache_size + join_buffer_size + read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack ) + (performance_schema max_connections * 429498)`
Assurez-vous que vous disposez de suffisamment de ressources allouées à votre base de données pour exécuter vos requêtes. En outre, certaines requêtes, telles que les procédures stockées, peuvent utiliser une quantité illimitée de mémoire lors de leur exécution. Pour éviter les transactions qui s’exécutent pendant longtemps, divisez vos requêtes volumineuses en requêtes de plus petite taille. Pour plus d'informations sur la façon dont Amazon RDS for MySQL utilise la mémoire, consultez la page Comment MySQL utilise la mémoire sur le site Web de MySQL.
Il est recommandé de mettre régulièrement à jour la version mineure de MySQL de votre instance. Les versions mineures antérieures peuvent contenir des bogues liés à des fuites de mémoire. Pour plus d'informations sur les versions de MySQL, consultez les notes de publication de MySQL 8.0 sur le site Web de MySQL.
Vérifier la taille de votre pool de mémoires tampons
Pour afficher les transactions de longue durée, les statistiques d'utilisation de la mémoire ou les verrouillages, utilisez la commande SHOW ENGINE INNODB STATUS. Pour plus d'informations sur la requête SHOW ENGINE, consultez la page Requête SHOW ENGINE sur le site Web de MySQL. Examinez la sortie et vérifiez l’entrée BUFFER POOL AND MEMORY pour rechercher des informations sur l'allocation de la mémoire pour InnoDB, telles que Mémoire totale allouée, Tables de hachage internes et Taille du pool de mémoires tampons. Si votre charge de travail rencontre souvent des blocages, modifiez le paramètre innodb_lock_wait_timeout dans votre groupe de paramètres personnalisé. InnoDB s'appuie sur le paramètre innodb_lock_wait_timeout pour annuler les transactions en cas de blocage.
Un pool de mémoire tampon plus important nécessite moins d'opérations d'I/O renvoyées vers le disque. Par défaut, innodb_buffer_pool_size utilise au maximum 75 % de la mémoire disponible allouée à l'instance de base de données Amazon RDS : innodb_buffer_pool_size = DBInstanceClassMemory*3/4. Pour plus d'informations sur les pools de mémoires tampons, consultez la page Pool de mémoires tampons sur le site Web de MySQL.
Pour identifier la source d'utilisation de la mémoire, vérifiez d'abord le paramètre innodb_buffer_pool_size. Ensuite, si nécessaire, modifiez la valeur du paramètre dans votre groupe de paramètres personnalisé pour réduire innodb_buffer_pool_size.
Pour en savoir plus, consultez la section Bonnes pratiques de configuration des paramètres d'Amazon RDS for MySQL, partie 1 : Paramètres liés à la performance.
Vérifier les threads MySQL
Une certaine quantité de mémoire est également allouée à chaque thread MySQL connecté à une instance de base de données MySQL. Pour plus d'informations sur les threads MySQL qui nécessitent une mémoire allouée, consultez Diagnostic et résolution de l'état des paramètres incompatibles pour une limite de mémoire sur la page Problèmes liés à MySQL et MariaDB,
MySQL crée des tables internes temporaires pour effectuer certaines opérations. Si les tables atteignent la valeur la plus basse de tmp_table_size ou max_heap_table_size, MySQL convertit les tables de tables basées sur la mémoire en tables basées sur disque. Si plusieurs sessions créent des tables internes temporaires, il est possible que vous constatiez une augmentation de l'utilisation de la mémoire. Pour réduire l'utilisation de la mémoire, utilisez uniquement un maximum de tables dans vos requêtes. Pour plus d'informations, consultez la page Variables système du serveur sur le site Web de MySQL et la page Comment MySQL utilise la mémoire sur le site Web de MySQL.
Si vous augmentez les valeurs de tmp_table_size et max_heap_table_size, des tables temporaires de plus grande taille sont stockées en mémoire. Pour vérifier que MySQL a créé une table temporaire implicite, utilisez la variable created_tmp_tables. Pour en savoir plus sur cette variable, consultez la page Created_tmp_tables du site Web de MySQL.
Consulter les opérations JOIN et SORT actives
Si vous identifiez une requête qui nécessite une table temporaire, vous devez avoir une mémoire supplémentaire à allouer à cette table. Pour afficher les connexions et les requêtes actives dans votre base de données, utilisez la commande SHOW FULL PROCESSLIST. Pour plus d'informations sur SHOW FULL PROCESSLIST et des exemples de requêtes, consultez la page Requête SHOW PROCESSLIST sur le site Web de MySQL.
Si MySQL alloue plusieurs tampons du même type, tels que join_buffer_size ou sort_buffer_size lors d'une opération JOIN ou SORT, l'utilisation de la mémoire augmente. Par exemple, MySQL alloue un tampon JOIN pour effectuer une opération JOIN entre deux tables. Pour les requêtes qui utilisent plusieurs tables JOIN où toutes les requêtes requièrent une mémoire tampon JOIN, MySQL alloue une mémoire tampon JOIN de moins que le nombre total de tables.
Si vous configurez les variables de session avec une valeur trop élevée, des erreurs peuvent s’afficher. Pour résoudre cette erreur, allouez la mémoire minimum requise aux variables de niveau session telles que join_buffer_size et sort_buffer_size.
Remarque : si vous effectuez des insertions groupées dans des tables MYISAM, MySQL utilise des octets de mémoire bulk_insert_buffer_size. Pour en savoir plus, consultez la page Bonnes pratiques d'utilisation de MySQL.
Activer Performance Schema
Si vous activez Performance Insights, MySQL alloue des tampons internes pour Performance Schema lorsque vous démarrez l'instance et pendant les opérations du serveur. Pour en savoir plus sur la façon dont Performance Schema utilise la mémoire, consultez la section sur le modèle d'allocation de mémoire de Performance Schema du site Web de MySQL.
Surveiller l'utilisation de la mémoire dans votre instance
Vérifier les métriques CloudWatch
Pour vérifier l’existence d’une mémoire faible, utilisez l'onglet Surveillance de la console Aurora et RDS pour surveiller les métriques CloudWatch, DatabaseConnections, CPUUtilization, ReadIOPS et WriteIOPS.
Pour DatabaseConnections, chaque connexion établie à la base de données nécessite une mémoire allouée, ce qui peut réduire la mémoire libérable. Utilisez la formule suivante pour calculer le quota max_connections maximum estimé : DBInstanceClassMemory/12582880
Pour vérifier si vous avez dépassé le quota max_connections, consultez la métrique CloudWatch DatabaseConnections.
Pour vérifier la pression de la mémoire, surveillez les métriques CloudWatch SwapUsage et FreeableMemory. Il est recommandé de maintenir les niveaux de pression de la mémoire sous 95 % afin d'améliorer les performances de la base de données. Pour plus d’informations, consultez la section Pourquoi mon instance de base de données Amazon RDS utilise-t-elle de la mémoire d’échange quand je dispose de suffisamment de mémoire ?
Utiliser le schéma système MySQL pour suivre l'utilisation de la mémoire
Utilisez le schéma système MySQL pour suivre la connexion, le composant et la requête de votre mémoire. Pour plus d'informations, consultez la page Chapitre 30 Schéma système MySQL sur le site Web de MySQL. Utilisez le schéma système MySQL et les tables Performance Schema pour identifier et suivre l'utilisation actuelle de la mémoire.
Remarque : vous devez activer Performance Schema pour utiliser le schéma système.
Pour suivre l'utilisation de la mémoire dans le schéma système, connectez-vous à la base de données et effectuez les actions suivantes :
- Utilisez memory_by_host_by_current_bytes pour déterminer quel hôte utilise le plus de mémoire.
- Utilisez memory_by_thread_by_current_bytes pour déterminer quel ID de thread utilise le plus de mémoire.
Remarque : l'ID de thread dans MySQL peut être une connexion client ou un thread d'arrière-plan. Vous pouvez utiliser la vue sys.processlist ou la table performance_schema.threads et mapper les ID de thread aux ID de connexion MySQL. - Utilisez memory_by_user_by_current_bytes pour déterminer quel utilisateur utilise le plus de mémoire.
- Utilisez memory_global_by_current_bytes pour déterminer quel composant du moteur utilise le plus de mémoire.
- Utilisez memory_global_total pour afficher l'utilisation totale de la mémoire suivie dans le moteur de base de données.
- Utilisez sys.memory_global_by_current_bytes pour déterminer quel composant utilise le plus de mémoire.
Remarque : pour les événements de mémoire liés à Performance Schema, utilisez memory/performance_schema/%. Pour InnoDB, utilisez memory/innodb/%.
Pour identifier les composants des fonctionnalités qui consomment le plus de mémoire au niveau global, exécutez la requête suivante :
SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(event_name, '/', 2), '/', -1 ) AS event_type, ROUND(SUM(CURRENT_NUMBER_OF_BYTES_USED)/1024/1024, 2) AS MB_CURRENTLY_USED FROM performance_schema.memory_summary_global_by_event_name GROUP BY event_type HAVING MB_CURRENTLY_USED>0;
Si performance_schema utilise le plus de mémoire, exécutez les requêtes suivantes pour déterminer l'événement event_name qui utilise la mémoire.
select * from sys.memory_global_by_current_bytes where event_name like '%performance_schema%' and current_count > 0;
select * from performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/performance_schema/%'order by CURRENT_NUMBER_OF_BYTES_USED desc;
Exécutez ensuite les requêtes suivantes :
select * from sys.memory_global_by_current_bytes where event_name like 'memory/sql%' and current_count > 0;
select p.id,p.user,p.host,p.db,p.command,p.state,p.info,t.thread_id,t.type from information_schema.processlist p, performance_schema.threads t where p.id=t.processlist_id and t.thread_id=thread_id;
Remarque : remplacez memory/sql% par votre type d'événement.
Pour afficher les détails de l'allocation de mémoire par événement pour un thread spécifique, exécutez la requête suivante :
select * from performance_schema.memory_summary_by_thread_by_event_name where thread_id=thread_id and CURRENT_COUNT_USED >0 order by CURRENT_NUMBER_OF_BYTES_USED desc;
Vous pouvez également utiliser performance_schema pour afficher la quantité de mémoire que MySQL alloue aux tampons internes utilisés par Performance Schema. Pour connaître la quantité de mémoire allouée, vous pouvez également exécuter la requête suivante :
select * from performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/performance_schema/%';
Les instruments de mémoire se trouvent dans la table setup_instruments au format memory/code_area/instrument_name.
Pour activer l'instrumentation à mémoire dans Performance Schema, définissez la colonne ENABLED de l'instrument sur YES dans la table performance_schema.setup_instruments.
Remarque : dans MySQL 8.x, l'instrumentation de mémoire est active par défaut lorsque Performance Schema est activé.
Surveiller l'utilisation des ressources
Pour surveiller l'utilisation des ressources sur une instance de base de données, activez la surveillance améliorée. Puis, définissez une granularité comprise entre 1 et 5 secondes. La granularité par défaut est de 60 secondes. Vous pouvez utiliser la surveillance améliorée pour voir la mémoire libérable et active en temps réel.
Pour surveiller les threads qui consomment le plus de processeur et de mémoire, exécutez la commande suivante pour répertorier les threads de votre instance de base de données :
select THREAD_ID, PROCESSLIST_ID, THREAD_OS_ID from performance_schema.threads;
Puis, exécutez ensuite la commande suivante pour mapper le thread_OS_ID au thread_ID :
select p.* from information_schema.processlist p, performance_schema.threads t where p.id=t.processlist_id and t.thread_os_id=thread-ID;
Remarque : remplacez thread-ID par l'ID du thread.
Informations connexes
Outils de surveillance pour Amazon RDS
Résolution des problèmes d'utilisation de la mémoire pour les bases de données Aurora MySQL
- Sujets
- Database
- Langue
- Français
Vidéos associées


Contenus pertinents
demandé il y a 2 ans
demandé il y a 4 ans
demandé il y a 3 ans
demandé il y a un an