Блог bitmanager

Отправка писем как средство для тормозов

Каковы ингридиенты нестандартного и странного глюка или поведения в IT-системах? Рецепт прост: цепочка мелких недоработок, умолчательных настроек — и вот огромный гипервизор уже тупит под тяжестью навалившейся на него беды.

Сработал у нас мониторинг на одном из серверов с уровнем iowait > 30. И, самое главное, не очень понятно, с чем этот уровень был связан, потому что никаких закономерностей появления тормозов выявить особо не удалось. Полез смотреть iotop и что там вижу? В топе какие-то процессы, пытающиеся отправить письма. Взломали?! Куда бежать?! Что блокировать?!

Ну, для начала выясняем, какой контейнер это порождает, потом идем туда. Вроде все тихо, никаких следов взлома, но в очереди всего каких-то 41000 неотправленных писем. Чищу очередь, перезапускаю postfix, начинаю разбираться, что же это за послания такие. Все письма от крона с одной строчкой о падении линка. Ну, думаю, может, накопились за долгое время, надо понаблюдать и оставляю все, как есть. А через сутки снова тормоза и уже 144000 писем в очереди. Ну, нет, тут точно что-то аномальное. Копаем глубже. Находим задачу, которая порождает письмо и все становится на свои места.

Задача работает по крону раз в минуту. Проверяет и восстанавливает стандартную таблицу маршрутизации, если она поломается. А у нас как раз за три дня до этого упал один канал и, соответственно, один из маршрутов невозможно было восстановить. О чем сообщал ip route. А сознательный крон бережно собирал stderr и прилежно пытался его отправить. А так как он был настроен на локальный домен, которого не существовало, то отправка естественно обламывалась. А задача выполнялась раз в минуту… Ну, вы понимаете. В итоге, все кончилось хорошо. Stderr отправлен в /dev/null, очередь очищена и в мире снова покой и благоденствие.
Записки сисадмина