大規模なコレクション(〜300GB)のインデックスをMongoDBで構築していますが、dbターミナルウィンドウは印刷を続けます。
[DataFileSync] flushing mmaps took 10920ms for 151 files
Mmapをフラッシュするのにかかる時間は、通常、約10秒で、場合によってはそれより長くなります。私は高性能マシンでMongoDBを実行しているため、RAM可用性は問題になりません。
データファイル同期メッセージはどういう意味ですか?
問題ですか?
編集:
フラッシュルーチンの本当の問題は、MongoDBがその間フリーズしているように見えることです。
同じホストのターミナルウィンドウからの単純なクエリでも、完了するにはフラッシュが完了するまで待機する必要があり、約10秒(最大150秒)は長すぎます。サーバーで操作が実行されておらず、アクティブな接続がゼロの場合でも、このルーチンは(1、2、または3分の不定期な間隔で)発生します。
Windows Server 2008 R2でMongoDB 2.2.1 2008R2 +を実行しています。
MongoDBは、60秒ごとにバックグラウンドスレッドを使用して、メモリ内のデータ変更をディスクにフラッシュします(調整可能です syncdelay を参照)。通常の操作中は、挿入、更新、削除など(インデックスへの変更を含む)となり、これらの操作に関しておおよそのアクティビティと相関します。 mmapsの部分は、MongoDBがメモリマップファイルを使用するという事実に関連しています
インデックスを作成すると、大量の新しいインメモリデータが作成され、それらはすべて60秒ごとにディスクに保持されます。そのフラッシュがどれだけ迅速かは、次の関数になります。
例では、フラッシュに10秒かかることが示されている場合、ディスクが少し苦労していることを意味します。1桁の秒が高く、2桁が心配です。もちろん、それはディスクの性質に依存します-SSDが(たとえば)10秒かかっていた場合、それは大量のデータである必要があります。
これはメッセージングを説明しますが、インデックスの作成はすべて集中的な(そしてブロックする)操作であることに加えて、影響を回避するためにプライマリでバックグラウンドで実行できますが、セカンダリまでフォアグラウンドで実行されます SERVER-2771 が修正されました。その結果、レプリカセットを使用してインデックスを構築するための推奨方法の概要を次に示します。
http://docs.mongodb.org/manual/administration/indexes/#index-building-replica-sets
影響は、ビルドにかかる時間、その時点で何をしているのかなどによって異なりますが、上記の手順に従うと、エンドユーザーに影響を与える影響を回避できるはずです。
mongod.exe
を介してMongoDBサービスを開始するときに、いくつかのパラメーターを指定できます。syncdelay
はそのうちの1つです。
次のコマンドを使用してサービスを開始しました。
mongod.exe --syncdelay 10 --quiet --directoryperdb --bind_ip 127.0.0.1 --port 27018 --dbpath "D:\dbPath
これにより、デフォルトの60秒ではなく、10秒ごとにMMAPファイルが更新されます。
私の場合、大量のデータが書き込まれているため、このオプションを使用すると問題が解決する可能性があります。
これがあなたにも役立つことを願っています。