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

Pressão de memória / OOM

Sintoma

O OOM killer mata o processo, 'out of memory', cache hit ratio baixo, swap excessivo, Redis 'OOM command not allowed'.

1. Quem está consumindo memória

É a memória alocada pelo banco (buffer pool/SGA), a memória por sessão (PGA/sort/work_mem) ou o SO como um todo? Verifique free/vmstat no nível do SO e as views de memória dentro do banco.

Oracle

SELECT component, current_size/1048576 mb FROM v$memory_dynamic_components WHERE current_size>0;

PostgreSQL

SHOW shared_buffers; SHOW work_mem; -- work_mem * connections * number of sorts can blow up in total

MySQL

SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; SHOW STATUS LIKE 'Innodb_buffer_pool%';

Redis

INFO memory  # used_memory, maxmemory, mem_fragmentation_ratio

2. Separe configuração de carga

O total das configurações de memória excede a RAM física (over-commit)? Calcule shared_buffers + (work_mem * concorrência). Ou é uma carga momentânea (um sort/hash enorme, muitas conexões)?

3. Específico do Redis: eviction e fragmentação

Se used_memory atingiu maxmemory, verifique maxmemory-policy (com noeviction, as escritas são rejeitadas). Se mem_fragmentation_ratio estiver alto, use MEMORY PURGE / activedefrag. Encontre chaves grandes com --bigkeys.

Redis

CONFIG GET maxmemory-policy
MEMORY DOCTOR
redis-cli --bigkeys

4. Alivie imediatamente

Mate a consulta/sessão descontrolada que está comendo memória, reduza temporariamente a memória de sessão como work_mem, derrube conexões desnecessárias. Se o sistema estiver fazendo swap, sair do swap é a prioridade.

5. Dimensione corretamente

Distribua a RAM corretamente com a calculadora em Ferramentas > Memória/Buffer Pool. Regra geral: em um servidor dedicado, buffer pool/SGA ~70-80% da RAM; a memória total de sessões multiplicada pela concorrência não deve exceder a RAM. Adicione RAM se necessário.

Abrir no DBAtlas →