У меня есть машина под управлением 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» и выполнится.
Я проверил журналы на сервере, но не нашел никакой информации, связанной с ним.
РЕДАКТИРОВАТЬ: при отключении ping не отображается тайм-аут.
EDIT2: Хорошо, еще одна странная вещь. Получив доступ к ssh на сервере и запустив ping 8.8.8.8 (или, возможно, любую команду, которая выводит текст), когда начинается тайм-аут, я все равно могу без проблем просматривать текстовый вывод ping, если я нажму CTRL + C, чтобы отменить его , Я вижу минимальный / средний / максимальный статус пинга, но если я набираю команду (например, «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
После использования iostat и iotop для диагностики я обнаружил, что проблема заключалась в redis-serverе, который сохранял базу данных на диске, и из-за роста базы данных по какой-то причине записанный в диск блокирует сетевой трафик, и это было причиной тайм-аута (массовая запись на диск ).
Поскольку мне не требуется постоянство на диске, я отключил его и теперь снова отлично работает, но я не знаю, почему redis-server ведет себя таким образом.