データベースのサイズが時間の経過とともに大きくなるにつれて発生するように思われるMongoDB /ページファイルの問題について、誰かが助けてくれるかどうか疑問に思っています。時々、MongoDBはレプリカセットの特定のノードでクラッシュし、ページファイルサイズを大幅に増やす(doubleは安全です)まで再起動しません。現在、ページファイルは42GBです。 MongoDBを3ノードのレプリカセットとして実行しており、各ノードはAzureのWindows Server 2012R2仮想マシンで実行されています。各サーバーには3.5GBのメモリがあります。 MongoDBはバージョン2.6.5です。
以下の関連する投稿を見ましたが、MongoDBはメモリマップファイルを使用しており、RAMが十分にない場合は、おそらく仮想メモリがそれを支援することを理解しています。私が理解していないのは:
MongoDBが起動時に非常に多くのメモリ(131GBデータベースの場合は> 32GBページファイル)を必要とし、ワーキングセットが比較的小さい(〜100MB)のはなぜですか?おそらく、特にこれほど大きなページファイルでは、必要に応じてファイルをスワップアウトできるので、MongoDBがクラッシュするのはなぜですか?
これまでに見つけた投稿は次のとおりです。
挿入のみを行ってもmongodbのメモリ使用量が高くなっています
そしてこれ
SERVER-10044 これは、Mongoがクラッシュする理由を説明し、VMが悪化していることを意味します
助けてくれてありがとう。
より多くのコンテキストを提供するために、MongoDBを使用してデータをログに記録しているため、一定の読み取りと書き込みが行われるいくつかの小さなコレクション(合計100MB)を除いて、ほとんどのコレクションは書き込まれますが、読み取られることはめったにありません。データは単一のMongoDBデータベースに保存され、その統計は以下に示されています(dbおよびコレクション名が変更されています)。
"db" : "MyDatabase",
"collections" : 854,
"objects" : 243025868,
"avgObjSize" : 541.2304596809423,
"dataSize" : 131533002252,
"storageSize" : 172592721920,
"numExtents" : 7268,
"indexes" : 1934,
"indexSize" : 27824138048,
"fileSize" : 210284576768,
"nsSizeMB" : 16,
"dataFileVersion" : {
"major" : 4,
"minor" : 5
},
"extentFreeList" : {
"num" : 3,
"totalSize" : 110592
},
"ok" : 1
以下に示すように、ワーキングセットは約100MBのマークのように見えます。
"workingSet" : {
"note" : "thisIsAnEstimate",
"pagesInMemory" : 20874,
"computationTimeMicros" : 26236,
"overSeconds" : 876
},
最近障害が発生したセカンダリのログファイル出力は次のとおりです(これは起動時に発生しましたが、最初に障害が発生したのは通常の操作中です)。
2014-11-25T09:25:17.833 + 0000 [rsBackgroundSync] replSet同期先:10.1.6.71:27017 2014-11-25T09:25:17.833 + 0000 [rsBackgroundSync] replset設定syncSourceFeedbackを10.1.6.71:27017に2014-11- 25T09:25:17.849 + 0000 [rsSync] replSetはまだ同期していますが、まだminValid optime 54744561:c 2014-11-25T09:25:18.286 + 0000 [rsSync] replSet SECONDARY 2014-11-25T09:26:01.590 + 0000 [ conn21] serverStatusが非常に遅かった:{基本後:0、アサート後:0、backgroundFlushing後:0、接続後:0、カーソル後:0、dur後:0、extra_info後:0、globalLock後:0、indexCounters後:0、ロック後:0、ネットワーク後:0、opcounters後:0、opcountersRepl後:0、oplog後:10451、recordStats後:10451、repl後:10451、終了時:10451} 2014-11-25T09:26 :01.590 + 0000 [conn21]コマンドadmin。$ cmdコマンド:serverStatus {serverStatus:1、oplog:1} keyUpdates:0 numYields:0 locks(micros)r:65 reslen:4028 16764ms 2014-11-25T09:26:31.155 +0000 [DataFileSync] mmapのフラッシュに15022msかかりましたr115ファイル2014-11-25T09:26:47.501 + 0000 [conn5] serverStatusが非常に遅かった:{基本後:0、アサート後:0、backgroundFlushing後:0、接続後:0、カーソル後:0、dur後:0、extra_info後:0、globalLock後:0、indexCounters後:0、ロック後:0、ネットワーク後:0、opcounters後:0、opcountersRepl後:0、oplog後:4791、recordStats後:4791、repl後:4791、終了時:4791} 2014-11-25T09:26:47.501 + 0000 [conn5]コマンドadmin。$ cmdコマンド:serverStatus {serverStatus:1、oplog:1} keyUpdates:0 numYields:0 locks(micros)r :88 reslen:4028 7674ms 2014-11-25T09:27:06.350 + 0000 [repl writer worker 6]VirtualProtect for m:/mongodb/data/MyDatabase.72チャンク21220がerrnoで失敗しました: 1455ページングファイルが小さすぎてこの操作を完了できません。(チャンクサイズは67108864、アドレスは14b90000000)in mongo :: makeChunkWritable、終了2014-11-25T09:27:06.350 + 0000 [replライターワーカー6] MyDatabase.RC_PUR_11_456754致命的なアサーション16362201 4-11-25T09:27:06.615 + 0000 [repl writer worker 6]スタックトレースが失敗しました、SymInitializeがエラー3765269347で失敗しました2014-11-25T09: 27:06.615 + 0000 [replライターワーカー6] MyDatabase.RC_PUR_11_456754 2014-11-25T09:27:06.615 + 0000 [replライターワーカー6]
*** fassert()の失敗後の中止
Windowsでは、最悪のシナリオでは、ページファイルのサイズをデータファイルのサイズ+物理メモリのサイズに設定する必要がある場合があります。したがって、データファイルがディスク上で50 GBを占める場合、大まかなガイダンスは、ページファイルのサイズを53.5GBに設定することです。新しいストレージエンジンはOSが提供する仮想メモリサービスに依存しないため、これはMongoDB2.8リリースで改善されます。関連するテーマでは、3.5GBのメモリサイズは非常に小さいように聞こえます。リソースモニターで1秒あたりのハードページフォールトを確認します。数が数百の場合は、メモリサイズを大幅に増やす必要があります。