回答:
求められたとおりにできない（メモリを制限する）ことができない本当の理由は、MongoDBが直接使用するメモリを管理しないためです。OSに実行させることができます。MongoDBは、すべてのデータをメモリマップし、必要に応じてOSページにメモリを出し入れします。その結果、MongoDBがこれを完全に異なる方法で実装するか、OSが許可するまで、使用量を直接管理することはできません（Linuxでは2.4日以降不可能です）。
現在、リソースを本当に分離する唯一の方法は、仮想化ソリューションを使用して、MongoDBを独自のVMで分離することです。はい、オーバーヘッドが伴います（ハイパーバイザーはかなり良くなっていますが）が、現時点ではそのレベルのリソース制御に対して支払うべき価格です。
OOM Killerに関しては、ホスト上に他のプロセスがなくても、データセットとインデックス全体が使用可能なメモリを超えている限り、MongoDBはOOM Killerの問題を引き起こす可能性があります。これは、データがメモリからページアウトされる方法のためです-メモリのプレッシャーがなく（常駐メモリを必要とするものが他にない場合）、新しいデータとインデックスを追加/タッチし続けると、最終的に利用可能なすべてのRAMを消費します。したがって、MongoDBを実行するときは常にいくつかのスワップを構成することをお勧めします。
https://docs.mongodb.com/manual/administration/production-notes/#swap
もちろん、LRUデータは最初にページアウトされ、他のプロセスもres memを使用できますが、データセットをメモリにロードしてから静的にしない限り、この概念は適用されます。あなたが心配している場合に行うべき最善のことは、MMSにそれを入れて、時間の経過とともに使用状況を追跡することです：
更新：2015年8月
私がこの答えを書いて以来、物事はいくらか進んでおり、情報は少し古くなっています。たとえば、Linuxには現在、cgroupと関連テクノロジー（たとえばDockerコンテナー）があり、実稼働環境のプロセスで消費されるリソース（メモリーを含む）をより適切に分離および制限できるようになっています。 MongoDBのようなメモリマッピング。
さらに、MongoDB 3.0+のWiredTigerのようなMMAPを超える新しいストレージエンジンの出現により、組み込み機能を使用してMongoDBのキャッシュサイズを制限できます。したがって、現在のRAM要件は、MongoDBの構成方法、実行する環境、および選択するストレージエンジンによって実際に異なります。
MongoDBは、使用可能な空きメモリをキャッシュに使用し、必要に応じてディスクにスワップして、同じサーバー上の他のアプリケーションにメモリを割り当てます。最高のパフォーマンスを得るには、インデックスと頻繁に使用するデータ（「ワーキングセット」）をメモリに保持するのに十分なRAMが必要です。
参考文献：
MongoDBについては、年々何かが変更されます。
TL; DR
MMAPv1ストレージエンジンをMongoDBで使用する場合、working setサイズはRAMに収まる必要があります。
https://docs.mongodb.com/manual/faq/diagnostics/#must-my-working-set-size-fit-ram
WiredTigerストレージエンジンがMongoDBで使用されている場合、RAMが適切working setかどうかを気にする必要はありません。
https://docs.mongodb.com/manual/faq/diagnostics/#memory-diagnostics-for-the-wiredtiger-storage-engine
WiredTigerストレージエンジンのメモリ診断
ワーキングセットのサイズはRAMに適合しなければなりませんか？
いや
アプリケーションに必要なRAMの量を計算するにはどうすればよいですか？
WiredTigerでは、MongoDBはWiredTiger内部キャッシュとファイルシステムキャッシュの両方を利用します。
バージョン3.2で変更：MongoDB 3.2以降、WiredTigerの内部キャッシュは、デフォルトで次のいずれか大きい方を使用します。
RAMの60％から1 GB、つまり1 GB。