Vermeiden des Austauschs bei ElastiCache Redis

Wir haben ständig Probleme mit dem Austausch unserer ElastiCache Redis-Instanz. Amazon scheint über eine grobe interne Überwachung zu verfügen, bei der Auslagerungsspitzen festgestellt werden und die ElastiCache-Instanz einfach neu gestartet wird (wodurch alle zwischengespeicherten Elemente verloren gehen). Hier ist das Diagramm von BytesUsedForCache (blaue Linie) und SwapUsage (orange Linie) auf unserer ElastiCache-Instanz für die letzten 14 Tage:

Sie können sehen, dass das Muster der zunehmenden Auslagerungsnutzung einen Neustart unserer ElastiCache-Instanz auslöst, wobei alle zwischengespeicherten Elemente verloren gehen (BytesUsedForCache fällt auf 0).

Die Registerkarte "Cache-Ereignisse" in unserem ElastiCache-Dashboard enthält entsprechende Einträge:

Quell-ID | Typ | Datum | Veranstaltung

Cache-Instanz-ID | Cache-Cluster | Dienstag, 22. September, 07:34:47 GMT-400 2015 | Cache-Knoten 0001 neu gestartet

Cache-Instanz-ID | Cache-Cluster | Di 22.09. 07:34:42 GMT-400 2015 | Fehler beim Neustarten der Cache-Engine auf Knoten 0001

Cache-Instanz-ID | Cache-Cluster | So 20.09. 11:13:05 GMT-400 2015 | Cache-Knoten 0001 neu gestartet

Cache-Instanz-ID | Cache-Cluster | Do 17.09. 22:59:50 GMT-400 2015 | Cache-Knoten 0001 neu gestartet

Cache-Instanz-ID | Cache-Cluster | Wed Sep 16 10:36:52 GMT-400 2015 | Cache-Knoten 0001 neu gestartet

Cache-Instanz-ID | Cache-Cluster | Di 15.09. 05.02.35 GMT-400 2015 | Cache-Knoten 0001 neu gestartet

(frühere Einträge ausschneiden)

Amazon behauptet :

SwapUsage - Im normalen Gebrauch sollten weder Memcached noch Redis Swaps durchführen

Unsere relevanten (nicht standardmäßigen) Einstellungen:

• Instanztyp: cache.r3.2xlarge
• maxmemory-policy: allkeys-lru (wir hatten vorher die voreingestellte volatile-lru ohne großen Unterschied verwendet)
• maxmemory-samples: 10
• reserved-memory: 2500000000
• Wenn ich den INFO-Befehl auf der Instanz überprüfe, sehe ich mem_fragmentation_ratiozwischen 1.00 und 1.05

Wir haben den AWS-Support kontaktiert und nicht viele nützliche Ratschläge erhalten: Sie haben vorgeschlagen, den reservierten Speicher noch weiter zu erhöhen (der Standardwert ist 0 und wir haben 2,5 GB reserviert). Für diese Cache-Instanz sind keine Replikationen oder Snapshots eingerichtet, daher sollten meines Erachtens keine BGSAVEs auftreten, die eine zusätzliche Speichernutzung verursachen.

Die maxmemoryObergrenze einer cache.r3.2xlarge-Datei beträgt 62495129600 Byte, und obwohl wir unsere Obergrenze (minus unserer reserved-memory) schnell erreicht haben, erscheint es mir merkwürdig, dass das Host-Betriebssystem unter Druck geraten würde, hier so viel Swap zu verwenden, und zwar so schnell, es sei denn Amazon hat aus irgendeinem Grund die Einstellungen für den Austausch von Betriebssystemen erhöht. Irgendwelche Ideen, warum wir ElastiCache / Redis so häufig austauschen, oder eine mögliche Problemumgehung?

Da hier niemand anders eine Antwort hatte, dachte ich, ich würde das einzige teilen, was für uns funktioniert hat. Erstens haben diese Ideen nicht funktioniert:

• größerer Cache-Instanztyp: hatte das gleiche Problem bei kleineren Instanzen als der Cache.r3.2xlarge, den wir jetzt verwenden
• zwicken maxmemory-policy: weder flüchtige lru noch allkeys-lru schienen einen unterschied zu machen
• stoßen nach oben maxmemory-samples
• stoßen nach oben reserved-memory
• Erzwingen, dass alle Clients eine Ablaufzeit festlegen, in der Regel höchstens 24 Stunden, wobei einige wenige seltene Anrufer bis zu 7 Tage zulassen. Die überwiegende Mehrheit der Anrufer verwendet jedoch eine Ablaufzeit von 1 bis 6 Stunden.

Hier ist, was letztendlich viel geholfen hat: Alle zwölf Stunden einen Job ausführen, der einen SCAN über alle Schlüssel in Blöcken ( COUNT) von 10.000 ausführt . Hier ist das BytesUsedForCache derselben Instanz, immer noch eine cache.r3.2xlarge-Instanz, die noch stärker genutzt wird als zuvor, mit denselben Einstellungen wie zuvor:

Die Sägezahnverluste im Speicher entsprechen den Zeiten des Cronjobs. In diesem Zeitraum von zwei Wochen lag die Swap-Nutzung bei ~ 45 MB (vor dem Neustart bei ~ 5 GB). Auf der Registerkarte Cache-Ereignisse in ElastiCache werden keine Cache-Neustartereignisse mehr gemeldet.

Ja, dies scheint ein Trick zu sein, den Benutzer nicht selbst tun müssen sollten, und Redis sollte klug genug sein, um diese Bereinigung selbst durchzuführen. Warum funktioniert das? Nun, Redis bereinigt abgelaufene Schlüssel nicht häufig oder vorbeugend, sondern verlässt sich auf die Räumung abgelaufener Schlüssel während GETs . Wenn Redis feststellt, dass der Speicher voll ist, werden die Schlüssel für jedes neue SET entfernt. Meine Theorie besagt jedoch, dass Redis zu diesem Zeitpunkt bereits abgespritzt ist.

Ich weiß, dass dies vielleicht alt ist, aber ich bin in der aws-Dokumentation darauf gestoßen.

https://aws.amazon.com/elasticache/pricing/ Sie geben an, dass das r3.2xlarge 58.2gb Speicher hat.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html Sie geben an, dass der maximale Speicher des Systems 62 GB beträgt (dies ist der Zeitpunkt, an dem die maxmemory-Richtlinie aktiviert wird) und dass sie nicht geändert werden kann . Es scheint, dass wir mit Redis in AWS, egal was passiert, tauschen werden.