Presión de memoria / OOM

La memoria del servidor se está agotando, el sistema hace swapping o el OOM killer está activo. Determine primero quién consume la memoria: ¿la memoria asignada (buffer pool/SGA), la memoria de sesión (work_mem/PGA), el SO en general o una situación propia de Redis?

¿Quién consume la memoria?

Separe el origen de la presión de memoria por capas. ¿La memoria asignada (fija) es demasiado grande, se dispara la memoria por sesión, la consume un proceso ajeno a la BD o interviene la gestión de memoria propia de Redis?

SELECT component, ROUND(current_size/1024/1024) AS mb FROM v$memory_dynamic_components WHERE current_size>0 ORDER BY current_size DESC;

• Domina la memoria asignada (buffer pool / SGA)
• La memoria de sesión (work_mem / PGA) se dispara
• Un proceso ajeno a la BD / el SO en general
• Propio de Redis (maxmemory / eviction / fragmentación)

¿Supera la memoria total configurada a la RAM física?

Si la memoria fija asignada es grande, hay dos posibilidades: o el total configurado (buffer pool + sesiones + SO) supera la RAM física (over-commit), o el tamaño es razonable pero el cache hit ratio sigue siendo bajo. Sume los ajustes y compárelos con la 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';

• Sí, el total configurado supera la RAM (over-commit)
• No, el tamaño es razonable pero el cache hit ratio es bajo

Causa raíz: Over-commit de memoria

La suma de buffer pool/SGA + memoria de sesión + necesidades del SO supera la RAM física. El sistema hace swapping o el OOM killer está matando el proceso.

Causa raíz: caché insuficiente (cache hit ratio bajo)

La memoria asignada no supera la RAM pero es pequeña respecto al working set; el hit ratio del buffer cache es bajo y la BD lee constantemente de disco.

Causa raíz: explosión de la memoria de sesión

La memoria por sesión, como work_mem/PGA, multiplicada por una alta concurrencia agota la RAM. Cada operación de sort/hash puede asignar esta memoria por separado.

Causa raíz: gestión de memoria de Redis

En Redis, used_memory ha alcanzado maxmemory, la expulsión (eviction) está activa o la fragmentación es alta (used_memory_rss >> used_memory). Hay que abordar la política y la fragmentación.

Causa raíz: consumo de memoria ajeno a la BD

La memoria no la consume la base de datos, sino el SO en general o un proceso vecino: otra aplicación, presión de la caché del sistema de archivos o un proceso auxiliar con fuga de memoria.