Внедрение Docker вместе с его контейнерной структурой крайне полезно в условиях возросших современных требований к производительности. Но что если даже этот инструмент не хочет работать должным образом, что может отразиться на безопасности сервера? В этой статье мы поговорим о том, что нужно предпринять, если тормозит Docker.
Допустим, вы решили завернуть в контейнер ряд приложений, с помощью которых хотели повысить производительность системы, также прибегнув к Kubernetes. Но в результате вы получили сильную просадку в быстродействии.
Все становится еще запутаннее после того, как проведете диагностику аппаратной части и убедитесь в том, что имеющихся ресурсов хватает с головой. Но простой запуск хотя бы 4-х программ одновременно практически губит всю систему, повышая время ожидания на запросы до нескольких секунд!
В случае, если тормозит Docker, причина может скрываться в самой конфигурации. Ошибки могли быть допущены еще при разворачивании с приложения. Если же на первый взгляд все выглядит нормально, то стоит провести углубленный тест с помощью стороннего ПО, либо набора инструментов от Sysbench.
После того, как все механические детали будут продиагностированы, а изъяны все еще не найдены, обратите внимание изоляцию самого контейнера.
Приведем простой пример: при запуске даже нескольких легких приложений под управлением Docker можно получить не просто сильное снижение производительности, но и полный сбой работы всей системы.
При чем, это не зависит от количества выделяемых ресурсов под определенный процесс. Итак, если тормозит Docker в этом случае, значит найти проблему можно отталкиваясь от двух вещей:
- Неполадки внутри ядра ОС Linux, связанные с особенностью структуры кэша-объектов;
- Проведение отладки внутри ядра с помощью команды perf.
Немного о команде perf. Как ни странно, мало кто использует данное решение, сталкиваясь с проблемой в Docker. Оно было создано с появлением версии 2.6.31, а представляет из себя достаточно универсальный инструмент для диагностики ядра системы.
С помощью perf можно провести диагностику системы, а также составить профиль для использования конкретным пользователем. Все предусмотренные ОС счетчики будут перестроены с учетом введения нужного профиля.
С инструментом разобрались, самое время пустить его в ход и найти проблему!
Запустив perf, вы можете столкнуться с весьма неожиданной для себя картиной. На скриншоте вы можете увидеть, как команда отработала на протяжении 10 секунд и представила данные в виде таблицы: слева находится информация о работе на железе, а справа – непосредственно в контейнере.
Обратите внимание, что начальные обращения в правой части направлены к ядру системы, то есть на распределение пространства. Все остальное, что отчетливо видно в левой стороне, используется для исполнения процессов в пользовательском пространстве. С первого взгляда, все нормально. А теперь посмотрите на вызов posix_fadvise. Как видите, существенную долю времени занимает именно он.
posix_fadvise() – это запрос, который составляет шаблон для дальнейшего обращения к одному и тому же файлу системы. С точки зрения быстродействия и повышения производительности, это очень выгодное решение.
С одной стороны, он не должен вызывать никаких проблем. Но стоит проанализировать процесс глубже, вы сможете заметить следующее:
Перед вами библиотека glog, которая использовалась пользователем для его собственных нужд. То есть, она является сторонней. Одна единственная строчка LogFileObject::Write тормозит Docker из-за постоянного вызова при запуске нового события. Очевидно, что запись в лог проводится регулярно в любой системе, поэтому неудивительно, что производительность снизилась. Решение проблемы простое: отключаем fadvise с помощью параметра —drop_log_memory=false:
В результате, вы можете получить рост производительности в разы, снизив время ожидания с пары секунд до нескольких миллисекунд.
Итог
Чтобы не допустить банальную ошибку, с которой мы столкнулись в данном примере, стоит помнить о простых правилах во время использования Docker. Во-первых, все контейнеры потребляют ресурсы всей аппаратной части, включая ресурсы ядра. А значит, нужно регулярно проводить диагностику именно этой части. И тут мы переходим к второму правилу: чтобы упростить себе жизнь используйте для отладки «perf»!
Стабильная работа