O gerenciamento eficiente de recursos é fundamental para manter a estabilidade de instâncias do MongoDB, especialmente em ambientes compartilhados ou baseados em containers. Existem duas abordagens principais para restringir o consumo de recursos: através das ferrametnas de oruqestração (como Docker) ou via parâmetros internos do motor de armazenamento WiredTiger.

1. Restrições de Recursos via Docker

Ao implementar o MongoDB utilizando Docker, é possível aplicar limites rígidos de hardware diretamente na criação do container. Isso evita que o processo mongod consuma toda a RAM do hospedeiro em picos de carga.

Limites de Memória e Swap

Os parâmetros a seguir controlam como o container interage com a memória física e a área de troca:

• --memory ou -m: Define o limite máximo de memória física. Exemplo: 512m, 2g.
• --memory-swap: Define o total acumulado de memória RAM + Swap. Deve ser sempre maior que o valor definido em -m.
• --memory-swappiness: Controla a tendência do kernel de mover processos da RAM para o swap (valor entre 0 e 100).

# Exemplo: Limitando a 512MB de RAM e desativando swap agressivo
docker run -d \
  --name mongo-prod \
  -m 512M \
  --memory-swappiness=0 \
  mongo:latest

Se você definir --memory-swap como -1, o container terá a memória RAM limitada pelo parâmetro -m, mas poderá utilizar swap de forma ilimitada conforme a disponibilidade do host.

Restrições de Processamento (CPU)

Além da memória, é recomendável limitar o uso de CPU para garantir que outros serviços não fiquem sem ciclos de processamento:

# Executar o MongoDB utilizando apenas os núcleos 0 e 1 do processador
docker run -d \
  --cpuset-cpus="0,1" \
  --cpu-shares=512 \
  mongo:latest

2. Configuração do Cache Interno (WiredTiger)

Desde a versão 3.2, o MongoDB utiliza o WiredTiger como motor padrão. Por natureza, o WiredTiger tenta reservar uma porção significativa da RAM para seu cache interno para acelerar as operações de leitura e escrita. Se não configurado, ele pode ocupar 50% da RAM disponível (menos 1GB em versões recentes), o que pode causar conflitos em containers onde o limite do Docker é menor que a percepção de memória do sistema operacional.

Abaixo, um exemplo de arquivo de configuração (mongod.conf) otimizado para limitar o uso de memória:

storage:
  # Diretório para armazenamento dos arquivos de dados
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
  engine: wiredTiger
  wiredTiger:
    engineConfig:
      # Define o tamanho do cache do WiredTiger em GB. 
      # No exemplo abaixo, limitamos a 2GB.
      cacheSizeGB: 2

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 0.0.0.0
  # Proteção contra excesso de conexões simultâneas
  maxIncomingConnections: 5000

Considerações sobre o cacheSizeGB

Este parâmetro é o controle mais importante para a saúde do MongoDB. Ele não limita o uso total da memória do processo mongod (que ainda usará memória para conexões, índices e operações de agregação), mas limita a área de cache de dados brutos. Se o MongoDB estiver rodando dentro de um container Docker limitado a 4GB de RAM, é prudente configurar o cacheSizeGB para algo em torno de 1.5GB a 2GB, deixando margem para o sistema operacional e para as operações internas do banco.

Para aplicar as alterações via arquivo de configuração, inicie o serviço apontando para o caminho do arquivo:

mongod --config /etc/mongod.conf