Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird erläutert, wie Sie die Auslastung eines Azure Verwalteten Redis-Caches verwenden und überwachen.
Wertgrößen
Der Entwurf Ihrer Clientanwendung bestimmt, ob Sie viele kleine Werte oder eine kleinere Anzahl größerer Werte speichern sollten. In Bezug auf den Redis-Server führen kleinere Werte zu einer besseren Leistung. Es wird empfohlen, die Wertgröße kleiner als 100 kB zu halten.
Wenn Ihr Design erfordert, dass Sie größere Werte in den Azure verwalteten Redis speichern müssen, ist die Serverlast höher. In diesem Fall müssen Sie möglicherweise eine höhere Cacheebene verwenden, um sicherzustellen, dass die CPU-Auslastung den Durchsatz nicht einschränkt.
Auch wenn der Cache über eine ausreichende CPU-Kapazität verfügt, erhöhen größere Werte die Latenz. Befolgen Sie daher die Anleitung unter Konfigurieren geeigneter Timeouts.
Vermeiden Sie Spitzen bei Clientverbindungen
Das Erstellen und Schließen von Verbindungen ist ein aufwendiger Vorgang für Redis-Server. Wenn Ihre Clientanwendung innerhalb einer kurzen Zeit zu viele Verbindungen erstellt oder schließt, kann dies den Redis-Server belasten.
Wenn Sie viele Clientinstanzen instanziieren, um gleichzeitig eine Verbindung mit Redis herzustellen, sollten Sie erwägen, die neuen Verbindungserstellungen zeitlich versetzt zu gestalten, um einen steilen Anstieg bei der Anzahl verbundener Clientzahlen zu vermeiden.
Arbeitsspeicherauslastung
Eine hohe Arbeitsspeicherauslastung auf dem Server erhöht die Wahrscheinlichkeit, dass das System Daten auf den Datenträger weitergeben muss. Dies führt zu Seitenfehlern, die das System erheblich verlangsamen können.
Vermeiden von zeitintensiven Befehlen
Der Redis-Server ist ein Single-Thread-Prozess. Befehle mit einer zeitintensiven Ausführungszeit können zu Wartezeiten oder Timeouts auf der clientseitigen Seite führen. Der Grund dafür ist, dass der Server nicht auf andere Anforderungen reagieren kann, während er mit einem Befehl mit einer langer Ausführungszeit beschäftigt ist. Weitere Informationen finden Sie unter Fehlerbehebung bei serverseitigen Problemen mit Azure Cache for Redis.
Überwachen der Serverlast und CPU
Fügen Sie die Überwachung auf Serverlast und CPU hinzu, um sicherzustellen, dass Sie Benachrichtigungen erhalten, wenn einer davon hoch ist. Die Überwachung kann Ihnen helfen, Ihre Anwendungseinschränkungen zu verstehen. Anschließend können Sie proaktiv an der Entschärfung von Problemen arbeiten. Es wird empfohlen, die Serverauslastung unter 80 % zu halten, um negative Leistungseffekte zu vermeiden. Eine anhaltende Serverauslastung von über 80 % kann zu ungeplanten Failovern führen. Derzeit stellt Azure Managed Redis zwei Metriken in Insights unter Monitoring im Ressourcenmenü links im Portal bereit: CPU und Serverlast. Das Verständnis, was von den einzelnen Metriken gemessen wird, ist wichtig, wenn sie überwacht werden.
Die CPU-Metrik (a.k.a. percentProcessorTime) gibt die CPU-Auslastung für den Knoten an, der den Cache hostet. Die CPU-Metrik umfasst auch Prozesse, die keine strengen Redis-Serverprozesse sind. Die CPU umfasst Hintergrundprozesse für Antischadsoftware und andere. Daher kann die CPU-Metrik manchmal ansteigen und ist möglicherweise nicht immer ein verlässlicher Indikator für die CPU-Auslastung des Redis-Servers.
Die Metrik "Serverlast " spiegelt die eigene Bewertung der Gesamtlast des Redis-Servers wider und ähnelt der CPU-Metrik, aber auf Clusterebene.
Empfehlungen für kleinere SKUs
Bei Azure verwalteten Redis-SKUs, die von 2-vCPU-VMs (B0–B5, X3 und M10) unterstützt werden, sind prozentuale Metriken wie Server Load und CPU von Natur aus empfindlicher. Ein einzelner kurzlebiger Hintergrund-Thread kann einen erheblichen Prozentsatz der Gesamt-CPU verbrauchen, sodass die Metriken erhöht erscheinen, selbst wenn die tatsächliche Workload gering ist. Daher können diese Metriken die tatsächliche Last für kleine SKUs überschätzen und möglicherweise keine Workloadsättigung angeben.
Beim Überprüfen von Metriken über längere Zeiträume, z. B. mehrere Stunden oder Tage, empfehlen wir Folgendes:
- Verwenden der CPU anstelle der Serverlast , da sie auf Instanzebene angezeigt werden kann, wodurch eine genauere Granularität hinzugefügt wird
- Aufteilung nach Instanz-ID der virtuellen Maschinen, die die Azure Managed Redis-Instanz unterstützen
- Verwenden der durchschnittlichen Aggregation anstelle von "Maximum " für diese längeren Zeitbereiche
Sie können die maximale Aggregation über kurze Zeitfenster weiterhin verwenden, um kurze Spitzen oder Ereignisse abzufangen (z. B. solche, die Timeouts oder Failovers verursachen können), während Sie sich auf "Mittelwert " über längere Fenster für die Trendanalyse für kleine SKUs verlassen, insbesondere bei Verwendung der CPU.
Testen auf erhöhte Serverauslastung nach einem Failover
Bei Standard- und Premium-SKUs wird jeder Cache auf zwei Knoten gehostet. Die Clientverbindungen werden mit dem Load Balancer auf die beiden Knoten verteilt. Bei einer geplanten oder ungeplanten Wartung auf dem primären Knoten schließt der Knoten alle Clientverbindungen. In solchen Situationen können alle Clientverbindungen auf einem einzelnen Knoten landen, was zu einer erhöhten Serverauslastung auf dem verbleibenden Knoten führt. Es wird empfohlen, dieses Szenario zu testen. Starten Sie hierfür den primären Knoten neu, und vergewissern Sie sich, dass ein Knoten alle Clientverbindungen verarbeiten kann, ohne dass die Serverauslastung zu hoch wird.