web-dev-qa-db-ja.com

MongoDBがOOMを殺害

3台のマシンでmongodbレプリカセットを実行しています。 3台すべてのマシンのスワップ容量は約16GBですが、255MBしかありません。 Swappinessはデフォルト値の60のままです。マシンはCentOS 6.4を実行しています。データベースは16GBよりはるかに大きいですが、それで十分です。実際のワーキングセットははるかに小さいです。

私たちが直面している問題は、プライマリが消費するすべての利用可能なメモリを消費し、OOM-Killedを取得することです。これがmongodbがメモリを管理する方法であることを知っています。

サーバーがOOMを強制終了した後、誰かが手動で再起動する必要があります。

MongodbがOOMを殺されるのを防ぐ方法はありますか？スワップを調整しますか？スワップ領域を増やしますか？これらの設定はmongodが殺される前の猶予期間を増やすだけだと思います。

mongodboom-killer
7
bjoernhaeuser

OOMキラーはメモリを管理する方法ではありませんanyone。 Linuxカーネルは、システムのロックアップを回避するために最後の希望で致命的な障害を処理する方法です。

あなたがすべきことは：

  • 十分なスワップがあることを確認してください。確かな場合は、さらに追加してください。

  • リソース制限を実装してください！アプリケーションのLEASTでは、メモリを使用することが予想されます（メモリを想定していない場合はさらにそうなります-それらは通常、問題が発生します）。シェルでulimit -v（またはlimit addressspace）コマンドを確認し、アプリケーションの起動前にinitスクリプトに配置します。他の要素（プロセス数-uなど）も制限する必要があります...このようにして、カーネルが存在しないメモリを提供し、その後凶暴に行って周りのすべてを殺すのではなく、十分なメモリがない場合、アプリケーションはENOMEMエラーを受け取ります！

  • カーネルにメモリをオーバーコミットしないように伝えます。あなたはできる：

    エコー "0">/proc/sys/vm/overcommit_memory

    またはそれ以上（スワップ領域の量に応じて）

    echo "2">/proc/sys/vm/overcommit_memory;エコー "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

    この件についての詳細は Taming the OOM killer を参照してください。

7
Matija Nalis