DBAtlas · Atlas für Datenbankbetrieb

Speicherdruck / OOM

Der Serverspeicher geht aus, das System swappt oder der OOM Killer ist aktiv. Bestimme zuerst, wer den Speicher verbraucht: belegter Speicher (Buffer Pool/SGA), Session-Speicher (work_mem/PGA), das OS insgesamt oder eine Redis-spezifische Situation?

Wer verbraucht den Speicher?

Trenne die Quelle des Speicherdrucks nach Ebene. Ist der belegte (feste) Speicher zu groß, explodiert der Speicher pro Session, frisst ein Prozess außerhalb der DB ihn, oder spielt die Speicherverwaltung von Redis selbst eine Rolle?

SELECT component, ROUND(current_size/1024/1024) AS mb FROM v$memory_dynamic_components WHERE current_size>0 ORDER BY current_size DESC;
  • Belegter Speicher (Buffer Pool / SGA) dominiert
  • Session-Speicher (work_mem / PGA) explodiert
  • Ein Prozess außerhalb der DB / das OS insgesamt
  • Redis-spezifisch (maxmemory / Eviction / Fragmentierung)

Übersteigt der konfigurierte Gesamtspeicher den physischen RAM?

Ist der fest belegte Speicher groß, gibt es zwei Möglichkeiten: Entweder übersteigt die konfigurierte Summe (Buffer Pool + Sessions + OS) den physischen RAM (Over-Commit), oder die Größe ist vernünftig, aber die Cache Hit Ratio trotzdem niedrig. Addiere die Einstellungen und vergleiche sie mit dem 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';
  • Ja, die konfigurierte Summe übersteigt den RAM (Over-Commit)
  • Nein, die Größe ist vernünftig, aber die Cache Hit Ratio ist niedrig

Ursache: Speicher-Over-Commit

Die Summe aus Buffer Pool/SGA + Session-Speicher + OS-Bedarf übersteigt den physischen RAM. Das System swappt, oder der OOM Killer beendet den Prozess.

Ursache: Zu kleiner Cache (niedrige Cache Hit Ratio)

Der belegte Speicher übersteigt den RAM nicht, ist aber im Verhältnis zum Working Set klein; die Hit Ratio des Buffer Cache ist niedrig, und die DB liest ständig von der Platte.

Ursache: Explosion des Session-Speichers

Speicher pro Session wie work_mem/PGA, multipliziert mit hoher Parallelität, erschöpft den RAM. Jede Sort-/Hash-Operation kann diesen Speicher separat belegen.

Ursache: Redis-Speicherverwaltung

In Redis hat used_memory maxmemory erreicht, Eviction ist aktiv oder die Fragmentierung ist hoch (used_memory_rss >> used_memory). Policy und Fragmentierung müssen behandelt werden.

Ursache: Speicherverbrauch außerhalb der DB

Der Speicher wird nicht von der Datenbank verbraucht, sondern vom Betriebssystem insgesamt oder einem benachbarten Prozess: einer anderen Anwendung, Druck durch den Dateisystem-Cache oder einem Hilfsprozess mit Speicherleck.

In DBAtlas öffnen →