Allgemeine Best Practices

Auf dieser Seite finden Sie eine Anleitung zur optimalen Verwendung von Memorystore for Valkey. Diese Seite weist auch auf mögliche Probleme hin.

Best Practices für die Arbeitsspeicherverwaltung

In diesem Abschnitt werden Strategien zum Verwalten des Instanzspeichers beschrieben, damit Memorystore for Valkey effizient für Ihre Anwendung funktioniert.

Konzepte zur Speicherverwaltung

  • Schreiblast: Das Volumen und die Geschwindigkeit, mit der Sie Schlüssel in Ihrer Valkey-Instanz hinzufügen oder aktualisieren. Die Schreiblast kann je nach Valkey-Anwendungsfall und Anwendungsnutzungsmuster von normal bis sehr hoch variieren.

  • Bereinigungsrichtlinie: Für Memorystore for Valkey wird die Bereinigungsrichtlinie volatile-lru verwendet. Sie können Valkey-Befehle wie EXPIRE verwenden, um Auslagerungen für Schlüssel festzulegen.

Instanz mit normaler Schreiblast überwachen

Rufen Sie den Messwert /instance/cpu/maximum_utilization auf. Wenn /instance/cpu/maximum_utilization 100% oder weniger beträgt, funktioniert Ihre Valkey-Instanz bei normaler Schreiblast gut.

Wenn die Speichernutzung jedoch 100% erreicht und Sie mit einer steigenden Datennutzung rechnen, sollten Sie die Instanzgröße vergrößern, um Platz für neue Daten zu schaffen.

Instanz mit hoher Schreiblast überwachen

Rufen Sie den Messwert /instance/memory/maximum_utilization auf. Je nach Schwere der hohen Schreiblast kann es bei Ihrer Instanz bei den folgenden Grenzwerten zu Leistungsproblemen kommen:

  • Bei sehr hohen Schreiblasten können Probleme auftreten, wenn /instance/memory/maximum_utilization 65% oder mehr erreicht.

  • Bei mäßig hohen Schreiblasten können Probleme auftreten, wenn /instance/memory/maximum_utilization 85% oder mehr erreicht.

In diesen Fällen sollten Sie die Instanzgröße vergrößern, um die Leistung zu verbessern.

Wenn Probleme auftreten oder Sie Bedenken haben, dass Ihre Instanz eine hohe Schreiblast hat, wenden Sie sich an den Google Cloud -Support.

Shards skalieren

Wenn Sie die Anzahl der Shards in einer Instanz skalieren, sollten Sie dies in Zeiten mit wenigen Schreibvorgängen tun. Die Skalierung in Zeiten hoher Schreiblast kann den Arbeitsspeicher Ihrer Instanz aufgrund des durch die Replikation oder die Slotmigration verursachten Speicheraufwands belasten.

Wenn für Ihren Valkey-Anwendungsfall Schlüsselentfernungen verwendet werden, kann die Skalierung auf eine kleinere Instanzgröße die Cache-Trefferquote verringern. In diesem Fall müssen Sie sich jedoch keine Sorgen um den Verlust von Daten machen, da das Entfernen von Schlüsseln erwartet wird.

Bei Valkey-Anwendungsfällen, bei denen Sie keine Schlüssel verlieren möchten, sollten Sie nur auf eine kleinere Instanz herunterskalieren, die noch genügend Platz für Ihre Daten hat. Die neue Anzahl der Zielshards sollte mindestens 1,5-mal so groß sein wie der von den Daten belegte Arbeitsspeicher. Mit anderen Worten: Sie sollten genügend Shards für das 1,5-fache der Datenmenge bereitstellen, die sich derzeit in Ihrer Instanz befindet. Mit dem Messwert /instance/memory/total_used_memory können Sie sehen, wie viele Daten in Ihrer Instanz gespeichert sind.

Best Practices für die CPU-Auslastung

Wenn ein unerwarteter Zonenausfall auftritt, führt dies aufgrund der verlorenen Kapazität von Knoten in der nicht verfügbaren Zone zu reduzierten CPU-Ressourcen für Ihre Instanz. Wir empfehlen die Verwendung von instanzen mit Hochverfügbarkeit. Die Verwendung von zwei Replicas pro Shard (anstelle von einem) bietet zusätzliche CPU-Ressourcen bei einem Ausfall. Außerdem empfehlen wir, die CPU-Nutzung der Knoten so zu verwalten, dass sie genügend CPU-Overhead haben, um zusätzlichen Traffic aufgrund von verlorener Kapazität zu bewältigen, falls ein unerwarteter zonaler Ausfall auftritt. Sie sollten die CPU-Auslastung für primäre und Replikate mit dem Messwert Hauptthread-CPU-Sekunden /instance/cpu/maximum_utilization überwachen.

Je nachdem, wie viele Repliken Sie pro Knoten bereitstellen, empfehlen wir die folgenden /instance/cpu/maximum_utilization CPU-Auslastungsziele:

  • Bei Instanzen mit einer Replikation pro Knoten sollten Sie für die primäre Instanz und die Replik einen /instance/cpu/maximum_utilization-Wert von 0, 5 Sekunden anstreben.
  • Bei Instanzen mit zwei Replicas pro Knoten sollten Sie einen /instance/cpu/maximum_utilization-Wert von 0,9 Sekunden für die primäre Instanz und 0,5 Sekunden für die Replicas anstreben.

Wenn die Werte für den Messwert diese Empfehlungen überschreiten, empfehlen wir, die Anzahl der Shards oder Replicas in Ihrer Instanz zu erhöhen.

CPU-intensive Valkey-Befehle

Sie sollten Valkey-Befehle vermeiden, die aus verschiedenen Gründen teuer in der Ausführung sind. Dieser Abschnitt enthält Beispiele für Gründe, warum bestimmte Befehle teuer sind. Die Liste ist jedoch nicht vollständig.

Befehle, die auf den gesamten Schlüsselbereich angewendet werden

  • KEYS

Befehle, die auf einem Schlüsselsatz mit variabler Länge ausgeführt werden

  • LRANGE
  • ZRANGE
  • HGETALL

Befehle, die die Ausführung eines Scripts blockieren

  • EVAL
  • EVALSHA

Risiken der Verwendung teurer Befehle

  • Hohe Latenz und Client-Zeitüberschreitungen
  • Arbeitsspeicherdruck, der durch Befehle verursacht wird, die die Arbeitsspeichernutzung erhöhen.
  • Datenverluste bei der Knotenreplikation und -synchronisierung aufgrund des Blockierens des Valkey-Hauptthreads
  • Verlangsamte Systemdiagnosen, eingeschränkte Beobachtbarkeit und fehlerhafte Replikation.

Best Practices für Valkey-Kunden

Ihre Anwendung muss einen clusterfähigen Valkey-Client verwenden, wenn eine Verbindung zu einer Memorystore for Valkey-Instanz hergestellt wird. Beispiele für clusterfähige Clients und Beispielkonfigurationen finden Sie unter Codebeispiele für Clientbibliotheken. Ihr Client muss eine Zuordnung von Hash-Slots zu den entsprechenden Knoten in der Instanz verwalten, um Anfragen an die richtigen Knoten zu senden und den durch Weiterleitungen verursachten Leistungsoverhead zu vermeiden.

Clientzuordnung

In den folgenden Fällen müssen Kunden eine vollständige Liste der Slots und der zugeordneten Knoten abrufen:

  • Bei der Initialisierung des Clients muss die Zuordnung der ersten Slots zu Knoten vorgenommen werden.

  • Wenn eine MOVED-Weiterleitung vom Server empfangen wird, z. B. bei einem Failover, wenn alle Slots, die vom vorherigen primären Knoten bereitgestellt wurden, vom Replikat übernommen werden, oder bei einem erneuten Sharding, wenn Slots vom primären Quellknoten zum primären Zielknoten verschoben werden.

  • Wenn vom Server ein CLUSTERDOWN-Fehler empfangen wird oder Verbindungen zu einem bestimmten Server wiederholt Zeitüberschreitungen verursachen.

  • Wenn vom Server ein READONLY-Fehler empfangen wird. Das kann passieren, wenn ein primäres Replikat zu einem Replikat herabgestuft wird.

  • Außerdem sollten Clients die Topologie regelmäßig aktualisieren, damit sie für alle Änderungen gerüstet sind und über Änderungen informiert werden, die nicht zu Weiterleitungen oder Fehlern vom Server führen, z. B. wenn neue Replikationsknoten hinzugefügt werden. Alle veralteten Verbindungen sollten im Rahmen der Topologieaktualisierung geschlossen werden, um die Notwendigkeit zu verringern, während der Befehlsausführung fehlgeschlagene Verbindungen zu behandeln.

Kundenermittlung

Die Clienterkennung erfolgt in der Regel durch Ausführen eines SLOTS-, NODES- oder CLUSTER SHARDS-Befehls an den Valkey-Server. Wir empfehlen die Verwendung des Befehls CLUSTER SHARDS. CLUSTER SHARDS ersetzt den veralteten Befehl SLOTS und bietet eine effizientere und erweiterbare Darstellung der Instanz.

Die Größe der Antwort für die Client-Erkennungsbefehle kann je nach Instanzgröße und Topologie variieren. Größere Instanzen mit mehr Knoten liefern eine größere Antwort. Daher ist es wichtig, dass die Anzahl der Clients, die die Knotentopologie ermitteln, nicht unbegrenzt wächst.

Diese Aktualisierungen der Knotentopologie sind auf dem Valkey-Server zwar teuer, aber auch wichtig für die Anwendungsverfügbarkeit. Daher ist es wichtig, dass jeder Client zu einem bestimmten Zeitpunkt nur eine einzige Discovery-Anfrage stellt (und das Ergebnis im Arbeitsspeicher zwischenspeichert) und die Anzahl der Clients, die die Anfragen stellen, begrenzt wird, um eine Überlastung des Servers zu vermeiden.

Wenn die Clientanwendung beispielsweise gestartet wird oder die Verbindung zum Server verliert und eine Knotensuche ausführen muss, ist ein häufiger Fehler, dass die Clientanwendung mehrere Neuverbindungs- und Suchanfragen sendet, ohne beim Wiederholungsversuch ein exponentielles Backoff hinzuzufügen. Dies kann dazu führen, dass der Valkey-Server über einen längeren Zeitraum nicht mehr reagiert und eine sehr hohe CPU-Auslastung verursacht.

Überlastung der Erkennung bei Valkey vermeiden

Um die Auswirkungen eines plötzlichen Anstiegs von Verbindungs- und Suchanfragen zu minimieren, empfehlen wir Folgendes:

  • Implementieren Sie einen Clientverbindungspool mit einer begrenzten und kleinen Größe, um die Anzahl der gleichzeitigen eingehenden Verbindungen von der Clientanwendung zu begrenzen.

  • Wenn die Verbindung des Clients aufgrund einer Zeitüberschreitung getrennt wird, wiederholen Sie den Vorgang mit exponentiellem Backoff mit Jitter. So wird verhindert, dass mehrere Clients den Server gleichzeitig überlasten.

  • Verwenden Sie den Discovery-Endpunkt von Memorystore for Valkey, um die Node-Erkennung durchzuführen. Der Discovery-Endpunkt ist hochverfügbar und wird über alle Knoten in der Instanz ausgelastet. Außerdem versucht der Discovery-Endpunkt, die Knotenermittlungsanfragen an Knoten mit der aktuellsten Topologieansicht weiterzuleiten.

Best Practices für die Persistenz

In diesem Abschnitt werden Best Practices für die Persistenz erläutert.

RDB-Persistenz

Beachten Sie die folgenden Best Practices, um die beste Leistung bei der Sicherung Ihrer Instanz mit RDB-Snapshots zu erzielen:

Speicherverwaltung

Für RDB-Snapshots werden ein Prozess-Fork und der Copy-on-Write-Mechanismus verwendet, um einen Snapshot der Knotendaten zu erstellen. Je nach Schreibmuster an die Knoten steigt der genutzte Speicher der Knoten, wenn die von den Schreibvorgängen betroffenen Seiten kopiert werden. Im schlimmsten Fall kann der Speicherbedarf doppelt so groß sein wie die Datenmenge im Knoten.

Damit die Knoten genügend Arbeitsspeicher für die Erstellung des Snapshots haben, sollten Sie maxmemory auf 80% der Knotenkapazität belassen oder festlegen, damit 20% für den Overhead reserviert sind. Weitere Informationen finden Sie unter Instanz mit hoher Schreiblast überwachen. Dieser Arbeitsspeicheraufwand hilft Ihnen zusätzlich zu Monitoring-Snapshots, Ihre Arbeitslast zu verwalten, damit Snapshots erfolgreich erstellt werden können.

Veraltete Snapshots

Das Wiederherstellen von Knoten aus einem veralteten Snapshot kann zu Leistungsproblemen bei Ihrer Anwendung führen, da versucht wird, eine große Anzahl veralteter Schlüssel oder andere Änderungen an Ihrer Datenbank wie eine Schemaänderung zu vereinheitlichen. Wenn Sie Bedenken haben, dass Sie von einem veralteten Snapshot wiederhergestellt werden, können Sie die RDB-Persistenzfunktion deaktivieren. Sobald Sie die Persistenz wieder aktivieren, wird im nächsten geplanten Snapshot-Intervall ein Snapshot erstellt.

Auswirkungen von RDB-Snapshots auf die Leistung

Je nach Arbeitslastmuster können RDB-Snapshots die Leistung der Instanz beeinträchtigen und die Latenz für Ihre Anwendungen erhöhen. Sie können die Leistungsauswirkungen von RDB-Snapshots minimieren, indem Sie sie so planen, dass sie in Zeiten mit geringem Instanz-Traffic ausgeführt werden, sofern Sie mit weniger häufigen Snapshots einverstanden sind.

Wenn Ihre Instanz beispielsweise von 1:00 Uhr bis 4:00 Uhr nur wenig Traffic hat, können Sie die Startzeit auf 3:00 Uhr und das Intervall auf 24 Stunden festlegen.

Wenn Ihr System eine konstante Auslastung hat und häufige Snapshots benötigt, sollten Sie die Leistungsauswirkungen sorgfältig bewerten und die Vorteile der Verwendung von RDB-Snapshots für die Arbeitslast abwägen.

Wählen Sie eine Instanz mit einer einzelnen Zone aus, wenn für Ihre Instanz keine Replikate verwendet werden.

Wenn Sie eine Instanz ohne Replikate konfigurieren, empfehlen wir für eine bessere Zuverlässigkeit eine Einzonenarchitektur. Das kann folgende Gründe haben:

Auswirkungen von Ausfällen minimieren

Zonale Ausfälle wirken sich mit geringerer Wahrscheinlichkeit auf Ihre Instanz aus. Wenn Sie alle Knoten in einer einzigen Zone platzieren, sinkt die Wahrscheinlichkeit, dass ein Zonenausfall Ihren Server betrifft, von 100% auf 33%. Das liegt daran, dass die Wahrscheinlichkeit, dass die Zone, in der sich Ihre Instanz befindet, ausfällt, 33% beträgt, während die Wahrscheinlichkeit, dass Knoten in der nicht verfügbaren Zone betroffen sind, 100% beträgt.

Schnelle Erholung

Sollte ein Zonenausfall auftreten, wird die Wiederherstellung optimiert. Sie können schnell reagieren, indem Sie eine neue Instanz in einer funktionierenden Zone bereitstellen und Ihre Anwendung umleiten, um den Betrieb so wenig wie möglich zu unterbrechen.