Evitando trocar no ElastiCache Redis

Question

Temos tido problemas contínuos com a troca de instâncias do ElastiCache Redis. A Amazon parece ter um monitoramento interno bruto que percebe o uso de picos de uso e simplesmente reinicia a instância do ElastiCache (perdendo todos os nossos itens em cache). Aqui está o gráfico de BytesUsedForCache (linha azul) e SwapUsage (linha laranja) em nossa instância do ElastiCache nos últimos 14 dias:

VocêpodeveropadrãodecrescimentodousodeswapparecendoacionarasreinicializaçõesdenossainstânciadoElastiCache,emqueperdemostodosositensarmazenadosemcache(BytesUsedForCachecaipara0).

Aguia"Cache Events" do nosso painel do ElastiCache tem entradas correspondentes:

Source ID | Type | Date | Event

cache-instance-id | cache-cluster | Tue Sep 22 07:34:47 GMT-400 2015 | Cache node 0001 restarted

cache-instance-id | cache-cluster | Tue Sep 22 07:34:42 GMT-400 2015 | Error restarting cache engine on node 0001

cache-instance-id | cache-cluster | Sun Sep 20 11:13:05 GMT-400 2015 | Cache node 0001 restarted

cache-instance-id | cache-cluster | Thu Sep 17 22:59:50 GMT-400 2015 | Cache node 0001 restarted

cache-instance-id | cache-cluster | Wed Sep 16 10:36:52 GMT-400 2015 | Cache node 0001 restarted

cache-instance-id | cache-cluster | Tue Sep 15 05:02:35 GMT-400 2015 | Cache node 0001 restarted

(snip earlier entries)

Reivindicações da Amazon :

SwapUsage -- in normal usage, neither Memcached nor Redis should be performing swaps

Nossas configurações relevantes (não padrão):

• Tipo de instância: cache.r3.2xlarge
• maxmemory-policy : allkeys-lru (tínhamos usado o padrão volátil-lru anteriormente sem muita diferença)
• maxmemory-samples : 10
• reserved-memory : 2500000000
• Verificando o comando INFO na instância, vejo mem_fragmentation_ratio entre 1,00 e 1,05

Contatamos o suporte da AWS e não recebemos muitos conselhos úteis: eles sugeriram aumentar ainda mais a memória reservada (o padrão é 0 e temos 2,5 GB reservados). Não temos replicação ou snapshots configurados para esta instância de cache, portanto, acredito que nenhum BGSAVE deve estar ocorrendo e causando uso adicional de memória.

O limite de maxmemory de um cache.r3.2xlarge é de 62495129600 bytes e, embora tenhamos atingido nosso limite (menos nosso reserved-memory ) rapidamente, parece estranho para mim que o sistema operacional host se sinta pressionado a usá-lo muita troca aqui, e tão rapidamente, a menos que a Amazon tenha ativado as configurações de swap do sistema operacional por algum motivo. Alguma idéia de por que estaríamos causando tanto uso de troca no ElastiCache / Redis, ou uma solução alternativa que poderíamos tentar?

    

Answer 1

Como ninguém mais teve uma resposta aqui, pensei em compartilhar a única coisa que funcionou para nós. Primeiro, essas ideias não funcionaram :

• tipo de instância de cache maior: estava tendo o mesmo problema em instâncias menores do que o cache.r3.2xlarge que estamos usando agora
• aprimorando maxmemory-policy : nem volátil-lru nem allkeys-lru pareciam fazer alguma diferença
• aumentando em maxmemory-samples
• aumentando em reserved-memory
• forçando todos os clientes a definir um horário de expiração, geralmente no máximo 24 horas, com alguns chamadores raros permitindo até 7 dias, mas a grande maioria dos chamadores usando de 1 a 6 horas de tempo de expiração.

Aqui está o que finalmente ajudou muito: executar um trabalho a cada doze horas que executa SCAN sobre todas as chaves em blocos ( COUNT ) de 10.000. Aqui está o BytesUsedForCache dessa mesma instância, ainda uma instância cache.r3.2xlarge sob uso ainda maior do que antes, com as mesmas configurações de antes:

Odentedeserracainousodememóriacorrespondeaostemposdotrabalhocron.Duranteesteperíododeduassemanas,onossousodeswapchegoua~45MB(comumrecordede~5GBantesdasreinicializaçõesanteriores).EaguiaEventosdeCachenoElastiCachenãorelatamaiseventosdeReinicializaçãodeCache.

Sim,issopareceumkludgequeosusuáriosnãodeveriamterquefazersozinhos,equeRedisdeveserinteligenteosuficienteparalidarcomessalimpezaporcontaprópria.Então,porqueissofunciona?Bem,oRedisnãofazmuitaounenhumalimpezapreventivadechavesexpiradas,emvezdissodependede despejo de chaves expiradas durante GETs . Ou, se Redis perceber que a memória está cheia, então começará a despejar as chaves para cada novo SET, mas minha teoria é que nesse momento Redis já foi escolhido.

    

Answer 2

Eu sei que isso pode ser antigo, mas eu encontrei isso na documentação do aws.

link Eles afirmam que o r3.2xlarge tem 58.2gb de memória.

link Eles afirmam que o sistema maxmemory é 62gb (isso é quando o maxmemory-policy entra em ação) e que ele não pode ser alterado. Parece que não importa o que com Redis na AWS vamos trocar ..