Evitar el intercambio en ElastiCache Redis

Hemos tenido problemas continuos con nuestro intercambio de instancias de ElastiCache Redis. Amazon parece tener una supervisión interna cruda que advierte picos de uso de intercambio y simplemente reinicia la instancia de ElastiCache (perdiendo así todos nuestros elementos en caché). Aquí está el gráfico de BytesUsedForCache (línea azul) y SwapUsage (línea naranja) en nuestra instancia de ElastiCache durante los últimos 14 días:

Puede ver el patrón de uso creciente de intercambio que parece provocar el reinicio de nuestra instancia de ElastiCache, en el que perdemos todos nuestros elementos almacenados en caché (BytesUsedForCache cae a 0).

La pestaña 'Eventos de caché' de nuestro panel de control de ElastiCache tiene las entradas correspondientes:

ID de fuente | Tipo | Fecha | Evento

id-instancia-caché | clúster de caché | Martes 22 de septiembre 07:34:47 GMT-400 2015 | Nodo de caché 0001 reiniciado

id-instancia-caché | clúster de caché | Martes 22 de septiembre 07:34:42 GMT-400 2015 | Error al reiniciar el motor de caché en el nodo 0001

id-instancia-caché | clúster de caché | Dom 20 sep 11:13:05 GMT-400 2015 | Nodo de caché 0001 reiniciado

id-instancia-caché | clúster de caché | Jue 17 sep 22:59:50 GMT-400 2015 | Nodo de caché 0001 reiniciado

id-instancia-caché | clúster de caché | Mié 16 sep 10:36:52 GMT-400 2015 | Nodo de caché 0001 reiniciado

id-instancia-caché | clúster de caché | Martes 15 de septiembre 05:02:35 GMT-400 2015 | Nodo de caché 0001 reiniciado

(recortar entradas anteriores)

Amazon afirma :

SwapUsage : en uso normal, ni Memcached ni Redis deberían realizar intercambios

Nuestra configuración relevante (no predeterminada):

• Tipo de instancia: cache.r3.2xlarge
• maxmemory-policy: allkeys-lru (habíamos estado usando el volátil por defecto previamente sin mucha diferencia)
• maxmemory-samples: 10
• reserved-memory: 2500000000
• Comprobando el comando INFO en la instancia, veo mem_fragmentation_ratioentre 1.00 y 1.05

Nos hemos puesto en contacto con el soporte de AWS y no obtuvimos muchos consejos útiles: sugirieron aumentar aún más la memoria reservada (el valor predeterminado es 0 y tenemos 2,5 GB reservados). No tenemos réplicas o instantáneas configuradas para esta instancia de caché, por lo que creo que no deberían estar ocurriendo BGSAVE y causar un uso adicional de memoria.

El maxmemorylímite de un caché.r3.2xlarge es 62495129600 bytes, y aunque alcanzamos nuestro límite (menos nuestro reserved-memory) rápidamente, me parece extraño que el sistema operativo host se sienta presionado para usar tanto intercambio aquí, y tan rápido, a menos que Amazon ha aumentado la configuración de intercambio de SO por alguna razón. ¿Alguna idea de por qué estaríamos causando tanto uso de intercambio en ElastiCache / Redis, o una solución que podríamos intentar?

Como nadie más tenía una respuesta aquí, pensé que compartiría lo único que nos ha funcionado. Primero, estas ideas no funcionaron:

• tipo de instancia de caché más grande: tenía el mismo problema en instancias más pequeñas que el caché.r3.2xlarge que estamos usando ahora
• ajustes maxmemory-policy: ni volatile-lru ni allkeys-lru parecían hacer ninguna diferencia
• subir maxmemory-samples
• subir reserved-memory
• obligando a todos los clientes a establecer un tiempo de vencimiento, generalmente a lo sumo 24 horas con unas pocas llamadas raras que permiten hasta 7 días, pero la gran mayoría de las personas que llaman usan el tiempo de vencimiento de 1-6 horas.

Esto es lo que finalmente ayudó, mucho: ejecutar un trabajo cada doce horas que ejecuta un ESCANEADO sobre todas las teclas en bloques ( COUNT) de 10,000. Aquí está el BytesUsedForCache de esa misma instancia, todavía una instancia cache.r3.2xlarge con un uso aún mayor que antes, con la misma configuración que antes:

Las caídas de diente de sierra en el uso de la memoria corresponden a los tiempos del trabajo cron. Durante este período de dos semanas, nuestro uso de intercambio ha alcanzado un máximo de ~ 45 MB (máximo de ~ 5 GB antes de reiniciar antes). Y la pestaña Eventos de caché en ElastiCache informa que no hay más eventos de reinicio de caché.

Sí, esto parece un error que los usuarios no deberían tener que hacer ellos mismos, y que Redis debería ser lo suficientemente inteligente como para manejar esta limpieza por sí solo. Entonces, ¿por qué funciona esto? Bueno, Redis no hace mucho o ninguna limpieza preventiva de las claves caducadas, sino que confía en el desalojo de las claves caducadas durante los GET . O, si Redis se da cuenta de que la memoria está llena, comenzará a expulsar las claves para cada nuevo SET, pero mi teoría es que en ese momento Redis ya está manguera.

Sé que esto puede ser viejo, pero me encontré con esto en la documentación de aws.

https://aws.amazon.com/elasticache/pricing/ Afirman que el r3.2xlarge tiene 58.2gb de memoria.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html Indican que el sistema maxmemory es 62 gb (esto es cuando la política maxmemory entra en acción) y que no se puede cambiar . Parece que no importa qué con Redis en AWS intercambiaremos ...