Eu tenho uma máquina rodando Debian há muito tempo (talvez 7 anos) 24 horas por dia, 7 dias por semana. Há duas semanas decidi mudar a localização do servidor e atualizar para o Debian Jessie (estava rodando com dificuldade).
Tudo correu bem, exceto que a cada 5 ou 6 minutos o servidor não responde a nenhuma conexão por cerca de 20 segundos.
Eu criei um script para verificar quando isso acontece, aqui estão os horários:
2017-01-12 16:16:05 TIMEOUT!
2017-01-12 16:21:49 TIMEOUT!
2017-01-12 16:27:32 TIMEOUT!
2017-01-12 16:33:13 TIMEOUT!
2017-01-12 16:39:01 TIMEOUT!
...
2017-01-12 17:07:59 TIMEOUT!
2017-01-12 17:13:47 TIMEOUT!
2017-01-12 17:19:25 TIMEOUT!
Tenho uma máquina virtual rodando no servidor e o pacote chega bem, sem demora. Testei diferentes portas no servidor, como 80, 443, 9000, etc e todos os tempos limite. No servidor por exemplo rodando ssh, se eu tentar um comando durante o timeout, por exemplo digitando 3 vezes "ls", após ele recuperar ele receberá os 3 "ls" e executará.
Verifiquei os logs no servidor, mas não consegui encontrar nenhuma informação relacionada a ele.
EDIT: Deixar o ping em execução não mostra o tempo limite.
EDIT2: Ok, outra coisa estranha. Acessando o ssh no servidor e executando o ping 8.8.8.8 (ou provavelmente qualquer comando que produza texto) quando o tempo limite começar a acontecer, ainda posso visualizar a saída de texto do ping sem nenhum problema, se eu fizer CTRL+C para cancelá-lo , vejo o status min/avg/max do ping, mas se eu digitar um comando (por exemplo "ls") ele aguarda até que o servidor esteja disponível novamente para exibir a lista de arquivos.
EDIT3: Então, pode ser algo relacionado ao disco. O sda é um Samsung SSD 840 Pro 120GB.
iostats mostram o seguinte:
Comportamento normal:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 2.00 0.00 20.00 20.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-0 0.00 0.00 0.00 2.00 0.00 20.00 20.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 2.00 0.00 20.00 20.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Comportamento de tempo limite:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 136.00 0.00 69124.00 1016.53 127.69 1053.93 0.00 1053.93 7.35 100.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 16.00 0.00 18.50 0.00 540.00 58.38 0.10 5.51 0.00 5.51 1.19 2.20
dm-0 0.00 0.00 0.00 1.00 0.00 4.00 8.00 521.34 363490.00 0.00 363490.00 1000.00 100.00
dm-1 0.00 0.00 0.00 1.00 0.00 4.00 8.00 521.35 363492.00 0.00 363492.00 1000.00 100.00
dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Responder1
Depois de usariostateiotoppara diagnóstico descobri que o problema estava no servidor redis que era a persistência do banco de dados no disco, e por causa do crescimento do banco de dados, por algum motivo o tráfego de rede gravado no disco bloqueava e esse era o motivo do tempo limite (gravação em massa no disco ).
Como não preciso de persistência no disco, desativei-o e agora funciona muito bem novamente, mas não sei por que o redis-server se comporta dessa maneira.