Presión de memoria / OOM
Síntoma
El OOM killer termina el proceso, 'out of memory', cache hit ratio bajo, swapping excesivo, Redis 'OOM command not allowed'.
1. ¿Quién está consumiendo memoria?
¿Es la memoria asignada de la BD (buffer pool/SGA), la memoria por sesión (PGA/sort/work_mem) o el SO en su conjunto? Revise free/vmstat a nivel de SO y las vistas de memoria dentro de la BD.
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 totalMySQL
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; SHOW STATUS LIKE 'Innodb_buffer_pool%';Redis
INFO memory # used_memory, maxmemory, mem_fragmentation_ratio2. Separe la configuración de la carga
¿La suma de los parámetros de memoria supera la RAM física (over-commit)? Calcule shared_buffers + (work_mem * concurrencia). ¿O es una carga momentánea (un sort/hash enorme, muchas conexiones)?
3. Específico de Redis: eviction y fragmentación
Si used_memory ha alcanzado maxmemory, revise maxmemory-policy (con noeviction, se rechazan las escrituras). Si mem_fragmentation_ratio es alto, use MEMORY PURGE / activedefrag. Encuentre claves grandes con --bigkeys.
Redis
CONFIG GET maxmemory-policy
MEMORY DOCTOR
redis-cli --bigkeys4. Alivie de inmediato
Termine la consulta/sesión descontrolada que consume memoria, reduzca temporalmente la memoria de sesión como work_mem, cierre las conexiones innecesarias. Si el sistema está haciendo swapping, salir del swap es la prioridad.
5. Dimensione correctamente
Distribuya la RAM correctamente con la calculadora Herramientas > Memory/Buffer Pool. Regla general: en un servidor dedicado, buffer pool/SGA ~70-80% de la RAM; la memoria total de sesión multiplicada por la concurrencia no debe superar la RAM. Agregue RAM si es necesario.