Tenho a seguinte configuração:
- uma máquina host que executa três contêineres docker:
- MongoDB
- Redis
- Um programa usando os dois contêineres anteriores para armazenar dados
Tanto o Redis quanto o MongoDB são usados para armazenar grandes quantidades de dados. Eu sei que o Redis precisa manter todos os seus dados na RAM e estou bem com isso. Infelizmente, o que acontece é que o mongo começa a ocupar muita RAM e assim que a RAM do host está cheia (estamos falando de 32 GB aqui), o mongo ou o Redis travam.
Eu li as seguintes perguntas anteriores sobre isso:
- Limite o uso de RAM do MongoDB : aparentemente a maior parte da RAM é usada pelo cache do WiredTiger
- Limite de memória do MongoDB : aqui aparentemente o problema eram os dados de log
- Limite o uso de memória RAM no MongoDB : aqui eles sugerem limitar a memória do mongo para que ele use uma quantidade menor de memória para seu cache/logs/dados
- MongoDB usando muita memória : aqui eles dizem que é o sistema de cache WiredTiger que tende a usar o máximo de RAM possível para fornecer acesso mais rápido. Eles também afirmam
it's completely okay to limit the WiredTiger cache size, since it handles I/O operations pretty efficiently
- Existe alguma opção para limitar o uso de memória do mongodb? : cache novamente, eles também adicionam
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
- Relação de índice/RAM do MongoDB : citação:
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.
- como liberar o cache que é usado pelo MongoDB? : mesma resposta que em 5.
Agora, o que parece entender de todas essas respostas é que:
- Para um acesso mais rápido, seria melhor que o mongo ajustasse todos os índices na RAM. No entanto, no meu caso, estou bem com índices residindo parcialmente no disco, pois tenho um SSD bastante rápido.
- A RAM é usada principalmente para armazenamento em cache pelo mongo.
Considerando isso, eu esperava que o mongo tentasse usar o máximo de espaço de RAM possível, mas sendo capaz de funcionar também com pouco espaço de RAM e buscar a maioria das coisas do disco. No entanto, limitei a memória do contêiner do Mongo Docker (a 8 GB, por exemplo), usando --memory
e --memory-swap
, mas em vez de buscar coisas do disco, o mongo simplesmente travou assim que ficou sem memória.
Como posso forçar o mongo a usar apenas a memória disponível e buscar do disco tudo o que não cabe na memória?
Conforme MongoDB BOL Aqui Alterado na versão 3.4: Os valores podem variar de
256MB
a10TB
e podem ser umfloat
. Além disso, o valor padrão também mudou.A partir de
3.4
, o cache interno do WiredTiger , por padrão, usará o maior de:Com
WiredTiger
o , o MongoDB utiliza o WiredTigerinternal cache
e ofilesystem cache
.Por meio do
filesystem cache
, o MongoDB usa automaticamente toda a memória livre que não é usada peloWiredTiger cache
ou por outros processos.O storage.wiredTiger.engineConfig.cacheSizeGB limita o tamanho do
WiredTiger
cache interno. O sistema operacional usará a memória livre disponível para o cache do sistema de arquivos, o que permite que os arquivos de dados compactados do MongoDB permaneçam na memória. Além disso,operating system
usará qualquer RAM livre para armazenar em buffer os blocos do sistema de arquivos e o cache do sistema de arquivos.Para acomodar os consumidores adicionais de RAM , talvez seja necessário diminuir
WiredTiger
o tamanho do cache interno.Para mais informações sobre o mecanismo de armazenamento do WiredTiger e as opções do arquivo de configuração
Na verdade, se você olhar de perto, não é o mongod que morre por "falta de memória", é o gerenciador OOM do kernel (sem memória) que mata o mongod, porque tem o maior uso de memória.
Sim, você pode tentar resolver o problema com o parâmetro de configuração do monngodb cacheSizeGB , mas no ambiente de contêiner, é melhor usar cgroups para limitar os recursos que qualquer um dos três contêineres obtém.