1

mongo でこの問題にしばらく気付きましたが、それに関する内部ドキュメントや、この問題を軽減する方法は見つかりませんでした。まったく同じクエリのうちの 2 つについて説明します。一方は他方の直後に実行されます。

> db.derp.find().explain()
{
    "cursor" : "BasicCursor",
    "isMultiKey" : false,
    "n" : 8418,
    "nscannedObjects" : 8418,
    "nscanned" : 8418,
    "nscannedObjectsAllPlans" : 8418,
    "nscannedAllPlans" : 8418,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 3,
    "nChunkSkips" : 0,
    "millis" : 3267,
    "indexBounds" : {

    },
    "server" : ...
}

2回目の実行：

> db.derp.find().explain()
{
    "cursor" : "BasicCursor",
    "isMultiKey" : false,
    "n" : 8418,
    "nscannedObjects" : 8418,
    "nscanned" : 8418,
    "nscannedObjectsAllPlans" : 8418,
    "nscannedAllPlans" : 8418,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 6,
    "indexBounds" : {

    },
    "server" : ...
}

これは、クエリ速度が 3.2 秒から 6 ミリ秒に大幅に短縮されたことを示しています。ここで行われているこの内部キャッシングに関する情報を探しています。また、このキャッシュを調整する方法があるかどうか (そのデータをキャッシュし続けるために) を探しています。

4

3 に答える 3

3

クエリが最初に要求したときに、ページが常駐メモリにロードされました。これが、2 番目のクエリの応答時間がほとんどかからなかった理由です。

クエリを実行するたびにサーバー ステータス ワーキング セット コマンドを実行して、その効果を調べることができます。もちろん、これは「新しく開始したデータベース」で行う必要があります

于 2013-07-19T19:45:01.140 に答える
1

最初のリクエストはディスクからデータを読み取ります。2 番目のリクエストはメモリからのものです。

于 2013-07-19T19:42:55.867 に答える
1

違いは、複数の理由による可能性があります。前述のように、最初のクエリはおそらくディスクからロードされ、2 番目のクエリは RAM にデータが既に存在していました。これをテストする簡単な方法は、mongostat を実行し、最初の実行の前後に常駐 RAM をチェックして、これにより常駐 RAM が増加し、ページ フォールトも表示されるかどうかを確認することです。mongostat の詳細については、http://docs.mongodb.org/manual/reference/program/mongostat/ を参照してください。データを mongodb にプリロードする場合は、http://docs.mongodb.org/manual/reference/command/touch/で説明されているように touch コマンドを使用できます。

于 2013-07-19T20:53:44.863 に答える