Niedrige Cache-Trefferquote (Buffer-/Cache-Hit)

Die Cache-Trefferquote ist niedrig; Daten werden ständig von der Disk (oder aus der Quelle) gelesen. Bestimme, ob das Problem im Buffer/Shared Cache der DB oder im Redis-/Anwendungscache liegt, miss es und behebe es.

Welcher Cache hat eine niedrige Trefferquote?

Miss die Trefferquote und grenze das Problem ein: Ist der Buffer/Shared Cache der Datenbank niedrig (viele physische Lesevorgänge), oder hat der Redis-/Anwendungscache viele Misses und Evictions?

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';

• Trefferquote des DB-Buffer/Shared Cache ist niedrig
• Viele Misses / Evictions im Redis-/Anwendungscache

Warum wird von der Disk gelesen: Größe oder Scan-Muster?

Eine niedrige Buffer-Trefferquote hat zwei typische Ursachen: Die häufig genutzten Daten (Working Set) passen nicht in den Speicher (Cache zu klein), oder große Full Table Scans verschmutzen den Cache mit Einmal-Blöcken und verdrängen nützliche Pages.

SELECT component, current_size/1024/1024 AS mb FROM v$sga_dynamic_components WHERE component LIKE '%buffer cache%';
SELECT sql_id, disk_reads, executions FROM v$sql ORDER BY disk_reads DESC FETCH FIRST 10 ROWS ONLY;

• Working Set passt nicht in den RAM (Cache zu klein)
• Full Table Scans verschmutzen den Cache

Warum die Redis-Misses: maxmemory-Eviction oder TTL-/Schlüsselverwaltung?

Ist die Redis-Trefferquote niedrig, hat entweder der Speicher maxmemory erreicht und Schlüssel werden verdrängt, oder die TTL-Verwaltung/das Caching-Muster der Schlüssel ist schwach (kalte Schlüssel, geringe Wiederverwendung).

INFO memory
# used_memory, maxmemory, maxmemory_policy, evicted_keys
CONFIG GET maxmemory-policy
INFO keyspace
# Key count and expires (keys with TTL) ratio per db

• maxmemory voll, hohe Eviction
• Schwaches TTL-/Schlüsselmuster (geringe Wiederverwendung)

Ursache: Der Cache ist zu klein für das Working Set

Die häufig genutzten Daten sind größer als der zugewiesene Buffer/Cache, daher werden sie ständig verdrängt und erneut von der Disk gelesen. Die Trefferquote ist niedrig, die physischen Lesevorgänge sind hoch.

Ursache: Das Scan-Muster verschmutzt den Cache

Große Full Table Scans füllen den Cache mit Blöcken, die einmal genutzt und verworfen werden, und verdrängen heiße Pages; das senkt die Trefferquote.

Ursache: Redis-maxmemory-Eviction

Der Redis-Speicher hat das Limit maxmemory erreicht; alte Schlüssel werden verdrängt, um Platz für neue zu schaffen (evicted_keys steigt ständig). Dadurch gehen noch benötigte Einträge verloren und die Trefferquote sinkt.

Ursache: schwaches TTL-/Caching-Muster

Entweder bekommen Schlüssel gar keine TTL, sodass sich der Speicher mit kalten Daten füllt, oder das Caching-Muster hat eine geringe Wiederverwendung, sodass die meisten Requests als Miss enden.