インスタンス (7 GB RAM)にmongodb(バージョン: 2.0.8) をインストールしましたEC2が、データ サイズはまだ1GB. 100 IOPSディスクのパフォーマンスを向上させるために、プロビジョニングされたディスクを使用しています。
問題は、以下のようなランダムな SLOW QUERIES を多数取得していることです (mongo ログから)。
db.UserInfoShared クエリ: { _id: "999081873179" } ntoreturn:1 idhack:1 reslen:108 1919ms
ほとんどかかりました2 secs！
これは、各エントリのサイズが小さい_idコレクションのルックアップにすぎません。インスタンスには mongo のみが実行されており、通常、このようなルックアップにかかる時間は.100,000500 bytes0.01 sec
これの考えられる原因は何ですか？解決するにはどうすればよいですか？どんな助けでも大歓迎です...
@angela、@Asya、助けてくれてありがとう。
結局のところ、レイテンシーの主な原因は mongodbGLOBAL LOCK自体でした。平均 5% のロック率があり、30 ～ 50% に達することもあり、クエリが遅くなります。
この問題に直面している場合、最初に行う必要があるのは、mongodb MMS サービス ( mms.10gen.com) を有効にすることです。これにより、db サーバーで正確に何が起こっているかについて多くの洞察が得られます。
私たちの場合、LOCK PERCENTAGE は非常に高く、それには複数の理由がありました。それを理解するために最初にしなければならないことは、並行性に関するmongodbのドキュメントを読むことです http://docs.mongodb.org/manual/faq/concurrency/
ロックの理由は、アプリケーション レベル、mongodb、またはハードウェアにある可能性があります。
1）私たちのアプリは多くのことを行っていて、updates各更新（以上100 ops/sec）はglobal lockmongodbに保持されています。問題は、メモリ内にないエントリに対して更新が発生した場合、mongo は最初にデータをメモリにロードしてから (メモリ内で) 更新する必要があり、プロセス全体がglobal lock. 全体が完了するまでに 1 秒かかるとします (0.75secディスクからデータをロードし0.25secてメモリに更新するため1 sec)。アプリサーバーでのリクエストがますます遅くなります。
queryその解決策は (ばかげているように聞こえるかもしれませんが) update、. それが効果的に行うことは、「メモリへのデータのロード」（0.75秒）の部分を移動することですglobal lock。lock percentage
2) グローバル ロックのもう 1 つの主な原因は、mongodb のflushディスクへのデータです。基本的に、60 秒 (またはそれ以下) ごとに mongodb (または OS) がデータをディスクに書き込み、global lockこのプロセス中に a が保持されます。（これはランダムな遅いクエリを説明しています）。MMS 統計で、グラフを参照してくださいbackground flush avg... 高い場合は、より高速なディスクを入手する必要があることを意味します。
私たちの場合、新しいEBS optimizedインスタンスに移動し、EC2プロビジョニングIOPSされ100たものも増やしました。これにより、サーバーは現在、500ほぼ半分にbackground flush avgなり、サーバーははるかに満足しています.