Auf dieser Seite finden Sie eine Anleitung zur optimalen Verwendung von Memorystore for Valkey. Auf dieser Seite werden auch potenzielle Probleme aufgeführt, die Sie vermeiden sollten.
Best Practices für die Speicherverwaltung
In diesem Abschnitt werden Strategien für die Verwaltung des Instanzspeichers beschrieben, damit Memorystore for Valkey effizient für Ihre Anwendung funktioniert.
Konzepte zur Speicherverwaltung
Speichernutzung: Die Menge an Arbeitsspeicher, die von Ihrer Instanz verwendet wird. Sie haben eine feste Speicherkapazität. Mit Messwerten können Sie überwachen, wie viel Arbeitsspeicher Sie verwenden.
Entfernungsrichtlinie: Memorystore for Valkey verwendet die
volatile-lru-Entfernungsrichtlinie. Mit Valkey-Befehlen wieEXPIREkönnen Sie das Entfernen von Schlüsseln festlegen.
Arbeitsspeichernutzung für eine Instanz überwachen
Wenn Sie die Speichernutzung einer Memorystore for Valkey-Instanz überwachen möchten, empfehlen wir, den Messwert /instance/memory/maximum_utilization anzusehen. Wenn die Speichernutzung der Instanz sich 80% nähert und Sie mit einem Anstieg der Datennutzung rechnen, sollten Sie die Größe der Instanz hochskalieren, um Platz für neue Daten zu schaffen.
Wenn die Instanz eine hohe Arbeitsspeichernutzung aufweist, gehen Sie so vor, um die Leistung zu verbessern:
- Instanzgröße vertikal skalieren.
- Verringern Sie den Konfigurationsparameter
maxmemory.
Wenn Probleme auftreten, wenden Sie sich an den Google Cloud Kundenservice.
Shards im aktivierten Clustermodus skalieren
Wenn Sie die Anzahl der Shards in einer Instanz skalieren, empfehlen wir, dies in Zeiten mit wenigen Schreibvorgängen zu tun. Die Skalierung in Zeiten hoher Nutzung kann den Arbeitsspeicher Ihrer Instanz aufgrund des durch die Replikation oder Slotmigration verursachten Speicheraufwands belasten.
Wenn in Ihrem Valkey-Anwendungsfall Schlüssel entfernt werden, kann die Cache-Trefferquote durch die Skalierung auf eine kleinere Instanzgröße sinken. In diesem Fall müssen Sie sich jedoch keine Sorgen um Datenverlust machen, da das Entfernen von Schlüsseln erwartet wird.
Bei Valkey-Anwendungsfällen, in denen Sie keine Schlüssel verlieren möchten, sollten Sie nur auf eine kleinere Instanz herunterskalieren, die noch genügend Speicherplatz für Ihre Daten bietet. Die neue Anzahl der Ziel-Shards sollte mindestens das 1,5-Fache des von Daten verwendeten Arbeitsspeichers betragen. Mit anderen Worten: Sie sollten genügend Shards für das 1,5-Fache der Daten bereitstellen, die sich derzeit in Ihrer Instanz befinden. 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-Nutzung
Wenn ein unerwarteter Zonenausfall auftritt, führt dies zu weniger CPU-Ressourcen für Ihre Instanz, da die Kapazität von Knoten in der nicht verfügbaren Zone verloren geht. Wir empfehlen die Verwendung von Instanzen mit Hochverfügbarkeit. Wenn Sie zwei Replikate pro Shard verwenden (im Gegensatz zu einem Replikat pro Shard), stehen bei einem Ausfall zusätzliche CPU-Ressourcen zur Verfügung. Außerdem empfehlen wir, die CPU-Nutzung von Knoten so zu verwalten, dass Knoten genügend CPU-Overhead haben, um zusätzlichen Traffic aufgrund von verloren gegangener Kapazität zu verarbeiten, falls es zu einem unerwarteten zonalen Ausfall kommt. Sie sollten die CPU-Nutzung für Primaries und Replikate mit dem Messwert CPU-Sekunden des Hauptthreads überwachen./instance/cpu/maximum_utilization
Je nachdem, wie viele Replikate Sie pro Knoten bereitstellen, empfehlen wir die folgenden /instance/cpu/maximum_utilization-CPU-Auslastungsziele:
- Bei Instanzen mit einem Replikat pro Knoten sollten Sie einen
/instance/cpu/maximum_utilization-Wert von 0, 5 Sekunden für den primären Knoten und das Replikat anstreben. - Bei Instanzen mit zwei Replikaten 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 Replikate anstreben.
Wenn die Werte für den Messwert diese Empfehlungen überschreiten, empfehlen wir, die Anzahl der Shards oder Replikate in Ihrer Instanz zu erhöhen.
Ressourcenintensive Valkey-Befehle
Wir empfehlen dringend, ressourcenintensive Valkey-Befehle zu vermeiden. Die Verwendung dieser Befehle kann zu den folgenden Leistungsproblemen führen:
- Hohe Latenz und Client-Zeitüberschreitungen
- Arbeitsspeichermangel durch Befehle, die die Arbeitsspeichernutzung erhöhen
- Datenverlust bei der Knotenreplikation und ‑synchronisierung, weil der Valkey-Hauptthread blockiert ist
- Systemdiagnosen, Beobachtbarkeit und Replikation
In der folgenden Tabelle sind Beispiele für ressourcenintensive Valkey-Befehle und ressourcenschonende Alternativen aufgeführt.
| Kategorie | Ressourcenintensiver Befehl | Ressourcenschonende Alternative |
|---|---|---|
| Für den gesamten Schlüsselbereich ausführen | KEYS |
SCAN |
| Für einen Schlüsselsatz mit variabler Länge ausführen | LRANGE |
Begrenzen Sie die Größe des Bereichs, den Sie für eine Abfrage verwenden. |
ZRANGE |
Begrenzen Sie die Größe des Bereichs, den Sie für eine Abfrage verwenden. | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| Ausführung eines Skripts blockieren | EVAL |
Achten Sie darauf, dass Ihr Script nicht unbegrenzt ausgeführt wird. |
EVALSHA |
Achten Sie darauf, dass Ihr Script nicht unbegrenzt ausgeführt wird. | |
| Dateien und Links entfernen | DELETE |
UNLINK |
| Veröffentlichen und abonnieren | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
Best Practices für Valkey-Clients
Überlastung der Verbindung auf Valkey vermeiden
Um die Auswirkungen eines plötzlichen Anstiegs der Verbindungen zu minimieren, empfehlen wir Folgendes:
Ermitteln Sie die für Sie optimale Größe des Clientverbindungspools. Eine gute Ausgangsgröße für jeden Client ist eine Verbindung pro Valkey-Knoten. Anschließend können Sie Benchmarks durchführen, um zu sehen, ob mehr Verbindungen helfen, ohne die maximal zulässige Anzahl von Verbindungen zu überschreiten.
Wenn die Verbindung des Clients zum Server getrennt wird, weil der Server eine Zeitüberschreitung hat, versuchen Sie es noch einmal mit exponentiellem Backoff mit Jitter. So wird verhindert, dass mehrere Clients den Server gleichzeitig überlasten.
Für Instanzen mit aktiviertem Clustermodus
Ihre Anwendung muss einen clusterfähigen Valkey-Client verwenden, wenn sie eine Verbindung zu einer Memorystore for Valkey-Instanz mit aktiviertem Clustermodus herstellt. 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. Dadurch wird der Leistungs-Overhead durch Weiterleitungen vermieden.
Clientzuordnung
Kunden müssen in den folgenden Situationen eine vollständige Liste der Slots und der zugeordneten Knoten abrufen:
Wenn der Client initialisiert wird, muss er die Zuordnung von Slots zu Knoten festlegen.
Wenn vom Server eine
MOVED-Weiterleitung empfangen wird, z. B. bei einem Failover, wenn alle Slots, die vom ehemaligen primären Knoten bereitgestellt wurden, vom Replikat übernommen werden, oder beim Resharding, 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 immer wieder Zeitüberschreitungen verursachen.Wenn vom Server ein
READONLY-Fehler empfangen wird. Das kann passieren, wenn eine primäre Instanz zu einem Replikat herabgestuft wird.Außerdem sollten Clients die Topologie regelmäßig aktualisieren, um für Änderungen gerüstet zu sein und Änderungen zu erkennen, die nicht zu Weiterleitungen oder Fehlern vom Server führen, z. B. wenn neue Replikatknoten hinzugefügt werden. Beachten Sie, dass alle alten Verbindungen im Rahmen der Topologieaktualisierung geschlossen werden sollten, um die Notwendigkeit zu verringern, fehlgeschlagene Verbindungen während der Befehlsausführung zu behandeln.
Clientermittlung
Die Client-Erkennung erfolgt in der Regel durch Ausführen des Befehls SLOTS, NODES oder CLUSTER SHARDS auf dem Valkey-Server. Wir empfehlen die Verwendung des Befehls CLUSTER SHARDS. CLUSTER SHARDS ersetzt den Befehl SLOTS (eingestellt) 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 führen zu einer größeren 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 kostspielig, aber auch wichtig für die Verfügbarkeit der Anwendung. Daher ist es wichtig, dass jeder Client zu einem bestimmten Zeitpunkt nur eine 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 die Knotenerkennung durchführen muss, ist ein häufiger Fehler, dass die Clientanwendung mehrere Wiederverbindungs- und Erkennungsanfragen stellt, ohne beim Wiederholen exponentielle Backoffs hinzuzufügen. Dadurch kann der Valkey-Server für längere Zeit nicht mehr reagieren und eine sehr hohe CPU-Auslastung verursachen.
Erkennungs-Endpunkt für die Knotenerkennung verwenden
Verwenden Sie den Discovery-Endpunkt von Memorystore for Valkey, um Knoten zu ermitteln. Der Discovery-Endpunkt ist hochverfügbar und wird per Load-Balancing auf alle Knoten in der Instanz verteilt. Außerdem versucht der Discovery-Endpunkt, die Knotenerkennungsanfragen an Knoten mit der aktuellsten Topologieansicht weiterzuleiten.
Für Instanzen mit deaktiviertem Clustermodus
Wenn Sie eine Verbindung zu einer Instanz mit deaktiviertem Clustermodus herstellen, muss Ihre Anwendung eine Verbindung zum primären Endpunkt herstellen, um in die Instanz zu schreiben und die letzten Schreibvorgänge abzurufen. Ihre Anwendung kann auch eine Verbindung zum Leseendpunkt herstellen, um Daten aus Replikaten zu lesen und den Traffic vom primären Knoten zu isolieren.
Best Practices für die Persistenz
In diesem Abschnitt werden Best Practices für die Persistenz erläutert.
RDB-Persistenz
Wenn Sie Ihre Instanz mit RDB-Snapshots sichern möchten, sollten Sie die folgenden Best Practices beachten:
Speicherverwaltung
Bei RDB-Snapshots wird ein Prozess-Fork und ein „Copy-on-Write“-Mechanismus verwendet, um einen Snapshot der Knotendaten zu erstellen. Je nach Muster der Schreibvorgänge für Knoten wächst der verwendete Speicher der Knoten, da die von den Schreibvorgängen betroffenen Seiten kopiert werden. Im schlimmsten Fall kann der Speicherbedarf doppelt so groß sein wie die Daten im Knoten.
Damit Knoten genügend Arbeitsspeicher für die Erstellung des Snapshots haben, sollten Sie maxmemory auf 80% der Knotenkapazität festlegen oder beibehalten, damit 20% für den Mehraufwand reserviert sind. Weitere Informationen finden Sie unter Arbeitsspeichernutzung einer Instanz überwachen. Dieser zusätzliche Arbeitsspeicher hilft Ihnen zusammen mit Monitoring-Snapshots, Ihre Arbeitslast so zu verwalten, dass erfolgreiche Snapshots erstellt werden können.
Veraltete Snapshots
Das Wiederherstellen von Knoten aus einem alten Snapshot kann zu Leistungsproblemen bei Ihrer Anwendung führen, da versucht wird, eine große Anzahl alter Schlüssel oder andere Änderungen an Ihrer Datenbank, z. B. eine Schemaänderung, abzugleichen. Wenn Sie Bedenken haben, dass Sie einen alten Snapshot wiederherstellen, können Sie die RDB-Persistenz deaktivieren. Sobald Sie die Persistenz wieder aktivieren, wird beim 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 Auswirkungen von RDB-Snapshots auf die Leistung minimieren, indem Sie sie für Zeiträume mit geringem Instanz-Traffic planen, wenn Sie mit weniger häufigen Snapshots zufrieden sind.
Wenn Ihre Instanz beispielsweise zwischen 1:00 Uhr und 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 Last hat und häufige Snapshots erforderlich sind, sollten Sie die Auswirkungen auf die Leistung sorgfältig prüfen und die Vorteile der Verwendung von RDB-Snapshots für die Arbeitslast abwägen.
Instanz in einer einzelnen Zone auswählen, wenn Ihre Instanz keine Replikate verwendet
Wenn Sie eine Instanz ohne Replikate konfigurieren, empfehlen wir eine Einzelzonenarchitektur, um die Zuverlässigkeit zu verbessern. Das kann folgende Gründe haben:
Auswirkungen von Ausfällen minimieren
Zonale Ausfälle wirken sich weniger wahrscheinlich auf Ihre Instanz aus. Wenn Sie alle Knoten in einer einzigen Zone platzieren, sinkt die Wahrscheinlichkeit, dass ein Zonenausfall Ihren Server beeinträchtigt, von 100% auf 33%. Das liegt daran, dass die Wahrscheinlichkeit, dass die Zone, in der sich Ihre Instanz befindet, ausfällt, 33% beträgt. Die Wahrscheinlichkeit, dass Knoten in der nicht verfügbaren Zone betroffen sind, beträgt dagegen 100 %.
Schnelle Erholung
Sollte ein Zonenausfall auftreten, wird die Wiederherstellung optimiert. Sie können reagieren, indem Sie schnell eine neue Instanz in einer funktionierenden Zone bereitstellen und Ihre Anwendung umleiten, um den Betrieb möglichst wenig zu unterbrechen.