MySQL OOM シリーズ 3: MySQL が強制終了されるという不運を取り除く_MySQL

前の 2 つの章では、Linux のメモリ割り当て戦略を分析し、Linux は OOM_Killer メカニズムを使用して「オーバーブッキング」によって引き起こされるリスクを解決しました。他のアプリケーションと同様、オペレーティング システムが許可する範囲内でオーバーブッキングすることができます。ほとんどの人は、Innodb_buffer_pool が実際の物理メモリより小さくなければならないことを理解しています。そうしないと、MySQL の起動に失敗します。実際、これは誤解です。これは MySQL 層によって制御されません。前述の /proc/sys/overcommit_memory は、OS が「オーバーブッキング」を許可するかどうかを制御します。 「オーバーブッキング」が許可されている場合、Innodb_buffer_pool は実際のメモリ領域のサイズをはるかに超える可能性がありますが、領域のこの部分は使用されません。小さな実験をしてみましょう。下の写真をご覧ください:

MySQL の Innodb_buffer_pool は 5G に設定されていますが、実際のメモリは 3G のみです。

ここまで述べたところで、本題に戻り、RDS インスタンスが OS によって強制終了されるという最初に述べた問題に戻ります。前述したように、インスタンスの使用可能なメモリが不足すると、通常は MySQL が優先されます。 OOM_Killer のターゲット。ここには 2 つの問題が関係しています:

1. メモリが不足しているのはなぜですか?

2. MySQL が強制終了されないようにする方法は?
まず最初の質問を見てみましょう。メモリ不足の問題には多くの理由がありますが、主に 2 つの側面があります。1 つは、MySQL 自体のメモリ計画に問題があることです。 2 つ目は、通常、MySQL をデプロイするサーバーは、大量の監視スクリプトやスケジュールされたタスク スクリプトをデプロイしますが、これらのスクリプトには必要なメモリ制限がないことが多く、その結果、ピーク時に大量のメモリが占​​有され、Linux OOM_Killer メカニズムがトリガーされ、MySQL が無実のものが犠牲になった。
では、どうすれば MySQL が強制終了されるという不運から抜け出すことができるでしょうか? MySQL が強制終了される根本原因は、Linux のオーバーブッキング メモリ割り当てメカニズムにあります。このオーバーブッキング メカニズムが存在する限り、特定のアプリケーションが強制終了されるリスクを完全に回避することはできません。 MySQL が強制終了されるのを防ぐには、オペレーティング システムが実際のメモリ空間を超えてメモリを割り当てることを禁止することしかできません。ただし、前に述べたように、MySQL がデプロイされているサーバーにはこれをお勧めしません。これは、MySQL のメモリの多くが適用されたばかりで、OS がオーバーブッキングを禁止すると、すぐには使用されないためです。これは、MySQL 自体のメモリに影響を与えるだけではありません。計画ではより厳しい要件が提示され、メモリ使用量が不十分であるという問題もあります。同時に、各 MySQL 接続のプライベート メモリが動的に割り当てられるため、割り当てられていない場合はサーバーのクラッシュが直接発生し、MySQL がクラッシュするリスクも高まります。
これはオペレーティング システムによって制限されており、強制終了を完全に回避することはできないため、MySQL が強制終了される可能性を減らすことを試みることしかできません。少なくとも次の3つはできると思います:

1) MySQL のメモリ使用量を合理的に計画します。
2) OOM_adj パラメータを調整して、OOM_Killer によってロックされている MySQL の優先度を下げます。
3) メモリの監視と警告を強化します。警告が発せられると、DBA はすぐに介入して、より多くのメモリを占有している一部の接続を強制終了する必要があります。