Время ожидания сервера Debian истекает каждые 5/6 минут на ~20 секунд

Время ожидания сервера Debian истекает каждые 5/6 минут на ~20 секунд

У меня есть машина, на которой Debian работает уже долгое время (может быть, лет 7) 24/7. Две недели назад я решил переместить сервер и обновиться до Debian Jessie (работал wheezy).

Все прошло отлично, за исключением того, что каждые 5 или 6 минут сервер не отвечает ни на одно соединение в течение примерно 20 секунд.

Я создал скрипт, чтобы проверить, когда это произойдет, вот время:

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!

У меня есть виртуальная машина, запущенная на сервере, и пакеты доходят до нее нормально, без задержек. Я тестировал разные порты на сервере, например, 80, 443, 9000 и т. д., и все таймауты. Например, на сервере, запущенном ssh, если я попробую команду во время таймаута, например, набрав 3 раза "ls", после восстановления он получит 3 "ls" и выполнится.

Я проверил логи на сервере, но не нашел никакой информации по этому поводу.

EDIT: Если оставить ping запущенным, тайм-аут не отображается.

EDIT2: Хорошо, еще одна странная вещь. Заходя по ssh на сервер и запуская ping 8.8.8.8 (или, возможно, любую команду, которая выводит текст), когда начинается тайм-аут, я все еще могу просматривать текстовый вывод ping без каких-либо проблем, если я нажимаю CTRL+C, чтобы отменить его, я вижу мин/средн/макс статус ping, но если я ввожу команду (например, "ls"), он ждет, пока сервер снова не станет доступен, чтобы отобразить список файлов.

EDIT3: Так, это может быть связано с диском. SDA — это Samsung SSD 840 Pro 120 ГБ.

iostats показывает следующее:

Нормальное поведение:

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

Поведение тайм-аута:

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

решение1

После использованияiostatииотопВ ходе диагностики я обнаружил, что проблема была в Redis-сервере, который сохранял базу данных на диске, и из-за роста базы данных по какой-то причине записанные на диск данные блокировали сетевой трафик, что и было причиной тайм-аута (массовая запись на диск).

Поскольку мне не нужно сохранение на диске, я отключил его и теперь все снова работает отлично, но я не знаю, почему redis-server ведет себя таким образом.

Связанный контент