Redis problema de conexão

Question

No momento, estamos passando por muitos erros do Redis com a mensagem

Unable to connect: read error on connection, trying next server

Nós rodamos Redis no FreeBSD usando PHP Redis e nós temos dificuldade em reproduzir o erro no Ubuntu, então isso pode ser uma dica. Há um longo problema sobre o assunto no github .

Basicamente, obtemos um soquete do sistema operacional com uma chamada para connect(host, port, timeout) no phpredis, mas quando fazemos um select(db_index) , obtemos uma exceção. Poderia haver um problema com a persistência? Eu assumo que a conexão não faz nada no fundo e selecione tenta acessar a conexão, que está realmente fechada.

Não nos deparamos com um tempo limite. Tentamos ajustar o TIME_WAIT sem sucesso.

Alguma outra ideia de onde o problema pode vir? Qual é a melhor maneira de rastrear o problema? dtrace talvez?

Atualizar

No momento, estamos analisando nossas configurações de BGSAVE. Curiosamente, leva meio segundo e mais para criar uma bifurcação para o processo que grava regularmente os dados no disco (persistência) e talvez os redis não possam responder às solicitações connect() durante esse período de tempo.

    

Answer 1

Reduzimos a taxa de erro em 90% com o seguinte comando redis :

CONFIG SET save ""

Isso desabilita BGSAVE, que regularmente armazena todas as alterações do banco de dados no disco. A razão para os erros de conexão provavelmente vem de uma operação fork() de bloqueio do processo principal do redis para iniciar o processo BGSAVE.

O redis.conf diz:

# Redis may block too long on the fsync() call. Note that there is no fix for
# this currently, as even performing fsync in a different thread will block
# our synchronous write(2) call.

Veja também como o mecanismo é implementado com um simples fork() aqui . Pensamos em usar um servidor de redis dedicado do nosso pool, que será responsável pelas operações do BGSAVE e apenas usar os outros para leitura / escrita.

No chat do IRC, parece que algumas outras empresas tiveram o mesmo erro. O Bump também estava usando um sistema mestre / escravo. O escravo não aceita conexões e está lá apenas para persistir os dados (veja a discussão sobre hackernews aqui )

Hulu diz o seguinte: "Para manter o desempenho consistente nos fragmentos, desativamos a gravação no disco em todos os shards, e temos um cron job que é executado às 4 da manhã todos os dias executando um comando" BGSAVE "em cada instância individual." ( veja aqui )

Editar:

Acontece que isso foi apenas uma correção temporária. A carga aumentou e voltamos às altas taxas de erro. No entanto, estou bastante confiante de que uma operação em segundo plano (por exemplo, um fork ou um processo em segundo plano de execução curta) está causando os erros, pois as mensagens de erro sempre aparecem em blocos.

Edit2:

Como o Redis é single-threaded, sempre fique de olho nas operações de longa duração, pois elas bloqueiam todo o resto. Um exemplo é o comando keys * . Evite e use scan