❤️💎 WorkerKiller 💎❤️

Утечки ресурсов и/или памяти, а также её фрагментация являются обычной проблемой для всех языков программирования. Неважно есть там сборщик мусора или нет, компилируемый язык или интерпретируемый. Ruby не является исключением и сегодня мы немного поговорим про эти проблемы, варианты их решения и даже напишем своё собственное.

Перепост статьи со старой площадки

Проблема может появиться и появляется когда у нас есть процесс, запущенный длительное время и выполняющий много разнообразной работы. Большинство этих проблем связаны с ошибками в коде при которых код продолжает вполне корректно выполнять свою бизнес-функцию. Их не всегда легко найти и исправить. А вот фрагментация памяти поджидает нас немного с другой стороны и даже корректный код может постепенно накапливать фрагментированную память. В мире Rails процессами, которые попадают под категорию “долгоиграющих”, являются, собственно, веб-сервер и различные менеджеры фоновых/отложенных задач — DelayedJob, Sidekiq и пр. Вот про них дальше и поговорим.

Веб-сервер

Самым надёжным способом “отдать” память системе является завершение процесса. Для многих серверов уже написаны специальные плагины/расширения, которые решают проблемы с памятью путем периодического перезапуска рабочих процессов (puma, unicorn), а в Phusion Passenger это встроено в сам сервер. У нас в RNDSOFT именно “пассажир” является основным веб-сервером, на котором крутятся все наши Rails-приложения. Кому интересно более детально посмотреть на существующие решения, добро пожаловать:

• https://about.gitlab.com/blog/2015/06/05/how-gitlab-uses-unicorn-and-unicorn-worker-killer/
• https://github.com/schneems/puma_worker_killer
• https://docs.gitlab.com/ee/administration/operations/sidekiq_memory_killer.html

Алгоритмы, используемые в таких “перезапускальщиках” в основном базируются на двух критериях — число обработанных запросов и потреблённая процессом память. С числом запросов всё просто — в каждом процессе считаем каждый запрос и по достижении лимита — перезапускаемся. А вот с памятью все обстоит куда хуже — потреблённую процессом память можно посчитать только приблизительно и Passenger предлагает такой функционал только в Enterprise версии.

Менеджер фоновых задач

Как-то так получилось, что я являюсь ярым евангелистом DelayedJob, а точнее ActiveJob(чтоб в случае проблем с производительностью можно было перебраться “на этот ваш сайдкик” без проблем). На самом деле нет особой разницы какой именно инструмент использовать — принцип решения нашей проблемы от этого не меняется — перезапуск процесса. Для Sidekiq уже есть решение, а для DelayedJob еще нет!

Внимательно посмотрев и подумав над ситуацией мы решили написать своё небольшое решение для нашего любимого веб-сервера и моего любимого DelayedJob и назвали его WorkerKiller — встречайте!

Как сделать роскошный велосипед?

Начинается всё с middleware, который выполняет анализ критериев, необходимых для перезапуска с помощью переданной стратегии.

Если запросы считать весьма дёшево с точки зрения CPU, то с памятью сложнее. Однако нам не нужно чётко укладываться в лимиты — ничего страшного, если наше приложение обработает на несколько запросов больше, чем мы ограничили или отъест немного больше памяти перед перезапуском, поэтому расчет памяти будем делать “периодически" — с этим нам поможет Limiter.

Теперь про сам перезапуск — нам нужен Killer. Сначала мы пошли по пути unicorn — процесс посылал себе SIGTERM. При небольшой загрузке все было хорошо — процесс завершался, а Passenger Master Process запускал новый ему на замену. Но при тестировании и бенчмаркинге Яндекс Танком оказалось, что при этом теряются запросы, находящиеся “inflight” между пассажиром и завершённым процессом. Немного покопав документацию, был найден способ завершать процесс корректно:

passenger-config detach-process <PID>

При этом нет абсолютно никакой просадки производительности, даже если мы шлем 500 запросов в секунду, а рестартуем через каждые 100. Это происходит потому что Passenger очень качественно обрабатывает перезапуск — сначала он запускает новый процесс-обработчик, потом останавливает выделение запросов старому, дожидается обработки всей его очереди и только потом завершает процесс.

Разряд!

С веб-сервером, кажется, разобрались, дальше - DelayedJob. У него примитивная система плагинов, основанная на хуках, но вот передавать параметры в плагины не очень удобно.

Разряд!

Результат

Что мы получили в конце? Прежде всего мы запилили свой гем WorkerKiller 💪 Кроме того, получили простой и надёжный механизм решения проблем с памятью через перезапуск процессов. Тут следует оговориться — если у вас в приложении есть утечки памяти, то такой подход замаскирует проблему не решив её окончательно, и проблема всё равно вас догонит и наподдаст вам в виде падения производительности, чрезмерной прожорливости приложения или редких плавающих багов. Так что если вы знаете что у вас есть серьёзные утечки — займитесь профилированием, а не тушите огонь пирогами.

Ссылки

Много всяких интересных ссылок, поэтому решил привести их в конце:

• Про Giltab и Unicorn killer
• Про Gitlab и Sidekiq killer
• Killer для puma
• Про то как считать память в Linux — только для настоящих мужиков
• Killer для unicorn — он был первым!
• Как дебажить утечки в Ruby