Redis-Tuning-Konzepte (Sitzungs-Schulung)

Überblick — was es tut

Dieser Artikel vermittelt, wie Sie die Kennzahlen auf dem Bildschirm Service ▸ Sitzungen (Redis) (/service/session) lesen und wie Sie darauf reagieren. Jener Bildschirm ist eine Live-Überwachungskonsole; diese Seite erklärt die dahinterliegenden Redis-Betriebskonzepte — Slowlog, Keyspace-Trefferquote, Speicherfragmentierung sowie Ablauf gegenüber Verdrängung.

InfraGuard verbindet sich niemals direkt mit Redis. Ein stellvertretender Collector im internen Netz (scripts/infr_redis_vts_collector.cjs, unter pm2 als minütlicher Cron ausgeführt) nimmt von jedem Knoten eine redis-cli INFO-Momentaufnahme und schreibt sie in die zentrale MySQL-Tabelle infr_redis_metric; die Anwendung liest diese Tabelle lediglich. Alle Werte hier stammen daher aus Standardfeldern von INFO.

Das genaue Vokabular und die Verbesserungstipps zu jeder Kennzahl liegen aus einer einzigen Quelle in den Schulungs-Popovers (beim Überfahren) des Sitzungsbildschirms (edu.* in resources/lang/{ko,en}/redis.php). Dieser Artikel fasst diese Konzepte zusammen und verknüpft sie, statt sie neu zu definieren — fahren Sie für alle Einzelheiten über die Live-Popovers.

Wann Sie es verwenden

• Eine Sitzungskarte ist auf Beeinträchtigt / Ausgefallen gewechselt und Sie möchten den Ursachencode verstehen (mem_saturation, fragmentation, blocked_clients, replica_link_down, rdb_save_failed, stale).
• Die Trefferquote wirkt niedrig, der Knoten scheint aber in Ordnung (Entscheidung, ob das für einen Sitzungsspeicher normal ist).
• Das Fragmentierungsverhältnis ist über 1,5 gestiegen oder unter 1,0 gefallen und Sie suchen Ursache und Abhilfe.
• Die Verdrängung ist über 0 gestiegen und Sie fürchten Sitzungsverluste.
• Das Slowlog wächst immer weiter und Sie müssen herausfinden, welches Befehlsmuster zu korrigieren ist.

Aufbau

Eine Sitzungskarte steht für einen Knoten (node_alias = infr_instance.alias, 1:1) und übernimmt die Erzählweise von Service ▸ Datenbank.

KPIs oben: Knotenanzahl · Aktiv/Beeinträchtigt/Ausgefallen · ops/s gesamt · Schlüssel gesamt · Clientsumme.

Wie die Kapazität (die Decke) bestimmt wird

Der 100-%-Bezugswert (das Budget) für Ringanzeige und Speicherdiagramm wird in dieser Reihenfolge gewählt:

1. Ist maxmemory gesetzt, ist das die harte Obergrenze (Redis erzwingt sie). Geschätzt frei = maxmemory − used.
2. Ist es nicht gesetzt (unbegrenzt), gilt Budget = total RAM − DB buffer pool − OS/other reserve (%). Die Reserve beträgt standardmäßig 20 % (Betriebsrichtlinie redis_reserve_pct); der Datenbank-Bufferpool wird anhand des access=database-Collectors desselben Knotens abgezogen.

Ein Knoten mit maxmemory 0 (unbegrenzt) zeigt den Hinweis „maxmemory nicht gesetzt — Anzeige relativ zum Betriebssystem-/Server-RAM“. Setzen Sie auf einer eigens für Sitzungen bestimmten Instanz ein explizites maxmemory (einen Bruchteil des Betriebssystem-RAM), damit sich die Verdrängungsrichtlinie vorhersehbar verhält.

Verwendung

1) Slowlog — warum es wächst (7 Ursachen zusammengefasst)

Redis ist single-threaded, ein einziger langsamer Befehl blockiert also den gesamten Server. slowlog_len ist der laufende Zähler der Befehle, die slowlog-log-slower-than (Standard 10 ms) überschreiten. Die häufigsten zuerst:

1. O(N)-Befehle — KEYS *, SMEMBERS, HGETALL, LRANGE 0 -1 durchlaufen ganze Sammlungen. Die Hauptursache.
2. Operationen auf großen Schlüsseln — Strings von mehreren MB oder Serialisierungs- und Übertragungskosten großer Hash/Set/ZSet.
3. Speicherdruck / Swap — die Allokation stockt, je näher die Belegung an die Obergrenze kommt.
4. Fork-Latenz der Persistenz — RDB-bgsave / AOF-Rewrite, latest_fork_usec.
5. Aufwendige Lua-/Funktionsskripte — ein aufwendiges EVAL blockiert für die Dauer seiner Ausführung.
6. Große Pipelines / MULTI — Tausende Befehle auf einmal stellen alles Übrige in die Warteschlange.
7. DEL großer Schlüssel — verwenden Sie das asynchrone UNLINK statt DEL.

Prüfen Sie direkt auf dem Knoten, welche Befehle tatsächlich aufgetreten sind:

# Die letzten 10 langsamen Befehle (redis-cli)
redis-cli SLOWLOG GET 10
# Schwellenwert + aufbewahrte Anzahl (Mikrosekunden · z. B. 10 ms)
redis-cli CONFIG SET slowlog-log-slower-than 10000
redis-cli CONFIG SET slowlog-max-len 128
redis-cli SLOWLOG RESET

Führen Sie KEYS * niemals in der Produktion aus — während es den gesamten Keyspace durchläuft, wartet jeder andere Befehl. Ersetzen Sie es durch die Cursor-Iteratoren SCAN / HSCAN / SSCAN / ZSCAN.

2) Keyspace-Trefferquote — niedrig ist kein Mangel

Trefferquote des jüngsten Fensters = Δkeyspace_hits / (Δhits + Δmisses). Ist die Stichprobe zu dünn (Delta-Nenner < 20), wird auf die seit dem Start kumulierte hit_rate zurückgegriffen. Noten: Hervorragend ≥99% · Gut ≥95% · Mäßig ≥80%.

Die Trefferquote ist KEINE Statusachse, die einen Knoten rot färbt. Ein Sitzungsspeicher hat naturgemäß wenige Treffer — jede neue Anmeldung, jeder Ablauf und jede Abmeldung ist ein Fehltreffer, weshalb 40–60 % normal sind (etwa blue mit 44,75 % ist ein völlig gesunder Sitzungsknoten). Deshalb wird der zwar vorhandene Schwellenwert redis_hit_rate_min (Standard 50) nicht für den Status verwendet — er wird nur zur Einordnung angezeigt. Echte Cache-Probleme werden lastunabhängig durch Speichersättigung, Verdrängung und Fragmentierung weiter unten erkannt.

Um die Trefferquote tatsächlich zu erhöhen: halten Sie den Arbeitsdatensatz resident (Spielraum bei RAM/maxmemory), bemessen Sie die TTLs richtig, entschärfen Sie den Cache-Ansturm (TTLs mit Jitter) und wärmen Sie fehltrefferlastige Präfixe vor. Einzelheiten finden Sie im Live-Popover zur Trefferquote.

3) Speicherfragmentierung — gesundes Band 1,0 bis 1,5

mem_fragmentation_ratio = used_memory_rss / used_memory — der physische Speicher, den das Betriebssystem Redis gegeben hat, im Verhältnis zu dem, was Redis tatsächlich nutzt.

Noten: Hervorragend 0,95–1,4 · Gut ~1,6 · Mäßig ~2,5. Der Statusschwellenwert redis_frag_ratio liegt standardmäßig bei 1,6.

Auf einer kleinen Instanz, bei der used_memory unter 64MB liegt, dominiert der feste Overhead das Verhältnis und die Fragmentierungszahl wird zum Fehlalarm. InfraGuard nimmt die Fragmentierung in diesem Fall aus der Bewertung heraus (frag_score = null) — der Wert wird weiterhin angezeigt, färbt den Knoten aber nicht rot.

4) Ablauf gegenüber Verdrängung — der Kern der Sitzungslebensdauer

In einem Sitzungsspeicher ist Ablauf normal, doch anhaltende Verdrängung über 0 bedeutet, dass lebende Sitzungen verworfen werden. Reagieren Sie so:

• Verdrängungsrate > 0 → RAM ergänzen / maxmemory erhöhen.
• Prüfen Sie die Richtlinie: allkeys-lru verdrängt auch Sitzungen; volatile-* verdrängt nur Schlüssel mit TTL.
• Steigt zugleich rejected_connections, haben Sie maxclients und das Speicherlimit gleichzeitig erreicht.

# Verdrängungsrichtlinie ansehen / ändern
redis-cli CONFIG GET maxmemory-policy
redis-cli CONFIG SET maxmemory-policy volatile-lru
# Online-Defragmentierung (bei Fragmentierung > 1.5 · benötigt jemalloc)
redis-cli CONFIG SET activedefrag yes

Das Speicherverwaltungsdiagramm im Detail legt eine 100-%-Kapazitätsdeckenlinie über used_pct und markiert Verdrängungsepisoden mit crit-Nadeln — so lässt sich visuell nachvollziehen, wann der Knoten an die Decke stieß und Sitzungen verwarf.

5) Logische Datenbanken lesen (Keyspace)

INFO keyspace meldet die Schlüsselanzahl nummerierter, voneinander unabhängiger Schlüsselräume (logische Datenbanken, standardmäßig 16, Index 0–15).

# INFO keyspace example
db0:keys=48213,expires=48213,avg_ttl=1680000
db1:keys=126,expires=0,avg_ttl=0

Die Datenbank mit den meisten Schlüsseln ist der Hauptsitzungsspeicher, und wenn in dieser Datenbank keys = expires (alle mit TTL) gilt, ist es ein reiner Sitzungsspeicher (die Schlüssel verfallen von selbst). Oben liest sich db0 als Sitzungen (alle mit TTL) und db1 als anderer Verwendungszweck (Cache/Sperren).

Datenquellen

Statusschwellenwerte (Betriebsrichtlinie infr_setting group=ops):

master_link_status=down (Replikatverbindung unterbrochen) und rdb_last_bgsave_status=err (RDB-Speicherung fehlgeschlagen) werden ebenfalls als Gründe für Beeinträchtigt erfasst. Das Keyspace-Detail je Datenbank, total_system_memory und die Schlüsselsummen sind Erweiterungsspalten des Collectors — bei einem älteren Collector blenden sich diese Abschnitte stillschweigend aus („wird nach erneutem Ausrollen des Collectors angezeigt“).

Zugriff

• Lesen (den Sitzungsbildschirm ansehen): Rollenbereich Service min_req 1 — jeder angemeldete Benutzer (demo=1 und höher). Der Bildschirm ist schreibgeschützt, es gibt daher keine Schreibsperre (keine direkte Redis-Verbindung, keine Schreibbefehle).
• Schwellenwerte bearbeiten: passen Sie die redis_*-Werte in der Betriebsrichtlinie an — Administrator level≥5 (admin=10, über infr.level abgesichert).
• Collector registrieren: das Hinzufügen von redis_host-Knoten zum redis_vts-Collector erfolgt unter Collectors mit level≥5.

Fehlerbehebung und FAQ

F. Es erscheint nur „Bislang keine Redis-Knoten erfasst.“ A. infr_redis_metric ist leer. Registrieren Sie unter Verwaltung ▸ Collectors redis_host-Knoten am redis_vts-Collector und rollen Sie scripts/infr_redis_vts_collector.cjs unter pm2 auf dem stellvertretenden Host aus. Der Collector legt die Tabelle per CREATE TABLE IF NOT EXISTS an und erfasst minütlich.

F. Ein Knoten bleibt mit dem Grund stale auf Ausgefallen. A. Die letzte Stichprobe ist älter als 5 Min. (redis_stale_min) — der pm2-Collector ist abgestürzt (pm2 ls), oder der Netz-/redis-cli-Zugang zum Knoten ist blockiert. Prüfen Sie die Collector-Protokolle.

F. Die Abschnitte zur Keyspace-/Sitzungsanalyse und zur Speicherdecke fehlen. A. total_system_memory, keyspace je Datenbank und die Schlüsselsummenspalten sind Collector-Erweiterungen. Bei einem älteren Collector sind sie null, sodass sich die Abschnitte ausblenden — rollen Sie den neuesten Collector erneut aus, damit sie erscheinen.

F. Die Trefferquote liegt bei 45 % — warum ist der Knoten nicht Beeinträchtigt? A. Das ist so beabsichtigt. Ein Sitzungsspeicher hat üblicherweise wenige Treffer, deshalb setzt die Trefferquote einen Knoten nie auf Beeinträchtigt. Echte Probleme (Speichersättigung, Verdrängung, Fragmentierung) werden auf eigenen Achsen erfasst.

F. Die Fragmentierung zeigt 3,0, die Instanz ist aber winzig. A. Liegt used_memory unter 64MB, verzerrt der feste Overhead das Verhältnis. InfraGuard nimmt die Fragmentierung in diesem Fall aus der Bewertung heraus — betrachten Sie den Wert als reine Information. Sofern es sich nicht um tatsächliches Swapping (<1,0) handelt, besteht kaum Anlass zur Sorge.

Verwandte Themen

• Bildschirm Sitzungen (Redis) — die Live-Konsole, die diese Konzepte anwendet
• Überwachung der Datenbanklast — der Datenbankmonitor mit derselben Erzählweise (Verbindungen, QPS, langsame Abfragen)
• Datenbank-Tuning-Konzepte (Schulung) — Sperren, Cache und Indizes auf Datenbankseite
• Betriebsrichtlinie — die redis_*-Schwellenwerte und den Reserveanteil bearbeiten
• Collectors — der redis_vts-Collector und die Knotenregistrierung
• Service-Übersicht — Sitzungskarten auf dem Board zusammenstellen