Hoher IO-Wait / Disk-Latenz
Das System wartet auf Disk-IO. Zuerst klären wir, ob die Last lese- oder schreibintensiv ist, und arbeiten uns dann zu den Ursachen vor: zu kleiner Buffer Cache, Full Table Scans, Checkpoint-Stürme, IOPS-Limits oder Auslagerung in temporären Speicher.
Ist das IO leseintensiv oder schreibintensiv?
Bestimme mit Datei-IO-Statistiken, ob die Wartezeit auf der Leseseite (Daten werden von der Disk gelesen) oder auf der Schreibseite (Redo-/Checkpoint-/Datenschreibvorgänge) liegt. Das teilt den Baum in zwei Zweige.
SELECT function_name, small_read_reqs+large_read_reqs AS reads, small_write_reqs+large_write_reqs AS writes,
small_read_megabytes+large_read_megabytes+small_write_megabytes+large_write_megabytes AS mb
FROM v$iostat_function ORDER BY mb DESC;- Überwiegend Lese-IO
- Überwiegend Schreib-IO
Warum ist das Lese-IO hoch?
Übermäßige physische Lesevorgänge haben drei Hauptursachen: Der Buffer Cache ist zu klein (das Working Set passt nicht in den RAM), Abfragen führen Full Table Scans aus, oder große Sort-/Hash-Operationen werden in temporären Speicher ausgelagert.
SELECT ROUND((1-(pr.value/(dbg.value+cg.value)))*100,2) AS buffer_hit_pct
FROM v$sysstat pr, v$sysstat dbg, v$sysstat cg
WHERE pr.name='physical reads' AND dbg.name='db block gets' AND cg.name='consistent gets';
SELECT sql_id, disk_reads, executions FROM v$sql ORDER BY disk_reads DESC FETCH FIRST 10 ROWS ONLY;- Buffer-Cache-Trefferquote ist niedrig, das Working Set passt nicht
- Abfragen führen Full Table Scans aus
- Große Sorts/Hashes werden in temporären Speicher ausgelagert
Warum ist das Schreib-IO hoch?
Ein Engpass auf der Schreibseite entsteht entweder dadurch, dass periodische Checkpoints/Flushes die Disk kurzzeitig auslasten (Checkpoint-Sturm), oder dadurch, dass dem Storage IOPS/Durchsatz für die Dauerlast fehlen.
SELECT event, total_waits, ROUND(time_waited/100,1) AS sec
FROM v$system_event
WHERE event IN ('log file parallel write','db file parallel write','checkpoint completed')
ORDER BY time_waited DESC;- Plötzliche Checkpoint-/Flush-Wellen (Checkpoint-Sturm)
- Storage hält der Dauerlast nicht stand (IOPS-Limit)
Ursache: zu kleiner Buffer Cache
Der häufig genutzte Datenbestand (Working Set) passt nicht in den Buffer Cache, daher werden Blöcke ständig erneut von der Disk gelesen. Die Trefferquote ist niedrig und die physischen Lesevorgänge sind hoch.
Ursache: Full Table Scans
Abfragen scannen große Tabellen komplett, weil kein passender Index existiert; das verursacht viele physische Lesevorgänge und füllt den Cache mit nutzlosen Blöcken.
Ursache: Sorts/Hashes werden in temporären Speicher ausgelagert
Große Sort-, Hash-Join- oder Group-by-Operationen passen nicht in den Arbeitsspeicher und schreiben in temporären Speicher (temp/tempdb), was hohes Lese-/Schreib-IO erzeugt.
Ursache: Checkpoint-Sturm
Dirty Pages sammeln sich lange an und werden in kurzen Abständen massenhaft auf die Disk geschrieben; diese plötzlichen Schreibwellen lasten das IO periodisch aus.
Ursache: unzureichende IOPS / unzureichender Durchsatz
Dem Storage fehlen IOPS oder Bandbreite, um die von der Workload benötigten Lese- und Schreibanfragen zu bedienen; Queue-Tiefe und Latenz sind dauerhaft hoch.