DBAtlas · Atlas de operações de banco de dados

Pressão de memória / OOM

A memória do servidor está acabando, o sistema está fazendo swap ou o OOM killer está ativo. Primeiro determine quem está consumindo a memória: a memória alocada (buffer pool/SGA), a memória de sessão (work_mem/PGA), o SO como um todo ou uma situação específica do Redis?

Quem está consumindo a memória?

Separe por camada a origem da pressão de memória. A memória alocada (fixa) é grande demais, a memória por sessão está explodindo, um processo que não é do banco a está consumindo ou é o próprio gerenciamento de memória do Redis?

SELECT component, ROUND(current_size/1024/1024) AS mb FROM v$memory_dynamic_components WHERE current_size>0 ORDER BY current_size DESC;
  • A memória alocada (buffer pool / SGA) predomina
  • A memória de sessão (work_mem / PGA) está explodindo
  • Um processo que não é do banco / o SO como um todo
  • Específico do Redis (maxmemory / eviction / fragmentação)

A memória total configurada excede a RAM física?

Se a memória alocada fixa é grande, há duas possibilidades: ou o total configurado (buffer pool + sessões + SO) excede a RAM física (over-commit), ou o tamanho é razoável, mas a taxa de acerto do cache ainda é baixa. Some as configurações e compare com a RAM.

SHOW PARAMETER sga_target;  SHOW PARAMETER pga_aggregate_target;
SELECT ROUND(value/1024/1024/1024,1) AS host_ram_gb FROM v$osstat WHERE stat_name='PHYSICAL_MEMORY_BYTES';
  • Sim, o total configurado excede a RAM (over-commit)
  • Não, o tamanho é razoável, mas a taxa de acerto do cache é baixa

Causa raiz: over-commit de memória

A soma de buffer pool/SGA + memória de sessão + necessidades do SO excede a RAM física. O sistema está fazendo swap ou o OOM killer está matando o processo.

Causa raiz: cache insuficiente (taxa de acerto do cache baixa)

A memória alocada não excede a RAM, mas é pequena em relação ao working set; a taxa de acerto do buffer cache é baixa e o banco lê constantemente do disco.

Causa raiz: explosão da memória de sessão

A memória por sessão, como work_mem/PGA, multiplicada pela alta concorrência, esgota a RAM. Cada operação de sort/hash pode alocar essa memória separadamente.

Causa raiz: gerenciamento de memória do Redis

No Redis, used_memory atingiu maxmemory, a eviction está ativa ou a fragmentação está alta (used_memory_rss >> used_memory). É preciso tratar a política e a fragmentação.

Causa raiz: consumo de memória fora do banco

A memória não está sendo consumida pelo banco de dados, mas pelo SO como um todo ou por um processo vizinho: outra aplicação, pressão do cache do sistema de arquivos ou um processo auxiliar com vazamento.

Abrir no DBAtlas →