Como configurar o cache do WiredTiger no MongoDB.

Guia Completo 2026 — dimensionamento, ajuste em containers e monitoramento.

O cache do WiredTiger é, isoladamente, o parâmetro de maior impacto na performance de leitura do MongoDB. Configurado errado, ele é a causa mais comum de leituras lentas em produção que parecem "aleatórias" — e a configuração default, embora sensata para a maioria dos casos, é frequentemente inadequada para containers, servidores compartilhados e workloads com padrão de acesso previsível.

O que é o cache do WiredTiger

Desde a versão 3.2, o WiredTiger é o storage engine padrão do MongoDB. Ele mantém um cache interno em memória com os dados e índices acessados com maior frequência — o chamado working set. Quando uma query encontra o dado no cache, a resposta é praticamente instantânea; quando não encontra, o WiredTiger precisa buscar em disco, e a diferença de latência entre os dois cenários costuma ser de uma a duas ordens de magnitude.

Dimensionar esse cache corretamente é a fronteira entre um MongoDB rápido e um MongoDB que "engasga" sob carga sem motivo aparente no dashboard de CPU.

O valor default — e por que ele nem sempre serve

Por padrão, o MongoDB reserva para o cache do WiredTiger o maior valor entre 50% da RAM disponível menos 1 GB, ou 256 MB:

wiredTigerCacheSizeGB = max((RAM_GB − 1) × 0.5, 0.25)

Em um servidor dedicado com 32 GB de RAM, isso resulta em ~15,5 GB de cache — um ponto de partida razoável, já que reserva o restante da memória para o filesystem cache do sistema operacional, que também acelera leituras (os arquivos de dados do MongoDB, comprimidos, ficam em cache no SO independentemente do cache do WiredTiger).

O problema aparece em três cenários recorrentes:

1. Containers e Kubernetes. Versões mais antigas do MongoDB podem não detectar corretamente o limite de memória do container (cgroup) e calculam o cache com base na RAM total do host, não do limite alocado — receita para OOM kill. Versões recentes detectam cgroups corretamente, mas definir o valor explicitamente continua sendo a prática mais segura.
2. Múltiplas instâncias no mesmo servidor. Se há mais de um mongod rodando na mesma máquina, o cálculo default não sabe disso — cada instância tentará reservar 50% da RAM total, e a soma facilmente ultrapassa a memória física disponível.
3. Workloads com working set conhecido. Se o conjunto de dados ativo é bem menor que a RAM disponível, um cache maior que o necessário não ajuda — e pode, em cenários específicos, competir por memória com o filesystem cache do SO de forma contraproducente.

Como configurar explicitamente

A forma mais confiável de definir o cache é diretamente no mongod.conf:

storage:
  dbPath: /var/lib/mongodb
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8

Em um container com limite de memória de 4 GB, por exemplo, um valor explícito e conservador (deixando margem para o processo do mongod, conexões e overhead do sistema operacional) é preferível a confiar no cálculo automático:

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 2

Reforçando: mesmo em ambientes que detectam cgroups corretamente, definir o valor de forma explícita elimina uma variável de incerteza — especialmente relevante em ambientes com deploys automatizados e múltiplos tamanhos de instância.

Ajuste em tempo real, sem reiniciar

Desde o MongoDB 3.2, é possível alterar o tamanho do cache em tempo de execução, sem downtime:

db.adminCommand({
  setParameter: 1,
  wiredTigerEngineRuntimeConfig: "cache_size=6G"
})

Atenção: essa alteração é temporária — ela vale até o próximo restart do processo. Para tornar a mudança permanente, é necessário atualizar também o mongod.conf com o novo valor. Esquecer esse segundo passo é um erro comum: o time testa o ajuste em runtime, valida o ganho de performance, e semanas depois um restart de manutenção silenciosamente reverte para o valor antigo.

Como monitorar o uso real do cache

Antes de qualquer ajuste, meça. O comando abaixo traz o valor configurado, em bytes:

db.serverStatus().wiredTiger.cache["maximum bytes configured"]
// resultado em bytes — divida por 1073741824 para obter GB

Para uma visão mais completa do comportamento do cache:

const cache = db.serverStatus().wiredTiger.cache;
print("Configurado (GB):", cache["maximum bytes configured"] / 1073741824);
print("Em uso (GB):", cache["bytes currently in the cache"] / 1073741824);
print("Lido do disco (bytes):", cache["bytes read into cache"]);
print("Escrito do cache (bytes):", cache["bytes written from cache"]);

Sinais de que o cache está subdimensionado

• Utilização consistentemente acima de 90% com taxa de eviction alta — o WiredTiger está sendo forçado a liberar páginas antes do ideal.
• Alto volume de páginas evictadas por application threads (e não pelos eviction threads dedicados do WiredTiger) — sinal de que o banco está sob pressão real de memória, já que idealmente a eviction acontece em background, não no caminho crítico da query da aplicação.
• Aumento de latência de leitura sem aumento correspondente de carga de CPU — indício clássico de que as leituras estão indo ao disco em vez de serem servidas pelo cache.

Recomendação da HTI

• Em servidores dedicados de produção, o range de 50–60% da RAM total costuma ser um bom ponto de partida — mas ponto de partida, não valor final.
• Sempre defina o cache explicitamente em ambientes containerizados, independentemente da versão do MongoDB.
• Monitore db.serverStatus().wiredTiger.cache de forma contínua (não apenas no momento do diagnóstico) — o padrão de working set de uma aplicação muda ao longo do tempo, e o dimensionamento de cache precisa acompanhar essa mudança.
• Trate ajuste de cache como parte de uma revisão de performance mais ampla — junto com estratégia de índices (regra ESR) e desenho de pipelines de agregação. Cache bem dimensionado não compensa índice ausente.

Precisa de ajuda para dimensionar o seu ambiente?

Fazemos essa análise como parte do Health Check de MongoDB — cache, índices, replicação e segurança, com relatório priorizado por impacto.

Artigo do cluster técnico Consultoria MongoDB da HTI Tecnologia — 35+ anos sustentando bancos de dados críticos no Brasil. Veja também o índice completo de artigos MongoDB.