Maison > base de données > tutoriel mysql > le corps du texte

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

WBOY
Libérer: 2023-05-29 23:25:19
avant
1751 Les gens l'ont consulté

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%';
Copier après la connexion

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

select * from performance_schema.setup_instruments where name like 'memory%innodb%' limit 5;
Copier après la connexion

**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                           |
+---------------------------------------+-------------------------------------+
Copier après la connexion

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                         |
+---------------------+---------------------------------------+-------------------------------------+
Copier après la connexion

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

Comment résoudre les problèmes daugmentation anormale de la mémoire dans la base de données de production MySQLAccé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!

Étiquettes associées:
source:yisu.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal
À propos de nous Clause de non-responsabilité Sitemap
Site Web PHP chinois:Formation PHP en ligne sur le bien-être public,Aidez les apprenants PHP à grandir rapidement!