[Ruby, Ruby on Rails] WorkerKiller
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Утечки ресурсов и/или памяти, а также её фрагментация являются обычной проблемой для всех языков программирования. Неважно есть там сборщик мусора или нет, компилируемый язык или интерпретируемый. Ruby не является исключением и сегодня мы немного поговорим про эти проблемы, варианты их решения и даже напишем своё собственное.
Проблема может появиться и появляется когда у нас есть процесс, запущенный длительное время и выполняющий много разнообразной работы. Большинство этих проблем связаны с ошибками в коде при которых код продолжает вполне корректно выполнять свою бизнес-функцию. Их не всегда легко найти и исправить. А вот фрагментация памяти поджидает нас немного с другой стороны и даже корректный код может постепенно накапливать фрагментированную память. В мире 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
Алгоритмы, используемые в таких “перезапускальщиках” в основном базируются на двух критериях — число обработанных запросов и потреблённая процессом память. С числом запросов всё просто — в каждом процессе считаем каждый запрос и по достижении лимита — перезапускаемся. А вот с памятью все обстоит куда хуже — потреблённую процессом память можно посчитать только приблизительно и 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 ? Кроме того, получили простой и надёжный механизм решения проблем с памятью через перезапуск процессов. Тут следует оговориться — если у вас в приложении есть утечки памяти, то такой подход замаскирует проблему не решив её окончательно, и проблема всё равно вас догонит и наподдаст вам в виде падения производительности, чрезмерной прожорливости приложения или редких плавающих багов. Так что если вы знаете что у вас есть серьёзные утечки — займитесь профилированием, а не тушите огонь пирогами.
Band-Aid on a bullet woundСсылкиМного всяких интересных ссылок, поэтому решил привести их в конце:
- Про Giltab и Unicorn killer
- Про Gitlab и Sidekiq killer
- Killer для puma
- Про то как считать память в Linux — только для настоящих мужиков
- Killer для unicorn — он был первым!
- Как дебажить утечки в Ruby
===========
Источник:
habr.com
===========
Похожие новости:
- [Open source, Java, ERP-системы, CRM-системы, 1С] Как мы сделали программу лояльности для 300 магазинов «У Палыча» на open source iDempiere ERP/CRM
- [Data Mining, Big Data, Бизнес-модели] Бизнес-аналитика в управлении рисками: Некоторые последние достижения (2014 год) (перевод)
- [Angular] Отслеживание состояния компонентов в Angular c помощью ng-set-state (перевод)
- [Анализ и проектирование систем, Управление продуктом] 4 вида аналитики, в которых нужно разбираться продуктовой команде
- [Управление разработкой, Управление проектами, Управление продуктом, DevOps] Практика создания единого шаблона проектов на базе Azure DevOps (TFS)
- [IT-инфраструктура, Service Desk, Управление проектами, Карьера в IT-индустрии] Как мы развернули круглосуточную техническую поддержку с нуля всего за 1 год
- [Lua, Умный дом, Интернет вещей, Tarantool] Чем Tarantool круче Redis'а для IoT-сервисов
- [Интервью] «Почему так сложно писать код?» Григорий Петров о физиологии мозга и управлении личной и командной эффективностью
- [Ruby, Ruby on Rails, Google Cloud Platform] Веб-клиент Google Cloud Text to Speech за завтраком в бастионе Сен-Жерве
- [Управление проектами, Управление продуктом, Управление персоналом] Основные проблемы в командах разработки и их решения
Теги для поиска: #_ruby, #_ruby_on_rails, #_delayed_job, #_passenger, #_phusion_passenger, #_memory_leak, #_ruby_on_rails, #_gem, #_ruby, #_ruby_on_rails
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:35
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Утечки ресурсов и/или памяти, а также её фрагментация являются обычной проблемой для всех языков программирования. Неважно есть там сборщик мусора или нет, компилируемый язык или интерпретируемый. Ruby не является исключением и сегодня мы немного поговорим про эти проблемы, варианты их решения и даже напишем своё собственное.  Проблема может появиться и появляется когда у нас есть процесс, запущенный длительное время и выполняющий много разнообразной работы. Большинство этих проблем связаны с ошибками в коде при которых код продолжает вполне корректно выполнять свою бизнес-функцию. Их не всегда легко найти и исправить. А вот фрагментация памяти поджидает нас немного с другой стороны и даже корректный код может постепенно накапливать фрагментированную память. В мире Rails процессами, которые попадают под категорию “долгоиграющих”, являются, собственно, веб-сервер и различные менеджеры фоновых/отложенных задач — DelayedJob, Sidekiq и пр. Вот про них дальше и поговорим.Веб-серверСамым надёжным способом “отдать” память системе является завершение процесса. Для многих серверов уже написаны специальные плагины/расширения, которые решают проблемы с памятью путем периодического перезапуска рабочих процессов (puma, unicorn), а в Phusion Passenger это встроено в сам сервер. У нас в компании именно “пассажир” является основным веб-сервером, на котором крутятся все наши Rails-приложения. Кому интересно более детально посмотреть на существующие решения, добро пожаловать:
passenger-config detach-process <PID>
 Band-Aid on a bullet woundСсылкиМного всяких интересных ссылок, поэтому решил привести их в конце:
=========== Источник: habr.com =========== Похожие новости:
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:35
Часовой пояс: UTC + 5