Tengo una máquina ejecutando Debian durante mucho tiempo (tal vez 7 años) 24 horas al día, 7 días a la semana. Hace dos semanas decidí mover la ubicación del servidor y actualizar a Debian Jessie (estaba funcionando con sibilancias).
Todo salió genial, excepto que cada 5 o 6 minutos el servidor no responde a ninguna conexión durante unos 20 segundos.
Creé un script para verificar cuándo sucede eso, estos son los horarios:
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!
Tengo una máquina virtual ejecutándose en el servidor y el paquete llega bien, sin demora. Probé diferentes puertos en el servidor, como 80, 443, 9000, etc. y todos los tiempos de espera. En el servidor, por ejemplo, que ejecuta ssh, si intento un comando durante el tiempo de espera, por ejemplo escribiendo 3 veces "ls", después de recuperarlo recibirá los 3 "ls" y se ejecutará.
Revisé los registros en el servidor, pero no pude encontrar ninguna información relacionada con ellos.
EDITAR: dejar el ping en ejecución no muestra el tiempo de espera.
EDIT2: Ok, otra cosa extraña. Al acceder a ssh en el servidor y ejecutar ping 8.8.8.8 (o probablemente cualquier comando que genere texto) cuando comienza el tiempo de espera, aún puedo ver el resultado de texto del ping sin ningún problema, si hago CTRL+C para cancelarlo. , veo el estado mínimo/promedio/máximo del ping, pero si escribo un comando (por ejemplo, "ls"), espera hasta que el servidor esté disponible nuevamente para mostrar la lista de archivos.
EDITAR3: Entonces, puede ser algo relacionado con el disco. El sda es un Samsung SSD 840 Pro de 120 GB.
Los iostats muestran lo siguiente:
Comportamiento 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
Comportamiento de tiempo de espera:
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
Respuesta1
Después de usariostatoyiotopPara el diagnóstico, descubrí que el problema estaba en el servidor Redis, que era la persistencia de la base de datos en el disco y, debido al crecimiento de la base de datos, por alguna razón, el tráfico de red escrito en el disco bloqueó y ese fue el motivo del tiempo de espera (escritura masiva en el disco). ).
Como no necesito persistencia en el disco, lo deshabilité y ahora funciona muy bien nuevamente, pero no sé por qué el servidor Redis se comporta de esta manera.