Estratégias de depuração de cpu do servidor Redis

3

Recentemente, notamos picos de CPU em nosso ambiente de produção causados por redis, que podem ser vistos abaixo:

Paracombateresseproblema,eureinicieioservidorredisduasvezespordia:(oqueobviamenteestálongedoideal.Eugostariadeidentificaracausaraiz.

Aquiestãoalgumascoisasqueanaliseiatéagora:
1)Verifiqueasanomaliasnoarquivodelogredis.Oseguinteparecesuspeito:

2)Pesquisamososlogsdeacessonginxparaverseestamostendoumtráfegoexcepcionalmentealto.Arespostaénão.

3)ANewRelicrevelouqueaediçãocomeçouem21denovembro,16'(cercadeummêsatrás),masnenhumcódigofoilançadoporvoltadessaépoca.

Aquiestãoalgunsdetalhessobrenossaconfiguração:

ServidorRedis:Redisserverv=2.8.17sha=00000000:0malloc=jemalloc-3.6.0bits=64build=64a9cf396cbcc4c7

PHP:5.3.27comfpm

ConfiguraçãodoRedis:

daemonizeyespidfile/var/run/redis/redis.pidport6379timeout0tcp-keepalive0loglevelnoticelogfile/var/log/redis/redis.logsyslog-enabledyesdatabases16save9001save30010save6010000stop-writes-on-bgsave-errornordbcompressionyesrdbchecksumyesdbfilenameredis.rdbdir/var/lib/redis/slave-serve-stale-datayesslave-read-onlyyesrepl-disable-tcp-nodelaynoslave-priority100maxmemory15GBappendonlynoappendfsynceverysecno-appendfsync-on-rewritenoauto-aof-rewrite-percentage100auto-aof-rewrite-min-size64mblua-time-limit5000slowlog-max-len128notify-keyspace-events""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes
include /etc/redis/conf.d/local.conf

Framework: Magento 1.7.2 com Cm_Cache_Backend_Redis

Por favor, deixe-me saber se, dadas as informações acima, há algo que eu posso fazer para mitigar o alto uso da CPU.

    
por dipole_moment 12.12.2016 / 21:49

1 resposta

3

ATUALIZAÇÃO MUITO IMPORTANTE :

Seu servidor pode ter sido invadido. Não é o redis que está causando o alto uso da CPU, mas um comando separado chamado yam (dê uma olhada na extremidade direita do seu htop, eu perdi na primeira vez). O comando yam é usado em uma exploração bem conhecida de redis e geralmente resulta em alto uso da CPU. Você deseja verificar novamente para garantir que seu servidor esteja seguro.

Aqui estão alguns artigos e links aos quais você pode se referir se quiser saber mais sobre a vulnerabilidade e como se proteger:

  • link (um exemplo de script de corte de senhora, nos comentários você pode ver onde uma versão original baixou o inhame)
  • link (uma tradução de um artigo chinês sobre o exploit e como explorá-lo)
  • link (outro post chinês mais focado nos próximos passos e limpeza)
  • link uma postagem no blog de opinião sobre segurança de redis descrevendo os meios de invasão que podem ter sido a fonte de ingresso no servidor do OP
  • link (uma visão geral de quantos servidores foram afetados pela falta de segurança de acesso )
  • link (um tópico relatando o sabor do bitcoin do hack)

Aqui está minha lista de verificação para problemas de desempenho do magento / redis, er:

  1. Verifique se você está em uma nova versão do redis, como 3.2, eu pessoalmente prefiro o redis32u do repositório do IUS se estiver no CentOS.
  2. Verifique o tamanho do banco de dados do redis, ele deve estar em /var/lib/redis e verifique se ele é relativamente pequeno.
  3. Verifique se você tem ram suficiente para redis. Você especificou um maxmemory de 15 GB, o que é realmente um exagero para o magento. Eu normalmente uso algo mais próximo de 256mb . Se você está usando tanto o redis (!!!!!!), você provavelmente tem outros problemas na sua pilha magento.
  4. Verifique se você definiu a configuração de supercomprometimento vm em syscntl. link (veja este link para mais detalhes sobre o que você precisa)
  5. Verifique se você tem limites de arquivos abertos suficientes para lidar com o número de conexões para redis.

De modo geral, o arquivo de registro não é suspeito porque suas configurações de salvamento de redis informam ao redis para salvar a cada minuto se houver > 10000 escrever, a cada cinco minutos, se houver > 10 escreve, e a cada 15 minutos, se houver > 1 escreva. Por isso, é essencialmente persistir a informação de volta ao disco a cada minuto, o que não deve ser tão pesado.

    
por 14.12.2016 / 05:39