Teilen über

Problembehandlung bei Wartezeiten und Timeouts in Azure Cache for Redis

  • Gilt für: ✅ Azure Cache for Redis

Von Bedeutung

Azure Cache for Redis kündigte den Auslauftermin für alle SKUs an. Es wird empfohlen, Ihren vorhandenen Azure-Cache für Redis-Instanzen in Azure Managed Redis zu verschieben, sobald Möglich.

Weitere Informationen zur Einstellung finden Sie unter:

Ein Azure Cache für Redis-Clientvorgang, der keine zeitnahe Antwort erhält, kann zu einer hohen Latenz oder einem Timeout-Fehler führen. In diesem Artikel wird erläutert, wie Häufige Probleme behoben werden, die zu hoher Latenz und Timeouts führen können.

Bei einem Vorgang können Probleme oder Timeouts in verschiedenen Phasen auftreten. Die Quelle des Problems hilft dabei, die Ursache und die Gegenmaßnahme zu ermitteln. Dieser Artikel ist in clientseitige und serverseitige Probleme unterteilt.

Clientseitige Probleme

Serverseitige Probleme

Behandeln von clientseitigen Problemen

Die folgenden clientseitigen Probleme können sich auf Latenz und Leistung auswirken und zu Timeouts führen.

Clientverbindungen mit hoher Speicherauslastung

Clientanforderungen für Clientverbindungen, die über das Maximum für den Cache hinausgehen, können fehlschlagen. Clientverbindungen mit hoher Speicherauslastung können auch eine hohe Serverauslastung verursachen, wenn wiederholte Verbindungsversuche verarbeitet werden.

Clientverbindungen mit hoher Speicherauslastung können auf einen Verbindungsverlust im Clientcode hindeuten. Verbindungen werden möglicherweise nicht ordnungsgemäß wiederverwendet oder geschlossen. Überprüfen Sie den Clientcode für die Verbindungsverwendung.

Wenn die hohen Verbindungen alle legitimen und erforderlichen Clientverbindungen sind, müssen Sie ihren Cache möglicherweise auf eine Größe mit einem höheren Verbindungslimit aktualisieren. Überprüfen Sie, ob die Metrik Maximalwert für verbundene Clients nahe oder höher als die maximale Anzahl zulässiger Verbindungen für die Cachegröße ist. Weitere Informationen zur Anpassung der Größe pro Clientverbindung finden Sie unter Azure Cache for Redis – Leistung.

Hohe CPU-Auslastung auf Clienthosts

Hohe Client-CPU-Auslastung weist darauf hin, dass das System nicht mit der ihm zugewiesenen Arbeit schritthalten kann. Auch wenn der Cache die Antwort schnell sendet, kann der Client die Antwort nicht schnell genug verarbeiten. Es ist am besten, die Client-CPU bei weniger als 80%zu halten.

So mindern Sie eine hohe CPU-Auslastung beim Client

  • Untersuchen Sie die Ursache von CPU-Spitzen.
  • Führen Sie ein Upgrade Ihres Clients auf eine größere VM-Größe (Virtual Machine) mit mehr CPU-Kapazität durch.

Überwachen Sie die systemweite CPU-Auslastung des Clients mithilfe von Metriken, die im Azure-Portal oder über Leistungsindikatoren auf dem virtuellen Computer verfügbar sind. Überprüfen Sie die Metrikfehler (Typ: Nicht reagierendeClients), um festzustellen, ob Ihre Clienthosts Antworten vom Redis-Server rechtzeitig verarbeiten können.

Achten Sie darauf, die Prozess-CPU nicht zu überwachen, da ein einzelner Prozess eine niedrige CPU-Auslastung aufweisen kann, die systemweite CPU kann jedoch hoch sein. Beobachten Sie die Spitzen bei der CPU-Auslastung, denn sie korrespondieren mit Timeouts. Hohe CPU kann auch zu hohen in: XXX Werten in timeoutException Fehlermeldungen führen. Ein Beispiel finden Sie im Abschnitt „Traffic-Burst und Thread-Pool-Konfiguration“.

Ab StackExchange.Redis 1.1.603 ist in den local-cpu-Fehlermeldungen die Metrik timeoutException enthalten. Stellen Sie sicher, dass Sie die neueste Version des StackExchange.Redis NuGet-Pakets verwenden, da Fehler regelmäßig behoben werden, um den Code resistenter gegen Timeouts zu machen. Weitere Informationen finden Sie unter Untersuchen von timeout Ausnahmen in StackExchange.Redis.

Große Schlüsselwerte

Sie können den Befehl redis-cli --bigkeys verwenden, um im Cache nach großen Schlüsseln zu suchen. Weitere Informationen zu redis-cli, der Redis-Befehlszeilenschnittstelle, finden Sie unter Redis CLI.

Gehen Sie wie folgt vor, um das Problem zu beheben:

  • Erhöhen Sie die Größe Ihrer VM, um höhere Bandbreitenfunktionen zu erhalten. Mehr Bandbreite auf ihrer Client- oder Server-VM kann die Datenübertragungszeiten für größere Antworten verringern. Vergleichen Sie die aktuelle Netzwerknutzung auf beiden virtuellen Computern mit den Grenzwerten Ihrer aktuellen VM-Größen. Mehr Bandbreite nur auf dem Server oder Client reicht möglicherweise nicht aus.

  • Erhöhen Sie die Anzahl von Verbindungsobjekten, die Ihre Anwendung verwendet. Verwenden Sie einen Roundrobinansatz, um Anforderungen über verschiedene Verbindungsobjekte auszuführen. Informationen zur Verwendung mehrerer Schlüssel und kleinerer Werte finden Sie unter Informationen zur Verwendung mehrerer Schlüssel und kleinerer Werte finden Sie unter .

Hohe Arbeitsspeicherauslastung auf dem Redis-Client

Der Arbeitsspeicherdruck auf dem Client kann zu Leistungsproblemen führen, die die Verarbeitung von Cacheantworten verzögern. Wenn der Arbeitsspeicherdruck auftritt, kann das System Daten auf den Datenträger ausblättern. Diese sogenannten Seitenfehler bewirken eine deutliche Verlangsamung des Systems.

So erkennen sie hohe Speicherauslastung auf dem Client

  • Überwachen Sie die Speicherauslastung auf dem virtuellen Computer, um sicherzustellen, dass der verfügbare Arbeitsspeicher nicht überschritten wird.
  • Überwachen Sie den Leistungsindikator Page Faults/Sec des Clients. Während des normalen Betriebs kommt es auf den meisten Systeme zu ein paar Seitenfehlern. Auftretende Spitzen bei Seitenfehlern, die mit Anforderungstimeouts korrespondieren, können auf hohe Arbeitsspeicherauslastung hindeuten.

So verringern Sie hohen Arbeitsspeicherdruck auf dem Client:

  • Untersuchen Sie Ihre Speicherauslastungsmuster, um den Arbeitsspeicherverbrauch auf dem Client zu verringern.
  • Führen Sie ein Upgrade Ihrer Client-VM auf eine größere VM mit mehr Arbeitsspeicher aus.

Einschränkung der Netzwerkbandbreite auf Clienthosts

Je nach Architektur haben Clientcomputer möglicherweise Einschränkungen bei der Verfügbarkeit der Netzwerkbandbreite. Wenn der Client die verfügbare Bandbreite überschreitet, indem er die Netzwerkkapazität überlastet, werden die Daten auf der Client-Seite nicht so schnell verarbeitet, wie sie vom Server gesendet werden. Diese Situation kann zu Timeouts führen.

Verringern Sie zur Minderung den Netzwerkbandbreitenverbrauch, oder vergrößern Sie die Client-VM auf eine mit höherer Netzwerkkapazität. Weitere Informationen finden Sie unter Große Anforderungen oder große Antworten.

RedisSessionStateProvider retryTimeout

Stellen Sie bei der Verwendung von RedisSessionStateProvider sicher, dass Sie das retryTimeout richtig festlegen. Der Wert retryTimeoutInMilliseconds sollte höher sein als der Wert operationTimeoutInMilliseconds. Andernfalls werden keine Wiederholungsversuche ausgeführt.

Im folgenden Beispiel wird retryTimeoutInMilliseconds auf 3000 festgelegt.

<add 
    name="AFRedisCacheSessionStateProvider"
    type="Microsoft.Web.Redis.RedisSessionStateProvider"
    host="enbwcache.redis.cache.windows.net"
    port="6380"
    accessKey="..."
    ssl="true"
    databaseId="0"
    applicationName="AFRedisCacheSessionState"
    connectionTimeoutInMilliseconds = "5000"
    operationTimeoutInMilliseconds = "1000"
    retryTimeoutInMilliseconds="3000"
>

TCP-Einstellungen für Linux-basierte Clientanwendungen

Clientanwendungen, die unter Linux gehostet werden, können aufgrund optimistischer TCP-Einstellungen in Linux Konnektivitätsprobleme haben. Weitere Informationen finden Sie unter TCP-Einstellungen für von Linux gehostete Clientanwendungen.

Sprunghafter Anstieg des Datenverkehrsvolumen und Threadpoolkonfiguration

Ein sprunghafter Anstieg des Datenverkehrsvolumens in Verbindung mit unzureichenden ThreadPool-Einstellungen kann zu Verzögerungen beim Verarbeiten der vom Redis-Server bereits gesendeten, aber auf der Clientseite noch nicht genutzten Daten führen. Überprüfen Sie die Metrik "Fehler (Typ: Nicht reagierende Clients)", um zu überprüfen, ob Ihre Client-Hosts plötzliche Verkehrsspitzen verkraften können. Sie können Ihre ThreadPool-Einstellungen konfigurieren, um sicherzustellen, dass der Threadpool in Belastungsszenarien schnell skaliert.

Sie können timeoutException Nachrichten von StackExchange.Redis verwenden, um weitere Informationen zu untersuchen.

    System.timeoutException: timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
    IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)

Die vorherige Ausnahme zeigt mehrere Probleme.

  • Im IOCP Abschnitt und im WORKER Abschnitt ist der Busy Wert größer als der Min Wert, was bedeutet, dass die ThreadPool Einstellungen angepasst werden müssen.
  • Der Wert in: 64221 gibt an, dass 64.221 Bytes auf der Kernel-Socketebene des Clients empfangen wurden, aber nicht von der Anwendung gelesen wurden. Dieser Unterschied bedeutet in der Regel, dass Ihre Anwendung, z. B. StackExchange.Redis, keine Daten aus dem Netzwerk so schnell liest, wie der Server sie sendet.

Ab StackExchange.Redis 1.1.603 ist in den local-cpu-Fehlermeldungen die Metrik timeoutException enthalten. Stellen Sie sicher, dass Sie die neueste Version des StackExchange.Redis NuGet-Pakets verwenden, da Fehler regelmäßig behoben werden, um den Code resistenter gegen Timeouts zu machen. Weitere Informationen finden Sie unter Untersuchung von Timeout-Exceptions in StackExchange.Redis.

Serverseitige Problembehandlung

Die folgenden serverseitigen Probleme können sich auf die Leistung auswirken und zu Timeouts führen.

Hohe Speicherauslastung

Der Arbeitsspeicherdruck auf dem Server kann zu verschiedenen Leistungsproblemen führen, die die Verarbeitung von Anforderungen verzögern. Bei Speicherdruck lagert das System die Daten auf die Festplatte aus, wodurch sich das System erheblich verlangsamt.

Einige mögliche Ursachen des Arbeitsspeicherdrucks sind, dass der Cache mit Daten gefüllt wird, um seine maximale Kapazität zu erreichen, oder dass der Redis-Server eine hohe Speicherfragmentierung aufweist.

Fragmentierung ist wahrscheinlich, wenn ein Lademuster Daten mit hoher Größenvariation speichert, z. B. wenn Daten auf 1 KB und 1 MB verteilt sind. Wenn ein 1-KB-Schlüssel aus vorhandenem Arbeitsspeicher gelöscht wird, kann ein 1-MB-Schlüssel nicht in den Speicherplatz passen, was zu Einer Fragmentierung führt. Ebenso kann ein hinzugefügter 1,5-MB-Schlüssel nicht in den vorhandenen zurückgewonnenen Speicher passen, wenn der 1-MB-Schlüssel gelöscht wird. Dieser nicht verwendete freie Arbeitsspeicher führt zu Fragmentierung.

Wenn ein Cache fragmentiert ist und unter hohem Arbeitsspeicherdruck ausgeführt wird, führt das System ein Failover durch, um den Rss-Speicher (Resident Set Size) wiederherzustellen. Redis macht zwei Statistiken verfügbar, used_memory und used_memory_rssüber den BEFEHL INFO , der Ihnen dabei helfen kann, dieses Problem zu identifizieren. Sie können diese Metriken auch im Azure-Portal anzeigen.

Wenn der Wert used_memory_rss größer als das 1,5-Fache der Metrik used_memory ist, tritt im Arbeitsspeicher eine Fragmentierung auf. Die Fragmentierung kann in folgenden Fällen Probleme verursachen:

  • Die Speicherauslastung liegt in der Nähe des maximalen Speicherlimits für den Cache.
  • Die used_memory_rss Metrik ist höher als die maximale Speichergrenze, was möglicherweise zu Seitenfehlern im Arbeitsspeicher führt.

Sie können mehrere Aktionen ausführen, um die Speicherauslastung fehlerfrei zu halten.

Weitere Empfehlungen zur Speicherverwaltung finden Sie unter Bewährte Methoden für die Speicherverwaltung.

Hohe Serverauslastung

Hohe Serverlast bedeutet, dass der Redis-Server ausgelastet ist und nicht mit Anforderungen in Verbindung bleiben kann, was zu Timeouts oder langsamen Antworten führt. Um die hohe Serverlast zu verringern, untersuchen Sie zunächst die Ursache, z. B. lange ausgeführte Befehle aufgrund eines hohen Arbeitsspeicherdrucks.

Sie können Metriken wie die Serverlast aus dem Azure-Portal überwachen. Um die Metrik "Serverlast " zu überprüfen, wählen Sie "Insights " unter "Überwachung " im linken Navigationsmenü auf Der Cacheseite aus, und zeigen Sie das Diagramm " Serverlast " an. Oder wählen Sie "Metriken" unter "Überwachung" im linken Navigationsmenü und dann unter "Metriken" die Option "Serverlast" aus.

Achten Sie auf Spitzen bei der Auslastung des Servers, die mit Zeitüberschreitungen einhergehen. Erstellen Sie Warnungen für Serverlademetriken, um frühzeitig über potenzielle Auswirkungen benachrichtigt zu werden.

Spitzen in der Serverlast

Bei C0- und C1-Caches werden möglicherweise kurze Spitzen bei der Serverlast angezeigt, die nicht durch eine Zunahme der Anforderungen verursacht werden, während die interne Defender-Überprüfung auf den virtuellen Computern ausgeführt wird. Auf diesen Stufen führt die Durchführung interner Defender-Scans zu einer höheren Latenz bei Anfragen.

Caches auf den C0- und C1-Stufen haben nur einen einzigen Kern für Multitasking, wobei die Arbeit zwischen internen Defender-Scan- und Redis-Anfragen aufgeteilt wird. Wenn die zusätzliche Latenz durch interne Defender-Scans Ihre Produktionsauslastung in einem C1-Cache negativ beeinflusst, können Sie auf eine höhere Stufe mit mehreren CPU-Kernen skalieren, z. B. C2. Weitere Informationen finden Sie unter Auswahl der richtigen Stufe.

Weitere Informationen zu schnellen Änderungen der Anzahl von Clientverbindungen finden Sie unter Vermeiden von Clientverbindungsspitzen.

Skalierung

Sie können auf mehr Shards aufskalieren, um die Last auf mehrere Redis-Prozesse zu verteilen, oder Sie skalieren auf einen größeren Cache mit mehr CPU-Kernen hoch. Skalierungsvorgänge sind cpu- und arbeitsspeicherintensiv, da sie das Verschieben von Daten um Knoten und das Ändern der Clustertopologie umfassen können. Weitere Informationen finden Sie unter Azure Cache for Redis Planning FAQs und Skalierung.

Zeitintensive Befehle

Einige Redis-Befehle sind aufwendiger auszuführen als andere. Die Redis Commands-Dokumentation zeigt die Zeitkomplexität der einzelnen Befehle. Die Redis-Befehlsverarbeitung ist auf einen Thread beschränkt. Jeder Befehl, der lange zur Ausführung benötigt, kann nachfolgende Befehle blockieren.

Überprüfen Sie die Befehle, die Sie auf Ihrem Redis-Server ausgeben, um deren Leistungseinbußen zu verstehen. Beispielsweise wird der Befehl KEYS häufig ohne das Wissen verwendet, dass es sich um einen O(N)-Vorgang (Big O Notation) handelt. Um CPU-Spitzen zu reduzieren, können Sie KEYS vermeiden, indem Sie SCAN verwenden.

Sie können die folgenden Redis-Befehle in einer Konsole ausführen, um lang andauernde und rechenintensive Befehle zu untersuchen.

  • CLIENTLISTE

    Der CLIENT LIST Befehl gibt Informationen und Statistiken über den Clientverbindungsserver in einem meist lesbaren Format zurück.

  • INFORMATIONEN

    Der INFO Befehl gibt Informationen und Statistiken über den Server in einem Format zurück, das für Computer einfach zu analysieren und einfach zu lesen ist. Der CPU Abschnitt kann hilfreich sein, um die CPU-Auslastung zu untersuchen. Ein server_load von 100 (Maximalwert) bedeutet, dass der Redis-Server ständig beschäftigt war und beim Verarbeiten der Anforderungen nie im Leerlauf war.

    Das folgende Beispiel zeigt eine Ausgabe des INFO Befehls:

    # CPU
used_cpu_sys:530.70
used_cpu_user:445.09
used_cpu_avg_ms_per_sec:0
server_load:0.01
event_wait:1
event_no_wait:1
event_wait_count:10
event_no_wait_count:1

  • MONITOR

    MONITOR ist ein Debugbefehl, der jeden vom Redis-Server verarbeiteten Befehl zurückstreamt. MONITOR kann Ihnen helfen, zu verstehen, was mit der Datenbank passiert. Dieser Befehl ist anspruchsvoll und kann sich negativ auf die Leistung auswirken und beeinträchtigen.

  • SLOWLOG

    Das Redis-Protokoll für langsame Abfragen ist ein System zum Protokollieren von Abfragen, die eine bestimmte Ausführungszeit überschritten haben. Die Ausführungszeit umfasst keine E/A-Vorgänge wie das Sprechen mit dem Client oder das Senden der Antwort, sondern nur die Zeit, die erforderlich ist, um den Befehl tatsächlich auszuführen.

    Der Befehl SLOWLOG liest das Protokoll für langsame Redis-Abfragen und setzt es zurück und kann auch verwendet werden, um zeitintensive Befehle auf der Clientseite zu untersuchen. Sie können teure Befehle überwachen und protokollieren, die mit SLOWLOG GET auf dem Redis-Server ausgeführt werden.

Einschränkung der Netzwerkbandbreite

Verschiedene Cachegrößen verfügen über unterschiedliche Netzwerkbandbreitenkapazitäten. Wenn der Server die verfügbare Bandbreite überschreitet, werden Daten nicht so schnell an den Client gesendet. Bei Anforderungen von Clients kann es zu Timeouts kommen, weil der Server die Daten nicht schnell genug an den Client übertragen kann.

Sie können Metriken wie Cachelese- und Cacheschreibzugriff im Azure-Portal überwachen, um zu sehen, wie viel serverseitige Bandbreite verwendet wird. Erstellen Sie Warnungen zu diesen Metriken , um frühzeitig über potenzielle Auswirkungen benachrichtigt zu werden.

So mindern Sie Situationen, in denen der Netzwerkbandbreitenverbrauch am Rande der maximalen Kapazität liegt

Serverwartung

Eine geplante oder ungeplante Wartung kann zu Unterbrechungen bei Clientverbindungen führen. Anzahl und Typ der Ausnahmen hängen davon ab, an welcher Stelle im Codepfad sich die Anforderung befindet, und wann der Cache seine Verbindungen schließt.

Wenn ihr Azure Cache for Redis einem Failover unterzogen wird, werden alle Clientverbindungen vom Knoten, der ausgefallen ist, an den Knoten übertragen, der noch ausgeführt wird. Bei der Serverauslastung können aufgrund der höheren Verbindungsanzahl Spitzen auftreten. Sie können versuchen, Ihre Clientanwendungen neu zu starten, damit alle Clientverbindungen neu erstellt und auf die beiden Knoten verteilt werden.

Ein Vorgang, der eine Anforderung sendet, aber keine Antwort empfängt, wenn das Failover auftritt, kann eine timeout Ausnahme erhalten. Bei neuen Anforderungen für das geschlossene Verbindungsobjekt treten Verbindungsausnahmen auf, bis die Verbindung erfolgreich wiederhergestellt wird.

Überprüfen Sie die timeout, um zu überprüfen, ob Ihr Azure Cache for Redis während des Auftretens Ihrer-Ausnahmen ein Failover hatte. Wählen Sie auf der Azure-Portalseite für Ihren Cache im linken Navigationsmenü "Metriken " unter "Überwachung " aus. Erstellen Sie dann ein neues Diagramm, das die Fehlermetrik misst, geteilt durch ErrorType. Nachdem Sie dieses Diagramm erstellt haben, wird eine Anzahl für Failover angezeigt. Weitere Informationen zu Failovern finden Sie unter Failover und Patching für Azure Cache for Redis.

Weitere Informationen zum Verringern von Problemen aufgrund der Serverwartung finden Sie in den folgenden Artikeln:

Verwandte Inhalte

  • Last updated on