Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Résolution des problèmes de mémoire insuffisante pour les bases de données Aurora MySQL
Lorsqu'une instance de base de données Aurora MySQL manque cruellement de mémoire, le système d'exploitation peut interrompre le processus de base de données et provoquer un redémarrage imprévu. Pour éviter ces redémarrages, Aurora MySQL inclut des fonctionnalités de gestion de la mémoire qui surveillent la mémoire du système et prennent des mesures de restauration automatique lorsque la mémoire est insuffisante. Ces actions permettent d'éviter l'indisponibilité de la base de données en raison de l'épuisement de la mémoire.
Les paramètres suivants contrôlent ce comportement :
-
aurora_enable_memory_management— Disponible uniquement dans Aurora MySQL 8.4.-
Lorsque
ON(par défaut), Aurora gère automatiquement les actions de restauration de mémoire et leaurora_oom_responseparamètre est ignoré. -
Réglez sur
OFFpour contrôler manuellement les actions de restauration viaaurora_oom_response.
-
-
aurora_oom_response— Liste des actions de restauration séparées par des virgules. Une chaîne vide désactive toutes les actions. Disponible dans Aurora MySQL version 3. Également disponible dans Aurora MySQL 8.4, mais uniquement pris en compte lorsqueaurora_enable_memory_managementce paramètre est défini surOFF.
Actions de réponse à l'OOM
Les actions suivantes peuvent être inclusesaurora_oom_response, classées de la moins agressive à la plus agressive.
| Action | Ce qu'il fait | Remarques |
|---|---|---|
print |
Enregistre les requêtes et les connexions gourmandes en mémoire dans le journal des erreurs. Aucune requête ou connexion n'est interrompue. | Disponible dans les versions 3 et 8.4 d'Aurora MySQL. |
tune |
Réduit les caches de table internes (table_open_cache,table_definition_cache) pour libérer de la mémoire. La taille du cache est rétablie lorsque la mémoire revient à la normale. Les entrées précédemment mises en cache ne sont pas restaurées ; les nouvelles entrées ne sont ajoutées que lorsque les requêtes suivantes y accèdent. |
Disponible dans les versions 3 et 8.4 d'Aurora MySQL. Instances provisionnées uniquement : non prises en charge sur Serverless v2. |
tune_buffer_pool |
Réduit le pool de mémoire tampon InnoDB pour libérer de la mémoire. La taille du pool de mémoire tampon est rétablie lorsque la mémoire revient à la normale. Les pages précédemment mises en cache qui ont été expulsées ne sont pas rechargées automatiquement ; les nouvelles pages ne sont mises en cache que lorsque des requêtes ultérieures y accèdent. | Aurora MySQL version 3 (3.06 et supérieure) et Aurora MySQL 8.4 uniquement. Pris en charge sur les instances provisionnées avec 2 vCPU uniquement. Non pris en charge sur Serverless v2. |
decline |
Rejette les nouvelles requêtes contenant une erreur lorsque la mémoire est insuffisante. | Disponible dans les versions 3 et 8.4 d'Aurora MySQL. |
kill_query |
Met fin à l'exécution SELECT des requêtes, en commençant par celles qui consomment le plus de mémoire, jusqu'à ce que la mémoire revienne à la normale. Le DDL, les autres DML et les transactions ne sont pas affectés. |
Disponible dans les versions 3 et 8.4 d'Aurora MySQL. Mutuellement exclusif avec kill_connect — si les deux sont définis, kill_connect s'active uniquement. |
kill_connect |
Résout les connexions des utilisateurs, annule leurs transactions actives et met fin aux instructions DDL. | Voir le comportement spécifique à la version ci-dessous. |
Important
Vous devez associer tune_buffer_pool avec kill_query ou kill_connect dans la valeur du paramètre aurora_oom_response. Sans l'un d'entre eux, le redimensionnement du pool de mémoire tampon ne se produit pas, même lorsqu'il tune_buffer_pool est inclus.
comportement spécifique à la version de kill_connect
| Aurora MySQL Version | Comportement |
|---|---|
| Aurora MySQL 3.04 — Aurora MySQL 3.10 | Interrompt les connexions utilisateur afin de libérer suffisamment de mémoire pour permettre à la base de données de se remettre de la pression de mémoire. |
| Aurora MySQL 3.11+, Aurora MySQL 8.4 | Interrompt les connexions utilisateur afin de libérer suffisamment de mémoire pour permettre à la base de données de se remettre de la pression de mémoire. Résout également toute connexion utilisateur qui tente d'allouer de la mémoire lorsque la mémoire est trop sollicitée. |
Sur Serverless v2, Aurora répond à la pression de la mémoire en augmentant d'abord la taille des ACU pour fournir de la mémoire supplémentaire. Si la pression sur la mémoire persiste alors que le dimensionnement est en cours, Aurora peut mettre fin aux connexions existantes pour récupérer de la mémoire. L'arrêt des connexions qui tentent d'allouer de la mémoire ne se produit que lorsque l'instance a atteint la limite ACU maximale configurée et ne peut plus évoluer davantage.
Valeurs par défaut par version
Aurora MySQL se configure automatiquement aurora_oom_response en fonction de la version du moteur, du type d'instance et de la mémoire disponible.
Dans Aurora MySQL 8.4, lorsque aurora_enable_memory_management c'est le cas ON (valeur par défaut), Aurora gère automatiquement les actions de restauration de mémoire et la aurora_oom_response valeur n'est pas utilisée. Lorsqu'elle est définie surOFF, Aurora utilise directement la aurora_oom_response valeur, qui est vide par défaut, ce qui signifie qu'aucune action de restauration n'est entreprise à moins que vous ne les configuriez explicitement. Le tableau des valeurs par défaut ci-dessous s'applique uniquement à Aurora MySQL version 3.
Seuil d'instance de petite taille : ≤2 GiB pour les versions 3.04 et 3.05. ≤4 GiB pour la version 3.06 et supérieure.
Seuil d'instance élevé : >2 GiB pour les versions 3.04 et 3.05. >4 GiB pour les versions 3.06 et supérieures.
| Version | Taille d’instance | Alloué | V2 sans serveur |
|---|---|---|---|
| Aurora MySQL 3.04—Aurora MySQL 3.05 | Petit | print,tune | print |
| Grand | handicapé | handicapé | |
| Aurora MySQL 3.06 | Petit | print,tune,decline,kill_connect | print |
| Grand | handicapé | handicapé | |
| Aurora MySQL 3.07 | Petit | print,tune,decline,kill_connect | print |
| Grand | print | print | |
| Aurora MySQL 3.08 | Petit | print,tune,tune_buffer_pool,decline,kill_connect | print |
| Grand | print | print | |
| Aurora MySQL 3.09—Aurora MySQL 3.10 | Petit | print,tune,tune_buffer_pool,decline,kill_connect | print |
| Grand | print,decline,kill_connect | print,decline,kill_connect | |
| Aurora MySQL 3.11+ | Petit | print,tune,tune_buffer_pool,decline,kill_connect | print,decline,kill_connect |
| Grand | print,decline,kill_connect | print,decline,kill_connect |
Aurora sans serveur v2
Les tune_buffer_pool actions tune et ne sont pas prises en charge sur Aurora Serverless v2. Toutes les autres actions fonctionnent de la même manière que sur les instances provisionnées.
Les seuils de mémoire s'ajustent dynamiquement à mesure que l'instance redimensionne ses ACU. La colonne Serverless v2 du tableau des valeurs par défaut ci-dessus indique les valeurs par défaut effectives pour chaque version.
Contrôle
Vous pouvez surveiller les activités d'évitement de l'OOM à l'aide des méthodes suivantes.
Journal des erreurs
Lorsque des actions de restauration de mémoire sont entreprises, Aurora MySQL écrit des messages dans le journal des erreurs de la base de données. Le préfixe du message varie en fonction de la version et peut être modifié dans les futures versions :
Aurora MySQL version 3 : les messages sont préfixés par
OOM crash avoidance:.Aurora MySQL version 8.4 : les messages sont préfixés par
Aurora memory management:.
Ces messages incluent :
Pression de mémoire détectée et notifications récupérées avec mémoire totale et disponible
Détails des requêtes ou des connexions interrompues pour récupérer de la mémoire
Requêtes de candidats identifiées par l'
printaction
Pour consulter le journal des erreurs, voirJournaux des erreurs Aurora MySQL.
CloudWatch Métriques Amazon
Les CloudWatch mesures suivantes permettent de suivre les activités d'évitement d'OOM au niveau de l'instance.
| Métrique | Description | Disponible auprès de | Unit |
|---|---|---|---|
AuroraMemoryHealthState | Indique l'état de santé de la mémoire. 0signifie une pression de mémoire saine (aucune pression de mémoire), 5 une pression de mémoire modérée, 10 une pression de mémoire critique. | Aurora MySQL 3.06.1+, Aurora MySQL 8.4 | Jauge |
AuroraMemoryNumDeclinedSqlTotal | Le nombre incrémentiel de requêtes a diminué dans le cadre de l'évitement de l'OOM. | Aurora MySQL 3.06.1+, Aurora MySQL 8.4 | Nombre |
AuroraMemoryNumKillConnTotal | Nombre incrémentiel de connexions fermées afin d’éviter le manque de mémoire (OOM). | Aurora MySQL 3.06.1+, Aurora MySQL 8.4 | Nombre |
AuroraMemoryNumKillQueryTotal | Le nombre incrémentiel de requêtes interrompues dans le cadre de l'évitement d'OOM. | Aurora MySQL 3.06.1+, Aurora MySQL 8.4 | Nombre |
AuroraMillisecondsSpentInOomRecovery | Durée écoulée depuis que l'état de santé de la mémoire est tombé en dessous de l'état normal. | Aurora MySQL 3.08.0+, Aurora MySQL 8.4 | Millisecondes |
AuroraNumOomRecoverySuccessful | Nombre de fois où l'état normal de la mémoire a été rétabli. | Aurora MySQL 3.08.0+, Aurora MySQL 8.4 | Nombre |
AuroraNumOomRecoveryTriggered | Le nombre de fois où l'état de santé de la mémoire est tombé en dessous de l'état normal. | Aurora MySQL 3.08.0+, Aurora MySQL 8.4 | Nombre |
Les CloudWatch mesures générales suivantes sont également utiles pour surveiller la pression de la mémoire :
| Métrique | Description | Unit |
|---|---|---|
FreeableMemory | La quantité de mémoire disponible. Indique la MemAvailable valeur à partir de/proc/meminfo. | Octets |
SwapUsage | Quantité d’espace d’échange utilisé. | Octets |
Pour obtenir la liste complète des métriques au niveau de l'instance Aurora MySQL, consultez. Instance-level métriques pour Amazon Aurora
Variables d’état globales
Les variables d'état suivantes fournissent des informations sur l'état de l'OOM. Disponible dans Aurora MySQL version 3.06.0 et supérieure.
| Variable | Description |
|---|---|
Aurora_oom_response | Les actions de réponse OOM actuellement actives pour cette instance de base de données. |
aurora_oom_avoidance_recovery_state | Que la restauration OOM soit ACTIVE ouINACTIVE. |
aurora_oom_status | État actuel de la mémoire de la base de données : saine (aucune pression sur la mémoire), pression mémoire modérée ou pression mémoire critique. Disponible en version 3 uniquement. |
Pour effectuer une requête : SHOW GLOBAL STATUS LIKE 'aurora_oom%';
Pour obtenir la liste complète des variables d'état globales d'Aurora MySQL, consultezVariables d’état globales Aurora MySQL.
Performance Insights
Si Performance Insights est activé, vous pouvez utiliser les métriques de OS-level mémoire pour surveiller la pression de la mémoire et détecter les événements OOM. Les métriques suivantes sont disponibles sous les os.swap compteurs os.memory et :
| Métrique | Description |
|---|---|
os.memory.outOfMemoryKillCount | Le nombre de victimes d'OOM au cours du dernier intervalle de collecte. Une valeur différente de zéro indique que le système d'exploitation a mis fin à un processus en raison de l'épuisement de la mémoire, ce qui entraîne généralement le redémarrage de la base de données. |
os.memory.total | Quantité totale de mémoire, en kilo-octets. |
os.memory.free | Quantité de mémoire non attribuée, en kilo-octets. |
os.memory.active | Quantité de mémoire attribuée, en kilo-octets. |
os.memory.cached | Quantité de mémoire utilisée pour la mise en cache du système de fichiers I/O, en kilo-octets. |
os.memory.dirty | Nombre de pages de mémoire modifiées mais non encore enregistrées dans le stockage, en kilo-octets. |
os.memory.inactive | Quantité de pages mémoire moins fréquemment utilisées, en kilo-octets. |
os.memory.db.residentSetSize | Quantité de mémoire utilisée par le processus de base de données (à l'exception de la mémoire partagée), en octets. |
os.memory.db.cache | Quantité de mémoire utilisée pour le cache de pages par le processus de base de données, en octets. |
os.memory.db.swap | Quantité de mémoire d'échange utilisée par le processus de base de données, en octets. |
os.swap.in | Quantité de mémoire échangée depuis le disque, en kilo-octets. |
os.swap.out | Quantité de mémoire échangée sur le disque, en kilo-octets. |
Vous pouvez surveiller os.memory.outOfMemoryKillCount pour détecter le moment où le système d'exploitation a arrêté le processus de base de données en raison d'un manque de mémoire. Pour obtenir la liste complète des compteurs de systèmes d'exploitation, consultez la section Mesures du système d'exploitation Performance Insights.
Schéma de performance
Si cette option performance_schema est activée, vous pouvez utiliser les tableaux récapitulatifs de la mémoire pour identifier les composants et les connexions qui consomment le plus de mémoire. Pour de plus amples informations, veuillez consulter Résolution des problèmes d’utilisation de la mémoire pour les bases de données Aurora MySQL.
