Warum besteht ein Speicherungleichgewicht zwischen den Shards in meinem selbstverwalteten ElastiCache für Valkey- oder ElastiCache für Redis OSS-Cluster?

Kurzbeschreibung

Standardmäßig versuchen Valkey- und Redis OSS-Cluster mit aktiviertem Cluster-Modus, den Cache-Schlüsselraum gleichmäßig auf die Shards in einem Cluster zu verteilen. Weitere Informationen findest du unter So arbeitest du mit dem Cluster-Modus auf Amazon ElastiCache für Redis.

Die folgenden Gründe können zu einer ungleichmäßigen Speicherauslastung führen, die dazu führt, dass einige Shards mehr Daten speichern als andere:

• Ungleichmäßige Schlüsselverteilung
• Zu große Schlüssel
• Hotkeys oder Shards
• Ungleichmäßige Verwendung von Hashtags
• Erhöhte Client-Ausgabepuffer

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version von AWS CLI verwendest.

Ungleichmäßige Schlüsselverteilung

Wenn du die Hash-Slots nicht gleichmäßig auf die Shards verteilst, verarbeiten einige Shards möglicherweise mehr Schlüssel als andere. Um dieses Problem zu beheben, verteile die Slots im Cluster neu.

Hinweis: Die Option Slot-Neugewichtung versucht, die 16 384 Hash-Slots gleichmäßig auf die verfügbaren Shards zu verteilen. Bei dieser Option erfolgt keine Neugewichtung auf der Grundlage der Speicherauslastung oder des Datenvolumens in jedem Shard.

Einige Schlüssel sind zu groß

Wenn einige Schlüssel viel größer sind als andere, wird für die Shards, die diese Schlüssel hosten, möglicherweise eine höhere Speicherauslastung festgestellt. Um dieses Problem zu lösen, kannst du große Schlüssel in kleinere Schlüssel-Wert-Paare aufteilen. Oder entferne unnötig große Schlüssel, um Speicherplatz freizugeben.

Um den Datensatz nach großen Schlüsseln zu durchsuchen, verwende den Befehl valkey-cli--bigkeys oder valkey-cli --memkeys. Weitere Informationen findest du unter Scannen nach großen Schlüsseln auf der Valkey-Website.

Es hat sich bewährt, effiziente Strategien zur Benennung von Schlüsseln, Datenstrukturen und Komprimierungstechniken zu verwenden, um die Speicherauslastung der Schlüssel zu optimieren.

Hotkeys oder Shards

Wenn du häufiger auf einige Schlüssel zugreifst als auf andere, verteilt sich die Last ungleichmäßig und belastet die Speicherauslastung des Server-Hosts. Die Schlüssel, auf die häufiger zugegriffen wird, werden als Hotkeys oder Hot Shards bezeichnet.

Um Hotkeys zu finden, führe den Befehl valkey-cli --hotkeys aus, um die Muster für Schlüsselzugriffe zu überprüfen und die Schlüssel zu identifizieren. In einigen Fällen kann ein einziger Hotcache-Schlüssel einen Hotspot erzeugen, der den Cache-Knoten überfordert. Der Hotspot kann sich auf die CPU-, Speicher- und Netzwerkressourcen des Knotens auswirken.

Hinweis: Der Befehl hotkeys funktioniert nur, wenn die maxmemory-policy auf *lfu gesetzt ist.

Gehe wie folgt vor, um dieses Problem zu beheben:

• Skaliere vertikal den Cluster und stelle mehr Ressourcen bereit.
• Verteilen den Lesetraffic auf Lesereplikate. Weitere Informationen findest du unter READONLY auf der Valkey-Website.
• Ändere die Client-Anwendung, um das Volumen der Schreibvorgänge auf die Schlüssel zu reduzieren.

Ungleichmäßige Verwendung von Hashtags

In einer Umgebung mit aktiviertem Cluster-Modus musst du Hashtags verwenden, um Mehrschlüsseloperationen in einem Valkey-Cluster zu implementieren. Wenn du die Verwendung von Hashtags erhöhst, speichern einige Hash-Slots mehr Schlüssel als andere und es kommt zu einem Speicherungleichgewicht zwischen den Shards.

Um dieses Problem zu beheben, überprüfe den Schlüsselraum und die Verwendung von Hashtags und verteile die Daten auf mehrere Hash-Slots. Weitere Informationen findest du im Abschnitt Hashtags unter Cluster-Spezifikation auf der Valkey-Website.

Erhöhte Client-Ausgabepuffer

Wenn die Befehle eines Clients eine schnellere Ausgabe erzeugen, als Valkey an den Client senden kann, wächst der Client-Ausgabepuffer und verbraucht mehr Speicher. Weitere Informationen findest du auf der Valkey-Website unter Grenzwerte für Ausgabepuffer.

Um die Ursache von Problemen mit dem Puffer zu ermitteln, stelle eine Verbindung zum betroffenen Knoten her und führe den Befehl CLIENT LIST aus, um Clients zu identifizieren, die Pufferspeicher verwenden. Weitere Informationen findest du unter CLIENT LIST auf der Valkey-Website.

Überprüfe die folgenden Schlüsselparameter in der Ausgabe, um die Ursache für einen hohen Client-Ausgabepuffer zu ermitteln:

• obl: Output buffer length (Länge des Ausgabepuffers)
• omem: Output buffer memory usage (Nutzung des Ausgangspufferspeichers)
• tot-mem: Total memory used by the client (Gesamter vom Client verwendeter Speicher)

Du kannst auch die Metriken DatabaseMemoryUsageCountedForEvictPercentage und DatabaseMemoryUsagePercentage in Amazon CloudWatch überprüfen. Wenn es einen signifikanten Unterschied in der Speicherauslastung zwischen den beiden Metriken gibt, sind die Client-Ausgabepuffer die Ursache für die Speicherauslastung.

Hinweis: Die Metrik DatabaseMemoryUsagePercentage umfasst auch den Verbindungs-Overhead und die Speicherauslastung des Client-Ausgabepuffers.

Bewährte Methoden

Verwende die folgenden bewährten Methoden, um Probleme mit dem Speicherungleichgewicht zu reduzieren.

TTL-Einstellungen konfigurieren

Stelle die entsprechenden Time to Live (TTL)-Werte für Schlüssel ein. Wenn du die entsprechenden TTL-Werte konfigurierst, entfernt der Valkey-Knoten automatisch Schlüssel, für die kein TTL mehr vorhanden ist und optimiert die Speicherauslastung. Weitere Informationen findest du unter TTL auf der Valkey-Website.

Speichermetriken überprüfen

Es hat sich bewährt, die folgenden wichtigen Speichermetriken für die Shards regelmäßig zu überprüfen, um Ungleichgewichte frühzeitig zu erkennen und proaktive Maßnahmen zu ergreifen:

• DatabaseMemoryUsagePercentage: Verfolge die gesamte Speicherauslastung auf dem Knoten.
• DatabaseMemoryUsageCountedForEvictPercentage: Um eine hohe Puffer- und Overhead-Nutzung zu erkennen, vergleiche mit ** DatabaseMemoryUsagePercentage**.
• **BytesUsedForCache:**Überwache den tatsächlichen Speicher, den zwischengespeicherte Daten verwenden.
• CurrItems: Verfolge die Anzahl der Elemente, die in jedem Shard gespeichert sind.
• SwapUsage: Verfolge die Menge an Swap, die auf einem Host verwendet wird.
  **Hinweis:**Es ist üblich, dass ElastiCache eine gewisse SwapUsage hat. Bei normaler Auslastung treten keine Latenzprobleme auf. Wenn SwapUsage 300 MB überschreitet, überprüfe den Speicherdruck. Weitere Informationen findest du unter Wie viel reservierten Speicher benötigst du?

Aktualisiere die Knoten

Um große Schlüssel und häufige Zugriffsmuster zu verarbeiten, skaliere die ElastiCache-Cluster vorübergehend, um zusätzliche CPU- und Speicherressourcen bereitzustellen.

Ähnliche Informationen

Wie überprüfe ich die Speicherauslastung in meinem selbst entworfenen ElastiCache für Redis Cluster und implementiere bewährten Methoden zur Kontrolle einer hohen Speicherauslastung?

Modell für die Schlüsselverteilung auf der Valkey-Website

Amazon ElastiCache-Update – Online-Größenänderung für Redis-Cluster

Wie behebe ich den Anstieg der Swap-Aktivität in meinen ElastiCache-Instances?