Comment résoudre les problèmes d'augmentation anormale de la mémoire dans la base de données de production MySQL

Modifier performance_schema

Étant donné que l'environnement de production de l'entreprise utilise Alibaba Cloud RDS, il est relativement pratique de modifier les paramètres. Le schéma de performance par défaut est 0, et cette fois il est modifié à 1. Soumettez les paramètres après modification et la base de données sera redémarrée. Il est recommandé de le faire pendant les faibles pics d'activité.

Activez la surveillance de la mémoire

Connectez-vous à la base de données MySQL, exécutez le SQL suivant et activez la surveillance de la mémoire.

update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';

Vérifiez-le après l'avoir ouvert.

select * from performance_schema.setup_instruments where name like 'memory%innodb%' limit 5;

**Remarque : **Cette commande permet d'ouvrir les statistiques de mémoire en ligne, donc seuls les objets de mémoire nouvellement ajoutés après l'ouverture ne seront pas comptés. Les objets de mémoire avant l'ouverture ne seront pas comptés. après l'ouverture avant d'effectuer les étapes suivantes. Facile à trouver des threads avec une utilisation élevée de la mémoire.

Trouver la consommation de mémoire

Consommation de mémoire d'événement statistique

select event_name,
       SUM_NUMBER_OF_BYTES_ALLOC
from performance_schema.memory_summary_global_by_event_name
order by SUM_NUMBER_OF_BYTES_ALLOC desc
LIMIT 10;
+---------------------------------------+-------------------------------------+
| event_name                            | SUM_NUMBER_OF_BYTES_ALLOC           |
+---------------------------------------+-------------------------------------+
| memory/sql/Filesort_buffer::sort_keys | 763523904056                        |
| memory/memory/HP_PTRS                 | 118017336096                        |
| memory/sql/thd::main_mem_root         | 114026214600                        |
| memory/mysys/IO_CACHE                 | 59723548888                         |
| memory/sql/QUICK_RANGE_SELECT::alloc  | 14381459680                         |
| memory/sql/test_quick_select          | 12859304736                         |
| memory/innodb/mem0mem                 | 7607681148                          |
| memory/sql/String::value              | 1405409537                          |
| memory/sql/TABLE                      | 1117918354                          |
| memory/innodb/btr0sea                 | 984013872                           |
+---------------------------------------+-------------------------------------+

Vous pouvez voir que l'événement avec la consommation de mémoire la plus élevée est Filesort_buffer Selon l'expérience, cela devrait être lié au tri.

Statistiques sur la consommation de mémoire des threads

select thread_id,
       event_name,
       SUM_NUMBER_OF_BYTES_ALLOC
from performance_schema.memory_summary_by_thread_by_event_name
order by SUM_NUMBER_OF_BYTES_ALLOC desc
limit 10;
+---------------------+---------------------------------------+-------------------------------------+
| thread_id           | event_name                            | SUM_NUMBER_OF_BYTES_ALLOC           |
+---------------------+---------------------------------------+-------------------------------------+
| 105                 | memory/memory/HP_PTRS                 | 69680198792                         |
| 183                 | memory/sql/Filesort_buffer::sort_keys | 49210098808                         |
| 154                 | memory/sql/Filesort_buffer::sort_keys | 43304339072                         |
| 217                 | memory/sql/Filesort_buffer::sort_keys | 37752275360                         |
| 2773                | memory/sql/Filesort_buffer::sort_keys | 31460644712                         |
| 218                 | memory/sql/Filesort_buffer::sort_keys | 31128994280                         |
| 2331                | memory/sql/Filesort_buffer::sort_keys | 28763981248                         |
| 106                 | memory/memory/HP_PTRS                 | 27938197584                         |
| 191                 | memory/sql/Filesort_buffer::sort_keys | 27701610224                         |
| 179                 | memory/sql/Filesort_buffer::sort_keys | 25624723968                         |
+---------------------+---------------------------------------+-------------------------------------+

Vous pouvez voir que les threads qui consomment beaucoup de mémoire sont liés à Filesort_buffer. Filesort_buffer相关。

定位具体SQL

根据前边我们查到的thread_id

Localisez le SQL spécifique

Accédez au journal pour trouver le SQL correspondant en fonction du thread_id que nous avons trouvé plus tôt. Les journaux d'audit Alibaba Cloud RDS sont relativement puissants. Nous récupérons directement en fonction du thread_id.

Nous avons vu un grand nombre de ces SQL dans les journaux, et le nombre de lignes analysées variait de milliers à des dizaines de milliers. Bien que la durée de chaque requête ne soit pas longue, généralement comprise entre des dizaines et des centaines de millisecondes, le nombre de requêtes simultanées est important. 🎜🎜🎜

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!