次の設定があります。
RedisとMongoDBはどちらも、大量のデータを格納するために使用されます。 RedisはすべてのデータをRAMに保持する必要があることを知っています。これで問題ありません。残念ながら、mongoは大量のRAMそして、ホストRAM=がいっぱいになると(ここでは32GBについて話している)、mongoまたはRedisがクラッシュします。
これに関する次の以前の質問を読みました。
it's completely okay to limit the WiredTiger cache size, since it handles I/O operations pretty efficiently
MongoDB uses the LRU (Least Recently Used) cache algorithm to determine which "pages" to release, you will find some more information in these two questions
も追加しますMongoDB keeps what it can of the indexes in RAM. They'll be swaped out on an LRU basis. You'll often see documentation that suggests you should keep your "working set" in memory: if the portions of index you're actually accessing fit in memory, you'll be fine.
これらすべての答えから私が理解しているように見えるのは、
これを考慮して、私はmongoができる限り多くのRAMスペースを試して使用することを期待していましたが、少数のRAMスペースで機能し、ほとんどのものをフェッチすることもできますただし、--memory
と--memory-swap
を使用して、mongo Dockerコンテナーのメモリを(たとえば8GBに)制限しましたが、mongoはメモリを使い果たすとすぐにクラッシュしました。
Mongoに使用可能なメモリのみを使用させ、メモリに収まらないものすべてをディスクからフェッチさせるにはどうすればよいですか?
MongoDB BOLに従って ここバージョン3.4で変更:値は256MB
から10TB
の範囲で指定できますfloat
にすることもできます。また、デフォルト値も変更されています。
3.4
以降、WiredTiger内部キャッシュは、デフォルトで、次のいずれか大きい方を使用します。
50% of RAM minus 1 GB, or
256 MB.
WiredTiger
を使用すると、MongoDBはWiredTigerinternal cache
とfilesystem cache
の両方を利用します。
MongoDBはfilesystem cache
を介して、WiredTiger cache
または他のプロセスで使用されていないすべての空きメモリを自動的に使用します。
storage.wiredTiger.engineConfig.cacheSizeGBは、WiredTiger
内部キャッシュのサイズを制限します。オペレーティングシステムは、ファイルシステムキャッシュに使用可能な空きメモリを使用します。これにより、圧縮されたMongoDBデータファイルをメモリに保持できます。さらに、operating system
は、ファイルシステムブロックとファイルシステムキャッシュをバッファリングするために、任意の空きRAMを使用します。
[〜#〜] ram [〜#〜]の追加のコンシューマーに対応するには、WiredTiger
内部キャッシュサイズを減らす必要がある場合があります。
詳細については、参照 WiredTiger Storage Engine および 構成ファイルオプション
実際、よく見ると、「メモリ不足」で死ぬのはmongodではなく、最大のメモリ使用量を持っているため、mongodを強制終了するのはカーネルOOM(メモリ不足)マネージャです。
はい、monngodb構成パラメーター cacheSizeGB で問題の解決を試みることができますが、コンテナー環境では、 cgroups を使用して3つのリソースのいずれかを制限することをお勧めしますコンテナーが取得します。