Problembehandlung bei Timeouts bei Azure Cache for Redis

  • Artikel

Ein Clientvorgang, der keine zeitnahe Antwort empfängt, kann zu einer Wartezeit- oder Timeoutausnahme führen. Für einen Vorgang kann in verschiedenen Phasen ein Timeout auftreten. Die Information, in welcher Phase das Timeout auftritt, hilft bei der Ermittlung der Ursache und bei der Entschärfung.

In diesem Abschnitt wird die Problembehandlung bei Wartezeit- und Timeoutproblemen erläutert, die beim Herstellen einer Verbindung mit Azure Cache for Redis auftreten.

Hinweis

Etliche Problembehandlungsschritte in diesem Leitfaden enthalten Anleitungen zum Ausführen von Redis-Befehlen und zum Überwachen verschiedener Leistungsmetriken. Weitere Informationen und Anleitungen finden Sie in den Artikeln im Abschnitt Weitere Informationen .

Behandeln von clientseitigen Problemen

Hier ist die clientseitige Problembehandlung.

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 anhand der Metrik „Fehler“ (Typ: UnresponsiveClients), ob Ihre Clienthosts mit einer plötzlichen Datenverkehrsspitze Schritt halten können.

Überwachen Sie die Änderungen bei den ThreadPool-Statistiken im zeitlichen Verlauf unter Verwendung eines Beispiel-ThreadPoolLogger-. Sie können TimeoutException-Meldungen von StackExchange.Redis verwenden, um weitere Untersuchungen anzustellen:

    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)

In der oben aufgeführten Ausnahme zeigen sich mehrere interessante Probleme:

  • Beachten Sie, dass in den Abschnitten IOCP und WORKER der Busy-Wert größer als der Min-Wert ist. Dieser Unterschied bedeutet, dass die ThreadPool-Einstellungen angepasst werden müssen.
  • Außerdem wird in: 64221 angegeben. Dieser Wert gibt an, dass 64.221 Bytes auf der Kernel-Socketebene des Clients empfangen, aber nicht von der Anwendung gelesen wurden. Dieser Unterschied bedeutet in der Regel, dass Ihre Anwendung (z. B. StackExchange.Redis) Daten aus dem Netzwerk nicht so schnell liest, wie sie vom Server gesendet werden.

Sie können Ihre ThreadPool-Einstellungen konfigurieren, um sicherzustellen, dass Ihr Threadpool bei Datenverkehrsspitzen schnell hochskaliert wird.

Großer Schlüsselwert

Informationen zur Verwendung mehrerer Schlüssel und kleinerer Werte finden Sie unter Informationen zur Verwendung mehrerer Schlüssel und kleinerer Werte finden Sie unter .

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

  • Erhöhen Sie die Größe Ihres virtuellen Computers, um höhere Bandbreitenkapazitäten zu erhalten.
    • Mehr Bandbreite auf ihrer Client- oder Server-VM kann die Datenübertragungszeiten für größere Antworten verringern.
    • Vergleichen Sie Ihre aktuelle Netzwerknutzung auf beiden Computern mit den Limits Ihrer aktuellen VM-Größe. Mehr Bandbreite nur auf dem Server oder nur auf dem Client ist möglicherweise nicht ausreichend.
  • Erhöhen Sie die Anzahl von Verbindungsobjekten, die Ihre Anwendung verwendet.
    • Verwenden Sie einen Roundrobinansatz, um Anforderungen über verschiedene Verbindungsobjekte auszuführen.

Hohe CPU-Auslastung auf Clienthosts

Hohe Client-CPU-Auslastung gibt an, dass das System nicht mit der ihm zugewiesenen Arbeit schritthalten kann. Obgleich der Client die Antwort schnell gesendet hat, schafft es der Client eventuell nicht, die Antwort rechtzeitig zu verarbeiten. Die Auslastung der Client-CPU sollte 80 Prozent nicht übersteigen. Überprüfen Sie anhand der Metrik „Fehler“ (Typ: UnresponsiveClients), ob Ihre Clienthosts Antworten des Redis-Servers rechtzeitig verarbeiten können.

Überwachen Sie die systemweite CPU-Auslastung des Clients mithilfe der im Azure-Portal zur Verfügung stehenden Metriken oder mithilfe von Leistungsindikatoren auf dem Computer. Achten Sie darauf, dass Sie nicht die Prozess-CPU überwachen. Für einen einzelnen Prozess kann die CPU-Auslastung gering sein, während aber die systemweite CPU-Auslastung hoch sein kann. Beobachten Sie die Spitzen bei der CPU-Auslastung, denn sie korrespondieren mit Timeouts. Eine hohe CPU-Auslastung kann auch hohe Werte für in: XXX in den TimeoutException-Fehlermeldungen verursachen, wie im Abschnitt [Sprunghafter Anstieg des Datenverkehrsvolumens] beschrieben.

Hinweis

Ab StackExchange.Redis 1.1.603 ist in den TimeoutException-Fehlermeldungen die Metrik local-cpu enthalten. Verwenden Sie immer die neueste Version des NuGet-Pakets für StackExchange.Redis. Fehler im Code werden regelmäßig behoben, um es stabiler hinsichtlich Timeouts zu machen. Es ist wichtig, die aktuelle Version zu haben.

So mindern Sie eine hohe CPU-Auslastung beim Client

  • Untersuchen Sie, was CPU-Spitzen verursacht.
  • Führen Sie ein Upgrade Ihres Clients auf eine größere VM mit höherer CPU-Kapazität aus.

Einschränkung der Netzwerkbandbreite auf Clienthosts

Je nach Architektur der Clientcomputer bestehen möglicherweise Einschränkungen im Hinblick auf die verfügbare Netzwerkbandbreite. Wenn auf dem Client durch Überladen der Netzwerkkapazität die verfügbare Bandbreite überschritten wird, werden die Daten auf der Clientseite nicht so schnell verarbeitet, wie sie vom Server gesendet werden. Diese Situation kann zu Timeouts führen.

Überwachen Sie die Änderungen bei der Bandbreitennutzung im zeitlichen Verlauf unter Verwendung eines Beispiel-BandwidthLogger. Dieser Code wird in einigen Umgebungen mit eingeschränkten Berechtigungen (z.B. Azure-Websites) möglicherweise nicht erfolgreich ausgeführt.

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.

TCP-Einstellungen für Linux-basierte Clientanwendungen

Aufgrund optimistischer TCP-Einstellungen unter Linux können bei Clientanwendungen, die unter Linux gehostet werden, Konnektivitätsprobleme auftreten. Weitere Informationen finden Sie unter TCP-Einstellungen für unter Linux gehostete Clientanwendungen.

RedisSessionStateProvider-Wiederholungstimeout

Wenn Sie RedisSessionStateProvider verwenden, müssen Sie das Timeout für Wiederholungsversuche richtig festlegen. Der Wert retryTimeoutInMilliseconds sollte höher sein als der Wert operationTimeoutInMilliseconds. Andernfalls werden keine Wiederholungsversuche ausgeführt. Im folgenden Beispiel ist retryTimeoutInMilliseconds auf 3000 festgelegt. Weitere Informationen finden Sie unter ASP.NET-Sitzungszustandsanbieter für Azure Cache for Redis und How to use configuration parameters of Session State Provider and Output Cache Provider (Verwenden der Konfigurationsparameter des Sitzungszustandsanbieters und des Ausgabecacheanbieters).

<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"
>

Serverseitige Problembehandlung

Hier ist die serverseitige Problembehandlung.

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, wenn der Cache die Verbindungen schließt. Beispielsweise tritt bei einem Vorgang, bei dem eine Anforderung gesendet wird, für die zum Zeitpunkt des Failovers jedoch noch keine Antwort zurückgegeben wurde, möglicherweise eine Timeoutausnahme auf. Bei neuen Anforderungen für das geschlossene Verbindungsobjekt treten Verbindungsausnahmen auf, bis die Verbindung erfolgreich wiederhergestellt wird.

Weitere Informationen finden Sie in den folgenden Abschnitten:

Überprüfen Sie anhand der Metrik Fehler, ob für Ihre Azure Cache for Redis-Instanz während der Timeouts ein Failover ausgeführt wurde. Wählen Sie im Azure-Portal im Ressourcenmenü die Option Metriken aus. Erstellen Sie dann ein neues Diagramm zum Messen der Metrik Errors, aufgeteilt nach 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.

Hohe Serverauslastung

Eine hohe Serverauslastung bedeutet, dass der Redis-Server mit Anforderungen nicht Schritt halten kann, was zu Timeouts führt. Der Server weist möglicherweise langsame Reaktionszeiten auf und kann mit den Anforderungsraten nicht Schritt halten.

Überwachen Sie Metriken wie Serverauslastung. Beobachten Sie die Spitzen bei der Server Load-Auslastung, denn sie korrespondieren mit Timeouts. Erstellen Sie Warnungen für Metriken wie Serverauslastung, um frühzeitig über mögliche Beeinträchtigungen benachrichtigt zu werden.

Sie können mehrere Änderungen vornehmen, um hohe Serverauslastung zu mindern:

  • Untersuchen Sie, was eine hohe Serverauslastung verursacht, z. B. zeitintensive Befehle aufgrund hoher Arbeitsspeicherauslastung (siehe weiter unten).
  • Skalieren Sie auf mehr Shards auf, um die Last auf mehrere Redis-Prozesse zu verteilen, oder skalieren Sie auf einen größeren Cache mit mehr CPU-Kernen hoch. Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Planung für Azure Cache for Redis.
  • Wenn Ihre Produktionsworkload in einem C1-Cache negativ von einer zusätzlichen Latenz durch interne Defender-Scans beeinflusst wird, können Sie den Effekt reduzieren, indem Sie auf ein Angebot höherer Ebene mit mehreren CPU-Kernen wie C2 skalieren.

Spitzen in der Serverlast

In C0- und C1-Caches werden möglicherweise kurze Spitzen bei der Serverlast angezeigt, die nicht durch eine Zunahme der Anforderungen einige Male pro Tag verursacht werden, während der interne Defender-Scan auf den VMs ausgeführt wird. Es wird eine höhere Latenz für Anforderungen angezeigt, während die internen Defender-Scans auf diesen Ebenen stattfinden. Caches auf den Ebenen C0 und C1Ebenen weisen nur einen einzigen Kern für Multitasking auf und teilen die Arbeit der Bereitstellung von internen Defender-Scans und Redis-Anforderungen auf.

Hohe Speicherauslastung

Dieser Abschnitt wurde verschoben. Weitere Informationen finden Sie unter Hohe Speicherauslastung.

Zeitintensive Befehle

Einige Redis-Befehle sind aufwendiger auszuführen als andere. In der Dokumentation zu den Redis-Befehlen wird die Zeitkomplexität jedes einzelnen Befehls angegeben. Die Redis-Befehlsverarbeitung ist auf einen Thread beschränkt. Jeder Befehl, dessen Ausführung lange dauert, kann alle nachfolgenden Befehle blockieren.

Überprüfen Sie die Befehle, die Sie an Ihren Redis-Server ausgeben, um die Auswirkungen auf die Leistung besser zu verstehen. Beispielsweise wird der Befehl KEYS häufig verwendet, ohne zu wissen, dass es sich um einen O(N)-Vorgang handelt. Sie können KEYSA vermeiden, indem Sie SCAN verwenden, um CPU-Spitzen zu verringern.

Mit dem Befehl SLOWLOG GET können Sie speicherintensive Befehle messen, die auf dem Server ausgeführt werden.

Kunden können diese Redis-Befehle über eine Konsole ausführen, um zeit- und speicherintensive Befehle zu untersuchen.

  • SLOWLOG wird zum Lesen und Zurücksetzen des Redis-Protokolls für langsame Abfragen verwendet. Der Befehl kann auch für die Untersuchung zeitintensiver Befehle auf der Clientseite verwendet werden. 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 Kommunikation mit dem Client, Senden der Antwort usw., sondern nur die Zeit, die für die tatsächliche Ausführung des Befehls erforderlich ist. Mithilfe des Befehls SLOWLOG können Kunden speicherintensive Befehle messen/protokollieren, die auf dem Redis-Server ausgeführt werden.
  • MONITOR ist ein Debugbefehl, der jeden vom Redis-Server verarbeiteten Befehl zurückstreamt. Mit diesem Befehl können Sie nachvollziehen, was mit der Datenbank geschieht. Dieser Befehl ist speicherintensiv und kann sich negativ auf die Leistung auswirken. Er kann die Leistung beeinträchtigen.
  • INFO: Mit diesem Befehl werden Informationen und Statistiken zum Server in einem Format zurückgegeben, das von Computern einfach analysiert und von Menschen leicht gelesen werden kann. In diesem Fall kann der Abschnitt „CPU“ nützlich bei der Untersuchung der CPU-Auslastung sein. Eine Serverlast von 100 (Maximalwert) zeigt an, dass der Redis-Server immer ausgelastet war und beim Verarbeiten der Anforderungen nie im Leerlauf war.

Ausgabebeispiel:

# 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
  • CLIENT LIST: Gibt Informationen und Statistiken zum Clientverbindungsserver in einem hauptsächlich für Menschen lesbaren Format zurück.

Einschränkung der Netzwerkbandbreite

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

Die Metriken „Cache Read“ (Cachelesevorgänge) und „Cache Write“ (Cacheschreibvorgänge) können verwendet werden, um festzustellen, wie viel Bandbreite auf der Serverseite verwendet wird. Sie können diese Metriken im Portal anzeigen. Erstellen Sie Warnungen bei Metriken wie „Cache Read“ oder „Cache Write“, um frühzeitig über mögliche Beeinträchtigungen benachrichtigt zu werden.

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

StackExchange.Redis-Timeoutausnahmen

Spezifischere Informationen zum Behandeln von Timeouts bei Verwendung von „StackExchange.Redis“ finden Sie unter Untersuchen von Timeoutausnahmen in StackExchange.Redis für Azure Redis Cache.

Zugehöriger Inhalt