MySQL 運用データベースでの異常なメモリ増加のトラブルシューティング方法

performance_schema の変更

会社の本番環境は Alibaba Cloud RDS を使用しているため、パラメータを変更するのが比較的便利です。デフォルトの Performance_schema は 0 ですが、今回は 1 に変更します。パラメータを変更して送信すると、データベースが再起動されます。これはビジネスのピーク時に行うことをお勧めします。

メモリ監視をオンにする

MySQL データベースにログインし、次の SQL を実行して、メモリ監視をオンにします。

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

開いたら確認してください。

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

**注: **このコマンドはメモリ統計をオンラインで開くためのものであるため、開いた後に新しく追加されたメモリ オブジェクトのみがカウントされます。開く前のメモリ オブジェクトはカウントされません。次の手順を実行して、メモリ使用量が多いスレッドを特定します。

メモリ消費量の検索

統計的なイベント メモリ消費量

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                           |
+---------------------------------------+-------------------------------------+

メモリ消費量が最も高いイベントは Filesort_buffer であることがわかります。経験によれば、これは並べ替えに関連しているはずです。 。

スレッドのメモリ消費量の統計

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                         |
+---------------------+---------------------------------------+-------------------------------------+

大量のメモリを消費するスレッドは、Filesort_bufferに関連していることがわかります。

特定の SQL を見つけます

先ほど見つけた thread_id に従って、ログで対応する SQL を検索します。Alibaba Cloud RDS 監査ログは比較的強力です。 thread_id に基づいて直接取得します。

ログにはこのような SQL が多数確認され、スキャンされた行数は数千から数万に及びました。各クエリの時間は長くなく、通常は数十ミリ秒から数百ミリ秒の間ですが、同時リクエストの数は多くなります。

以上がMySQL 運用データベースでの異常なメモリ増加のトラブルシューティング方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。