DBAtlas · Atlas für Datenbankbetrieb

Speicherdruck / OOM

Symptom

Der OOM Killer beendet den Prozess, 'out of memory', niedrige Cache Hit Ratio, übermäßiges Swapping, Redis 'OOM command not allowed'.

1. Wer verbraucht den Speicher

Ist es der allokierte Speicher der DB (Buffer Pool/SGA), der Speicher pro Session (PGA/Sort/work_mem) oder das OS insgesamt? Prüfe auf OS-Ebene free/vmstat und innerhalb der DB die Speicher-Views.

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. Konfiguration von Last trennen

Übersteigt die Summe der Speichereinstellungen den physischen RAM (Over-Commit)? Berechne shared_buffers + (work_mem * Parallelität). Oder ist es eine kurzzeitige Last (eine riesige Sortierung/ein riesiger Hash, viele Verbindungen)?

3. Redis-spezifisch: Eviction und Fragmentierung

Hat used_memory maxmemory erreicht, prüfe maxmemory-policy (bei noeviction werden Schreibvorgänge abgewiesen). Ist mem_fragmentation_ratio hoch, nutze MEMORY PURGE / activedefrag. Finde große Keys mit --bigkeys.

Redis

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

4. Sofort entlasten

Beende die ausufernde Abfrage/Session, die Speicher frisst, senke vorübergehend den Session-Speicher wie work_mem, trenne unnötige Verbindungen. Swappt das System, hat das Verlassen des Swaps Vorrang.

5. Richtig dimensionieren

Verteile den RAM richtig mit dem Rechner unter Tools > Memory/Buffer Pool. Allgemeine Regel: auf einem dedizierten Server Buffer Pool/SGA ~70-80 % des RAM; der gesamte Session-Speicher multipliziert mit der Parallelität darf den RAM nicht übersteigen. Füge bei Bedarf RAM hinzu.

In DBAtlas öffnen →