Evitare lo scambio su ElastiCache Redis

Abbiamo riscontrato problemi con lo scambio di istanze di ElastiCache Redis. Amazon sembra avere un rozzo monitoraggio interno in atto che nota picchi di utilizzo degli swap e riavvia semplicemente l'istanza di ElastiCache (perdendo così tutti i nostri oggetti memorizzati nella cache). Ecco il grafico di BytesUsedForCache (linea blu) e SwapUsage (linea arancione) sulla nostra istanza ElastiCache negli ultimi 14 giorni:

Puoi vedere il modello di crescente utilizzo degli swap che sembra innescare i riavvii della nostra istanza ElastiCache, in cui perdiamo tutti i nostri elementi memorizzati nella cache (BytesUsedForCache scende a 0).

La scheda "Eventi cache" della nostra dashboard ElastiCache contiene voci corrispondenti:

ID sorgente | Digita | Data | Evento

cache-istanza-id | cluster di cache | Mar 22 set 07:34:47 GMT-400 2015 | Nodo cache 0001 riavviato

cache-istanza-id | cluster di cache | Mar 22 set 07:34:42 GMT-400 2015 | Errore durante il riavvio del motore della cache sul nodo 0001

cache-istanza-id | cluster di cache | Dom 20 Set 11:13:05 GMT-400 2015 | Nodo cache 0001 riavviato

cache-istanza-id | cluster di cache | Gio 17 set 22:59:50 GMT-400 2015 | Nodo cache 0001 riavviato

cache-istanza-id | cluster di cache | Mer 16 set 10:36:52 GMT-400 2015 | Nodo cache 0001 riavviato

cache-istanza-id | cluster di cache | Mar 15 set 05:02:35 GMT-400 2015 | Nodo cache 0001 riavviato

(tagliare le voci precedenti)

Amazon afferma :

SwapUsage : nell'uso normale, né Memcached né Redis devono eseguire swap

Le nostre impostazioni pertinenti (non predefinite):

• Tipo di istanza: cache.r3.2xlarge
• maxmemory-policy: allkeys-lru (in precedenza avevamo usato la volatile-lru predefinita senza troppe differenze)
• maxmemory-samples: 10
• reserved-memory: 2500000000
• Controllando il comando INFO sull'istanza, vedo mem_fragmentation_ratiotra 1.00 e 1.05

Abbiamo contattato il supporto AWS e non abbiamo ricevuto molti consigli utili: hanno suggerito di aumentare ulteriormente la memoria riservata (il valore predefinito è 0 e abbiamo riservato 2,5 GB). Non abbiamo repliche o snapshot impostati per questa istanza della cache, quindi credo che nessun BGSAVE dovrebbe verificarsi e causare ulteriore utilizzo della memoria.

Il maxmemorylimite di un cache.r3.2xlarge è di 62495129600 byte, e sebbene colpiamo il nostro cap (meno il nostro reserved-memory) rapidamente, mi sembra strano che il sistema operativo host si senta pressato per usare così tanto swap qui, e così rapidamente, a meno che Amazon ha migliorato le impostazioni di swappiness del sistema operativo per qualche motivo. Qualche idea sul perché dovremmo causare un così grande utilizzo di swap su ElastiCache / Redis o una soluzione alternativa che potremmo provare?

Dato che nessun altro ha avuto una risposta qui, ho pensato di condividere l'unica cosa che ha funzionato per noi. Innanzitutto, queste idee non hanno funzionato:

• tipo di istanza cache più grande: stava riscontrando lo stesso problema su istanze più piccole rispetto a cache.r3.2xlarge che stiamo usando ora
• ottimizzazione maxmemory-policy: né volatile-lru né allkeys-lru sembravano fare la differenza
• alzarsi maxmemory-samples
• alzarsi reserved-memory
• costringendo tutti i clienti a impostare un tempo di scadenza, generalmente al massimo 24 ore con alcuni chiamanti rari che consentono fino a 7 giorni, ma la stragrande maggioranza dei chiamanti utilizza un tempo di scadenza di 1-6 ore.

Ecco cosa alla fine ha aiutato molto: eseguire un lavoro ogni dodici ore che esegue una SCANSIONE su tutte le chiavi in ​​blocchi ( COUNT) di 10.000. Ecco il BytesUsedForCache di quella stessa istanza, ancora un'istanza cache.r3.2xlarge con un utilizzo ancora più pesante di prima, con le stesse impostazioni di prima:

Il calo dei denti di sega nell'uso della memoria corrisponde ai tempi del cron job. Durante questo periodo di due settimane il nostro utilizzo di swap è stato superato a ~ 45 MB (superato a ~ 5 GB prima del riavvio). E la scheda Eventi cache in ElastiCache non segnala più eventi di riavvio cache.

Sì, questo sembra un kludge che gli utenti non dovrebbero fare da soli e che Redis dovrebbe essere abbastanza intelligente da gestire da solo questa pulizia. Allora perché funziona? Bene, Redis non fa molto o nessuna pulizia preventiva delle chiavi scadute, basandosi invece sullo sfratto delle chiavi scadute durante i GET . Oppure, se Redis si rende conto che la memoria è piena, inizierà a sfrattare le chiavi per ogni nuovo SET, ma la mia teoria è che a quel punto Redis è già nascosto.

So che potrebbe essere vecchio ma mi sono imbattuto in questo nella documentazione di aws.

https://aws.amazon.com/elasticache/pricing/ Dichiarano che r3.2xlarge ha 58.2 gb di memoria.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html Dichiarano che il sistema maxmemory è 62 gb (questo è quando entra in gioco la politica maxmemory) e non può essere cambiata . Sembra che non importa cosa con Redis in AWS cambieremo ..