http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodbからの引用
不十分なメモリ管理 - MongoDB は、データ セット全体をメモリ マッピングすることでメモリを管理し、ページ キャッシュの管理とフォールトをカーネルに任せます。よりインテリジェントなスキームは、使用前にインデックスのフォールトなどを実行したり、コールド/ホット データのフォールトをより効果的に処理したりできます。その結果、メモリ使用量を効果的に判断できず、パフォーマンスが最適化されません。
彼の言い分がわかりません。誰かがこれについて詳しく説明できますか？
@cHaoが言ったように、それはちょっとした暴言であり、作者はOS自身のメモリ管理プログラムがどれほど非常に複雑で複雑であるかを本当に理解していません.
これが、MongoDB が独自のメモリ管理を持たない理由です。これを行うと、問題やその他のナンセンスの頭痛の種になる可能性があるからです。結局のところ、OS には非常に優れたメモリ管理プロセスがあります (Windows でさえ)。同じレベルに到達するのに何年も、場合によっては数十年もかかるメモリ管理プロセスを作成する代わりに、それを使用してみませんか?
よりインテリジェントなスキームは、使用前にインデックスでフォルトなどを行うことができます
MongoDB があなたの心を読み取れるかどうかはわかりません...
つまり、実際にシステムを正しく設計していて、RAM 内のインデックスをすべて (または全体として) 同時に必要としない場合はどうなるでしょうか?
このようなプリエンプティブなデータのページング (フォールトではなく) を実行することは、適切なセットアップに対して直感に反するように聞こえます。
特定の時間にデータを RAM に置く必要がある場合は、 touch() http: //docs.mongodb.org/manual/reference/command/touch/ を使用するか、RAM で必要な一般的なクエリのスクリプトを実行できます。
その結果、メモリ使用量を効果的に判断できず、パフォーマンスが最適化されません。
うーん、その人は明らかに、OS の組み込みツールを実際に使用してmongod、テストでプロセスのページ フォールトとメモリ アクセスを測定することは決してありませんでした。
実際には、MongoDB の後者のバージョンには、メモリ使用量を引き起こすのに役立つツールがあると言われています: http://docs.mongodb.org/manual/reference/command/serverStatus/#server-status-workingset