Éviter l'échange sur ElastiCache Redis

Nous avons eu des problèmes continus avec notre échange d'instance ElastiCache Redis. Amazon semble avoir une surveillance interne brute en place qui remarque des pics d'utilisation de swap et redémarre simplement l'instance ElastiCache (perdant ainsi tous nos éléments mis en cache). Voici le graphique de BytesUsedForCache (ligne bleue) et SwapUsage (ligne orange) sur notre instance ElastiCache au cours des 14 derniers jours:

Vous pouvez voir le modèle de l'utilisation croissante des swaps sembler déclencher des redémarrages de notre instance ElastiCache, dans laquelle nous perdons tous nos éléments mis en cache (BytesUsedForCache tombe à 0).

L'onglet «Événements de cache» de notre tableau de bord ElastiCache contient les entrées correspondantes:

ID de la source | Type | Date | un événement

cache-instance-id | cache-cluster | Mar. 22 sept. 07:34:47 GMT-400 2015 | Nœud de cache 0001 redémarré

cache-instance-id | cache-cluster | Mar. 22 sept. 07:34:42 GMT-400 2015 | Erreur lors du redémarrage du moteur de cache sur le nœud 0001

cache-instance-id | cache-cluster | Dim. 20 sept. 11:13:05 GMT-400 2015 | Nœud de cache 0001 redémarré

cache-instance-id | cache-cluster | Jeu. 17 sept. 22:59:50 GMT-400 2015 | Nœud de cache 0001 redémarré

cache-instance-id | cache-cluster | Mer. 16 sept. 10:36:52 GMT-400 2015 | Nœud de cache 0001 redémarré

cache-instance-id | cache-cluster | Mar. 15 sept. 05:02:35 GMT-400 2015 | Nœud de cache 0001 redémarré

(couper les entrées précédentes)

Amazon affirme :

SwapUsage - en utilisation normale, ni Memcached ni Redis ne devraient effectuer de swaps

Nos paramètres pertinents (non par défaut):

• Type d'instance: cache.r3.2xlarge
• maxmemory-policy: allkeys-lru (nous utilisions auparavant le volatile-lru par défaut sans grande différence)
• maxmemory-samples: dix
• reserved-memory: 2500000000
• En vérifiant la commande INFO sur l'instance, je vois mem_fragmentation_ratioentre 1,00 et 1,05

Nous avons contacté le support AWS et n'avons pas reçu beaucoup de conseils utiles: ils ont suggéré d'augmenter encore plus la mémoire réservée (la valeur par défaut est 0 et nous avons 2,5 Go réservés). Nous n'avons pas de réplication ou d'instantanés configurés pour cette instance de cache, donc je pense qu'aucun BGSAVE ne devrait se produire et entraîner une utilisation supplémentaire de la mémoire.

Le maxmemoryplafond d'un cache.r3.2xlarge est de 62495129600 octets, et bien que nous atteignions reserved-memoryrapidement notre plafond (moins notre ), il me semble étrange que le système d'exploitation hôte se sente obligé d'utiliser autant de swap ici, et si rapidement, sauf si Amazon a augmenté les paramètres de permutation du système d'exploitation pour une raison quelconque. Avez-vous des idées sur la raison pour laquelle nous provoquerions autant d'échanges sur ElastiCache / Redis, ou une solution de contournement que nous pourrions essayer?

Puisque personne d'autre n'avait de réponse ici, j'ai pensé partager la seule chose qui a fonctionné pour nous. Tout d'abord, ces idées n'ont pas fonctionné:

• type d'instance de cache plus grand: rencontrait le même problème sur des instances plus petites que le cache.r3.2xlarge que nous utilisons maintenant
• peaufinage maxmemory-policy: ni volatile-lru ni allkeys-lru ne semblent faire la différence
• se cogner maxmemory-samples
• se cogner reserved-memory
• forçant tous les clients à définir un délai d'expiration, généralement au plus 24 heures, quelques rares appelants autorisant jusqu'à 7 jours, mais la grande majorité des appelants utilisent un délai d'expiration de 1 à 6 heures.

Voici ce qui a finalement aidé, beaucoup: exécuter un travail toutes les douze heures qui exécute un balayage sur toutes les clés en morceaux ( COUNT) de 10 000. Voici le BytesUsedForCache de cette même instance, toujours une instance cache.r3.2xlarge sous une utilisation encore plus lourde qu'auparavant, avec les mêmes paramètres qu'avant:

Les baisses en dents de scie de l'utilisation de la mémoire correspondent aux heures de la tâche cron. Au cours de cette période de deux semaines, notre utilisation du swap a atteint environ 45 Mo (dépassé à environ 5 Go avant de redémarrer). Et l'onglet Événements de cache dans ElastiCache ne signale plus d'événements de redémarrage du cache.

Oui, cela semble être un kludge que les utilisateurs ne devraient pas avoir à faire eux-mêmes, et que Redis devrait être assez intelligent pour gérer ce nettoyage seul. Alors pourquoi ça marche? Eh bien, Redis ne fait pas grand-chose ni aucun nettoyage préventif des clés expirées, mais s'appuie plutôt sur l' expulsion des clés expirées lors des GET . Ou, si Redis se rend compte que la mémoire est pleine, alors il commencera à expulser les clés pour chaque nouveau SET, mais ma théorie est qu'à ce stade, Redis est déjà arrosé.

Je sais que cela peut être ancien mais je l'ai rencontré dans la documentation aws.

https://aws.amazon.com/elasticache/pricing/ Ils indiquent que le r3.2xlarge a 58,2 Go de mémoire.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html Ils déclarent que le système maxmemory est de 62 Go (c'est lorsque la politique maxmemory entre en jeu) et qu'elle ne peut pas être modifiée . Il semble que peu importe quoi avec Redis dans AWS, nous échangerons ..