3 台のマシンで mongodb レプリカセットを実行しています。3 台のマシンはすべて約 16 GB ですが、スワップは 255 MB しかありません。swappiness はデフォルト値の 60 のままです。マシンは CentOS 6.4 を実行しています。データベースは 16 GB よりはるかに大きいですが、私たちにとっては問題ありません。実際に動作するセットははるかに小さいです。
私たちが直面している問題は、プライマリが利用可能なメモリをすべて消費し、OOM キルされることです。これが mongodb がメモリを管理する方法であることはわかっています。
サーバーが OOM で強制終了された後、誰かが手動で再起動する必要があります。
mongodb が OOM で強制終了されるのを防ぐ方法はありますか? swappiness を調整しますか? swap 領域を増やしますか? これらの設定では、mongod が強制終了されるまでの猶予期間が長くなるだけだと思います。
答え1
OOMキラーは方法ではない誰でもメモリを管理します。これは、システムのロックアップを回避するための最後の手段として致命的な障害を処理する Linux カーネルの方法です。
あなたがすべきことは次のとおりです:
十分なスワップがあることを確認してください。十分であることが確実であれば、さらに追加してください。
リソース制限を実装してください。少なくとも、メモリを使用すると思われるアプリケーションでは (メモリを使用しないと予想されるアプリケーションの場合はなおさらです。そのようなアプリケーションは、通常、問題を引き起こします)。シェルで ulimit -v (または limit addressspace) コマンドを調べ、アプリケーションの起動前に init スクリプトで実行してください。その他の制限も必要です (プロセス数 -u など)。そうすれば、メモリが不足しているときに、カーネルが存在しないメモリをアプリケーションに割り当て、その後暴走して周囲のすべてを強制終了するのではなく、アプリケーションは ENOMEM エラーを受け取ります。
カーネルにメモリをオーバーコミットしないように指示します。次のようにします。
エコー "0" > /proc/sys/vm/overcommit_memory
またはそれ以上（スワップスペースの量によって異なります）
echo "2" > /proc/sys/vm/overcommit_memory; echo "80" > /proc/sys/vm/overcommit_ratio
見るオーバーコミットをオフにする詳細については、こちらをご覧ください。
これにより、カーネルは、実際には持っていないメモリをアプリケーションに割り当てる際に、より慎重になるよう指示されます (世界経済危機との類似性が顕著です)
最後の手段として、MangoDB以外のシステム上のすべてが消耗品である場合（ただし、まず上記の2つの点を修正してください！）、殺される可能性/proc/$pid/oom_score_adj や /proc/$pid/oom_score を調整することで (または、代替案として何も動作しないマシンがハングアップする場合でも、強制終了されないようにします)。
echo "-1000" > /proc/`pidof mangod`/oom_score_adj
見るOOMキラーの抑制その件に関する詳しい情報。