Eu tenho uma máquina rodando Debian por um longo tempo (talvez 7 anos) 24/7. Duas semanas atrás eu decidi mudar a localização do servidor e atualizar para o Debian Jessie (estava rodando wheezy).
Tudo foi ótimo, 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!
Eu tenho uma máquina virtual em execução no servidor e o pacote chega bem, sem nenhum atraso. Eu testei portas diferentes no servidor, como 80, 443, 9000, etc e todo o tempo limite. No servidor por exemplo rodando ssh, se eu tentar um comando durante o tempo limite, por exemplo digitando 3 vezes "ls", depois que ele recuperar ele irá receber o 3 "ls" e executar.
Eu verifiquei os registros 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 ssh no servidor, e executando ping 8.8.8.8 (ou provavelmente qualquer comando que texto de saída) quando o timeout começar a acontecer, ainda posso ver 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 de 120GB.
os 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
Depois de usar o iostat e o iotop para diagnóstico, descobri que o problema estava no redis-server que era a persistência do banco de dados no disco e por causa do crescimento do banco de dados. alguma razão, o escrito em disco bloqueia o tráfego de rede e essa foi a razão para o tempo limite (gravação de massa em disco).
Como eu não preciso de persistência no disco, eu o desabilitei e agora funciona muito bem de novo, mas não sei por que o servidor-redis se comporta dessa maneira.