MySQL スレーブ トリガー oom-killer solution_MySQL

最近、MySQL インスタンスのメモリ不足のような警告メッセージが頻繁に表示されます。サーバーにログインすると、MySQL がメモリの 99% を使い果たしていることがわかります。

時間内に処理されなかった場合、カーネルが MySQL を再起動し、dmesg 情報に次のレコードがあることがわかります:

3 月 9 日 11:29:16 xxxxxx カーネル: mysqld が oom-killer を呼び出しました: gfp_mask=0x201da、order=0、oom_adj=0、oom_score_adj=0
3 月 9 日 11:29:16 xxxxxx カーネル: mysqld cpuset=/ mems_allowed=0
3 月 9 日 11:29:16 xxxxxx カーネル: Pid: 99275、comm: mysqld 汚染されていない 2.6.32-431.el6.x86_64 #1
3 月 9 日 11:29:16 xxxxxx カーネル: コール トレース:

次に特定のシーンを説明します:

大前提: オペレーティングシステムとMySQLのバージョン:

OS: CentOS リリース 6.5 (最終) カーネル: 2.6.32-431.el6.x86_64 (物理マシン)
MySQL: Percona 5.6.23-72.1-log (単一インスタンス)

トリガーシナリオ: 他のリンクが入っているかどうかに関係なく、スレーブは定期的にメモリサージを経験し、カーネルの oom-killer をトリガーします

この問題は 1 年以上前から発生していると言われています。私がここに来たばかりなので、上司から何か手がかりがないかもう一度確認するように言われ、この問題を確認し始めました。

1. MySQLに割り当てられているメモリがおかしいのではないかと思い、innodb_buffer_poolのサイズと物理メモリのサイズを確認したところ、そうでない場合はBPに割り当てられているサイズが約60%を占めていることが分かりました。理由は、それを除外してください。これが問題だった場合、彼らはずっと前にそれを発見していたはずです〜

2. OSのパラメータ設定を確認します。 [vm.swappiness = 1 ; /proc/sys/vm/overcommit_memory ; oom_adj ] 問題をトラブルシューティングする前に、カーネルが mysql を強制終了しないように、adj パラメータを一時的に -15 に設定することができます。問題を根本的に解決することはできません。また、メモリが必要なのに割り当てられない場合、MySQL がハングする可能性があります。 この方法についてちょっと考えてみましょう。
3. さて、mysql 初期化パラメータとオペレーティング システム パラメータには不適切な設定はないようです。次に、MySQL 自体を探してみましょう。

MySQL のメモリが急増しているので、メモリ割り当てが原因でしょうか? MySQL のメモリ割り当てが原因であるというオンラインで報告されたバグによると、私の環境でも動作させてみます。 1. 占有メモリ サイズを記録します。現在の MySQL プロセスによって、show エンジンの innodb ステータスを記録します。 3. フラッシュ テーブルを実行します。 5. これら 2 つの結果を比較します。 Flush Table の実行前と Flush Table の実行後に、MySQL によって割り当てられたメモリに明らかな変更があった場合。 さて、このバグはもう私にはないようです。

このバージョンを見ると、innodb_buffer_pool_instances パラメータと innodb_buffer_pool_size の不適切な設定が MySQL OOM を引き起こすというバグも公式 Web サイトにあります。一般的な意味は、innodb_buffer_pool_size を実際の物理メモリよりも大きく設定できるということです。たとえば、物理メモリは 64GB で、innodb_buffer_pool_size = 300GB に設定し、innodb_buffer_pool_instances > 5 に設定しても、MySQL をプルアップできます。ただし、MySQL は OOM が発生する傾向があります。詳細情報: http://bugs.mysql.com/bug.php?id=79850 ここをご覧ください。

別の状況があり、バグが報告されています。つまり、スレーブがフィルタリングを設定すると、OOM もトリガーされますが、これらのインスタンスを設定していないため、これは無視します。

MySQL メモリのオーバーサブスクリプションが原因ではないため、開いているテーブルのハンドルが原因ではありません。それでは、他にはどのような理由があるのでしょうか?

この現象は、マスターとスレーブの構成が同じで、スレーブ上の一部のインスタンスが実行されていないだけで発生します。タスクがまったく存在しないにもかかわらず、OOM が発生する場合、この状況はおそらくスレーブによって引き起こされます。

それで、例を見つけて試してみました。試してみたらショックでした。起動して実行しました: stop smile; start smile; このコマンドは約 3 分間スタックしていましたが、メモリ使用量を確認したところ、20 GB 以上がすぐに解放されました。 この時点で、基本的に問題は特定されましたが、スレーブに 2 つのスレッドがあることは誰もが知っています。原因は SQL スレッドでしょうか、それとも IO スレッドでしょうか。 次回それが起こったときは、さらなる調査を待つ必要があります。

メモリ監視情報を投稿してください:

12:00:01 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit

02:40:01 PM 566744 131479292 99.57 88744 618612 132384348 89.19
02:50:01 PM 553252 131492784 99.58 83216 615068 132406792 89.20
03:00:01 PM 39302700 92743336 70.24 95908 925860 132413308 89.21
03:10:01 PM 38906360 93139676 70.54 109264 1292908 132407836 89.21
03:20:01 PM 38639536 93406500 70.74 120676 1528272 132413136 89.21

もう少し具体的なことをここに記録しました: https://bugs.launchpad.net/percona-server/+bug/1560304 アクセスできない場合は、アクセスできます (http://www.bitsCN.com/記事/88729 .htm)

最後に少しまとめます:

現象: スレーブ OOM
一時的な解決策: スレーブを再起動します
長期的な解決策: MySQL Server のマイナー バージョン アップグレード

より体系的な情報については、Guo 氏の文章をお読みください:
http://www.bitsCN.com/article/88726.htm
http://www.bitsCN.com/article/88727.htm