Allgemeine Best Practices

Diese Seite enthält Anleitungen 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 Instanzarbeitsspeichers beschrieben, damit Memorystore for Valkey für Ihre Anwendung effizient 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 Nutzungsmuster der Anwendung normal bis sehr hoch sein.

  • Bereinigungsrichtlinie: Memorystore for Valkey verwendet die Bereinigungsrichtlinie volatile-lru. Mit Valkey-Befehlen wie dem Befehl EXPIRE können Sie Bereinigungen für Schlüssel festlegen.

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 sich Ihre Arbeitsspeichernutzung jedoch fast 100% nähert und Sie mit einer Zunahme der Datennutzung rechnen, sollten Sie die Instanzgröße erhöhen, um Platz für neue Daten zu schaffen.

Instanz mit hoher Schreiblast überwachen

Rufen Sie den Messwert /instance/memory/maximum_utilization auf. Je nach Schweregrad Ihrer hohen Schreiblast können bei der Instanz bei folgenden Schwellenwerten Leistungsprobleme auftreten:

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

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

In diesen Szenarien sollten Sie die Instanzgröße erhöhen, um die Leistung zu verbessern.

Wenn Probleme auftreten oder Sie befürchten, dass Ihre Instanz eine hohe Schreiblast aufweist, wenden Sie sich an Google Cloud-Support

Shards skalieren

Wenn Sie die Anzahl der Shards in einer Instanz skalieren, sollten Sie die Skalierung in Zeiten mit wenigen Schreibvorgängen vornehmen. Die Skalierung in Zeiträumen mit hoher Schreiblast kann den Arbeitsspeicher Ihrer Instanz beanspruchen, da der Arbeitsspeicher-Overhead durch Replikation oder Slot-Migration verursacht wird.

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.

Für Valkey-Anwendungsfälle, in 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 bietet. Die neue Ziel-Shard-Anzahl sollte mindestens das 1,5-Fache des von Daten genutzten Arbeitsspeichers ermöglichen. Mit anderen Worten, Sie sollten genügend Shards für die 1,5-fache 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-Nutzung

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 Replikaten pro Shard (im Gegensatz zu einem Replikat pro Shard) stellt bei einem Ausfall zusätzliche CPU-Ressourcen zur Verfügung. Außerdem empfehlen wir, die CPU-Auslastung 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 Zonenausfall 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 Replikate Sie pro Knoten bereitstellen, empfehlen wir die folgenden /instance/cpu/maximum_utilization-CPU-Nutzungsziele:

  • Bei Instanzen mit 1 Replikat pro Knoten sollten Sie für die primäre Instanz und das Replikat einen /instance/cpu/maximum_utilization-Wert von 0, 5 Sekunden festlegen.
  • Bei Instanzen mit 2 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 skalieren.

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 den gesamten Schlüsselbereich betreffen

  • SCHLÜSSEL

Befehle für einen Schlüsselsatz mit variabler Länge

  • LRANGE
  • ZRANGE
  • HGETALL

Befehle, die die Ausführung eines Skripts blockieren

  • BEWERTEN
  • EVALSHA

Risiken bei der Verwendung teurer Befehle

  • Hohe Latenz und Zeitüberschreitungen beim Client
  • Arbeitsspeicherdruck, der durch Befehle verursacht wird, die die Arbeitsspeichernutzung erhöhen.
  • Datenverlust während der Knotenreplikation und Synchronisierung aufgrund des Blockierens des Valkey-Hauptthreads.
  • Eingeschränkte Systemdiagnosen, Beobachtbarkeit und Replikation.

Best Practices für Valkey-Kunden

Ihre Anwendung muss beim Herstellen einer Verbindung zu einer Memorystore for Valkey-Instanz einen clusterfähigen Valkey-Client verwenden. Beispiele für clustersensitive Clients und Beispielkonfigurationen finden Sie in den Codebeispielen für die Clientbibliothek. 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 Leistungsaufwand zu vermeiden.

Clientzuordnung

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

  • Wenn der Client initialisiert wird, muss er den anfänglichen Slot mit Knoten füllen -Zuordnung.

  • Wenn eine MOVED-Weiterleitung vom Server eingeht, z. B. eines Failovers, wenn alle vom vorherigen primären Knoten bereitgestellten Slots übernommen werden vom Replikat oder eine Re-Fragmentierung, wenn Slots aus der Quelle verschoben werden zum primären Zielknoten.

  • 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. Dies kann passieren, wenn eine primäre wird auf Replikat herabgestuft.

  • 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. Beachten Sie, dass Veraltete Verbindungen sollten auch im Rahmen der Topologieaktualisierung geschlossen werden, dass fehlgeschlagene Verbindungen während der Befehlslaufzeit verarbeitet werden müssen.

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 auf die Befehle zur Clienterkennung kann variieren basierend auf der Instanzgröße und der Topologie. Größere Instanzen mit mehr Knoten erzeugen eine umfassendere 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 beispielsweise die Clientanwendung vom Server gestartet wird oder die Verbindung zum Server abbricht und eine Knotenerkennung durchführen muss, besteht ein häufiger Fehler darin, dass die Clientanwendung mehrere Anfragen zur erneuten Verbindung und Erkennung sendet, ohne bei einem Wiederholungsversuch einen exponentiellen Backoff hinzuzufügen. Dies kann dazu führen, dass der Valkey-Server über einen längeren Zeitraum nicht mehr reagiert, was eine sehr hohe CPU-Auslastung zur Folge hat.

Überlastung bei der Erkennung auf Valkey vermeiden

Um die Auswirkungen eines plötzlichen Zustroms von Verbindungen und Auffindbarkeit abzuschwächen 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 der Client aufgrund einer Zeitüberschreitung vom Server getrennt wird, wiederholen Sie den Vorgang mit exponentiellen Backoff mit Jitter. So vermeiden Sie, den Server überlastet.

  • Verwenden Sie den Discovery-Endpunkt von Memorystore for Valkey, um die Node-Erkennung durchzuführen. Der Erkennungsendpunkt ist hochverfügbar und erfolgt per Load-Balancing auf allen Knoten in der Instanz. 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 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 Muster der Schreibvorgänge auf Knoten wächst der verwendete Arbeitsspeicher der Knoten, wenn die von den Schreibvorgängen berührten Seiten kopiert werden. Im schlimmsten Fall kann der Speicherbedarf doppelt so groß sein wie die Daten 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 Arbeitsspeicher-Overhead hilft Ihnen zusammen mit Monitoring-Snapshots dabei, Ihre Arbeitslast für erfolgreiche Snapshots zu verwalten.

Veraltete Snapshots

Die Wiederherstellung von Knoten aus einem veralteten Snapshot kann zu Leistungsproblemen für Ihre Anwendung führen, da versucht wird, eine erhebliche Anzahl veralteter Schlüssel oder andere Änderungen an Ihrer Datenbank wie eine Schemaänderung abzugleichen. Wenn Sie einen veralteten Snapshot wiederherstellen möchten, können Sie die RDB-Persistenzfunktion deaktivieren. Wenn 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 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 01:00 Uhr bis 4:00 Uhr wenig Traffic aufweist, können Sie die Startzeit auf 3:00 Uhr morgens und das Intervall auf 24 Stunden festlegen.

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

Instanz mit einer einzelnen Zone auswählen, wenn die Instanz keine Replikate verwendet

Für die Konfiguration einer Instanz ohne Replikate empfehlen wir zur Verbesserung der Zuverlässigkeit eine Architektur mit einer einzelnen Zone. Das kann folgende Gründe haben:

Auswirkungen von Ausfällen minimieren

Zonale Ausfälle wirken sich mit geringerer Wahrscheinlichkeit auf Ihre Instanz aus. Durch das Platzieren aller Knoten in einer einzelnen Zone, sinkt die Wahrscheinlichkeit eines zonalen Ausfalls, der 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, das Bereitstellen einer neuen Instanz in einer funktionierenden Zone und das Weiterleiten Ihres für minimal unterbrochene Vorgänge.