Утечки ресурсов и/или памяти, а также её фрагментация являются обычной проблемой для всех языков программирования. Неважно есть там сборщик мусора или нет, компилируемый язык или интерпретируемый. Ruby не является исключением и сегодня мы немного поговорим про эти проблемы, варианты их решения и даже напишем своё собственное.
Проблема может появиться и появляется когда у нас есть процесс, запущенный длительное время и выполняющий много разнообразной работы. Большинство этих проблем связаны с ошибками в коде при которых код продолжает вполне корректно выполнять свою бизнес-функцию. Их не всегда легко найти и исправить. А вот фрагментация памяти поджидает нас немного с другой стороны и даже корректный код может постепенно накапливать фрагментированную память. В мире Rails процессами, которые попадают под категорию “долгоиграющих”, являются, собственно, веб-сервер и различные менеджеры фоновых/отложенных задач — DelayedJob, Sidekiq и пр. Вот про них дальше и поговорим.
Внимательно посмотрев и подумав над ситуацией мы решили написать своё небольшое решение для нашего любимого веб-сервера и моего любимого DelayedJobи назвали его WorkerKiller — встречайте!
Если запросы считать весьма дёшево с точки зрения CPU, то с памятью сложнее. Однако нам не нужно чётко укладываться в лимиты — ничего страшного, если наше приложение обработает на несколько запросов больше, чем мы ограничили или отъест немного больше памяти перед перезапуском, поэтому расчет памяти будем делать “периодически" — с этим нам поможет Limiter.
Теперь про сам перезапуск — нам нужен Killer. Сначала мы пошли по пути unicorn — процесс посылал себе SIGTERM. При небольшой загрузке все было хорошо — процесс завершался, а Passenger Master Process запускал новый ему на замену. Но при тестировании и бенчмаркинге Яндекс Танком оказалось, что при этом теряются запросы, находящиеся “inflight” между пассажиром и завершённым процессом. Немного покопав документацию, был найден способ завершать процесс корректно:
passenger-config detach-process <PID>
При этом нет абсолютно никакой просадки производительности, даже если мы шлем 500 запросов в секунду, а рестартуем через каждые 100. Это происходит потому что Passenger очень качественно обрабатывает перезапуск — сначала он запускает новый процесс-обработчик, потом останавливает выделение запросов старому, дожидается обработки всей его очереди и только потом завершает процесс.
Разряд!
С веб-сервером, кажется, разобрались, дальше - DelayedJob. У него примитивная система плагинов, основанная на хуках, но вот передавать параметры в плагины не очень удобно.
Разряд!
Результат
Что мы получили в конце? Прежде всего мы запилили свой гем WorkerKiller ? Кроме того, получили простой и надёжный механизм решения проблем с памятью через перезапуск процессов. Тут следует оговориться — если у вас в приложении есть утечки памяти, то такой подход замаскирует проблему не решив её окончательно, и проблема всё равно вас догонит и наподдаст вам в виде падения производительности, чрезмерной прожорливости приложения или редких плавающих багов. Так что если вы знаете что у вас есть серьёзные утечки — займитесь профилированием, а не тушите огонь пирогами.
Band-Aid on a bullet wound
Ссылки
Много всяких интересных ссылок, поэтому решил привести их в конце:
Источник статьи: https://habr.com/ru/post/554366/
Проблема может появиться и появляется когда у нас есть процесс, запущенный длительное время и выполняющий много разнообразной работы. Большинство этих проблем связаны с ошибками в коде при которых код продолжает вполне корректно выполнять свою бизнес-функцию. Их не всегда легко найти и исправить. А вот фрагментация памяти поджидает нас немного с другой стороны и даже корректный код может постепенно накапливать фрагментированную память. В мире Rails процессами, которые попадают под категорию “долгоиграющих”, являются, собственно, веб-сервер и различные менеджеры фоновых/отложенных задач — DelayedJob, Sidekiq и пр. Вот про них дальше и поговорим.
Веб-сервер
Самым надёжным способом “отдать” память системе является завершение процесса. Для многих серверов уже написаны специальные плагины/расширения, которые решают проблемы с памятью путем периодического перезапуска рабочих процессов (puma, unicorn), а в Phusion Passenger это встроено в сам сервер. У нас в компании именно “пассажир” является основным веб-сервером, на котором крутятся все наши 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
Менеджер фоновых задач
Как-то так получилось, что я являюсь ярым евангелистом 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 ? Кроме того, получили простой и надёжный механизм решения проблем с памятью через перезапуск процессов. Тут следует оговориться — если у вас в приложении есть утечки памяти, то такой подход замаскирует проблему не решив её окончательно, и проблема всё равно вас догонит и наподдаст вам в виде падения производительности, чрезмерной прожорливости приложения или редких плавающих багов. Так что если вы знаете что у вас есть серьёзные утечки — займитесь профилированием, а не тушите огонь пирогами.
Band-Aid on a bullet wound
Ссылки
Много всяких интересных ссылок, поэтому решил привести их в конце:
- Про Giltab и Unicorn killer
- Про Gitlab и Sidekiq killer
- Killer для puma
- Про то как считать память в Linux — только для настоящих мужиков
- Killer для unicorn — он был первым!
- Как дебажить утечки в Ruby
Источник статьи: https://habr.com/ru/post/554366/