Pression mémoire / OOM

Symptôme

L'OOM killer tue le processus, 'out of memory', cache hit ratio faible, swap excessif, Redis 'OOM command not allowed'.

1. Qui consomme la mémoire

Est-ce la mémoire allouée à la base (buffer pool/SGA), la mémoire par session (PGA/sort/work_mem), ou l'OS dans son ensemble ? Vérifiez free/vmstat au niveau OS et les vues mémoire dans la base.

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. Distinguez la configuration de la charge

Le total des paramètres mémoire dépasse-t-il la RAM physique (over-commit) ? Calculez shared_buffers + (work_mem * concurrence). Ou s'agit-il d'une charge momentanée (un tri/hash énorme, de nombreuses connexions) ?

3. Spécifique à Redis : éviction et fragmentation

Si used_memory a atteint maxmemory, vérifiez maxmemory-policy (avec noeviction, les écritures sont rejetées). Si mem_fragmentation_ratio est élevé, utilisez MEMORY PURGE / activedefrag. Trouvez les grosses clés avec --bigkeys.

Redis

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

4. Soulagez immédiatement

Tuez la requête/la session incontrôlée qui dévore la mémoire, abaissez temporairement la mémoire de session comme work_mem, coupez les connexions inutiles. Si le système swappe, sortir du swap est la priorité.

5. Dimensionnez correctement

Répartissez correctement la RAM avec le calculateur Outils > Memory/Buffer Pool. Règle générale : sur un serveur dédié, buffer pool/SGA ~70-80 % de la RAM ; la mémoire totale des sessions multipliée par la concurrence ne doit pas dépasser la RAM. Ajoutez de la RAM si nécessaire.