aratak 26 июл 2016 в 00:11

Сайдкик-самоубийца

3 мин

10K

Ruby*Ruby on Rails*

+13

Комментарии 16

Fikys 26 июл 2016 в 02:06

Привет, не очень понимаю смысла статьи, если у сайдкика есть API для работы с процессами. Был бы рад, если бы ты объяснил в чем преимущество твоего подхода :)

aratak 26 июл 2016 в 11:03

Я немного сбил вас с толку, называя запущенный воркер "сайдкик-процессом". Воркер работает внутри настоящего сайдкик-процесса и всю статью я пытаюсь остановить запущенный воркер, а процесс не трогать, так как ему еще предстоит обработать новые воркеры. API показывает как работать с запущенными процессами сайдкика, и команда #stop! останавливает весь сайдкик процесс, а не отдельно запущенный воркер.

Вот разница при работе с процессами и в моем случае.

Сначала запустим процесс и вызовем метод stop!, как это предлагают сайдкикеры.

INFO: Starting processing, hit Ctrl-C to stop
TestProcessWorker JID-e0d48711e21cd37c90e98186 INFO: start

# в этом месте я вызвал метод `stop!` на процессе из соседней вкладки

INFO: Shutting down
INFO: Terminating 49 quiet workers
INFO: Pausing up to 30 seconds to allow workers to finish...
WARN: Terminating 1 busy worker threads
WARN: Work still in progress [#<struct Sidekiq::BasicFetch::UnitOfWork queue="queue:default", message="{\"class\":\"TestProcessWorker\",\"args\":[1],\"retry\":false,\"queue\":\"default\",\"jid\":\"e0d48711e21cd37c90e98186\",\"created_at\":1469519195.722636,\"enqueued_at\":1469519195.722796}">]
INFO: Pushed 1 messages back to Redis
TestProcessWorker JID-e0d48711e21cd37c90e98186 INFO: fail: 121.278 sec

Повторный запуск сайдкика приводит к тому, что он пытается перезапустить процессы, которые были помечены статусом "fail".

Теперь давайте используем воркера из статьи и килять будем воркер, а не процесс:

INFO: Starting processing, hit Ctrl-C to stop
TestKillerWorker JID-e0d48711e21cd37c90e98186 INFO: start

# в этом месте кладем в редис соответствующий киллер-ключ

TestKillerWorker JID-e0d48711e21cd37c90e98186 INFO: done: 0.396 sec

Во втором случае процесс готов обрабатывать следующую задачу, в отличие от первого, где он вообще выключается со всеми работающими процессами.

Dreyk 26 июл 2016 в 10:20

Килять треды — не самая лучшая затея

aratak 26 июл 2016 в 11:09

Очень рад, что вы согласны выводами статьи. К большому сожалению лучшего способа, чем килять рядом запущенный тред, который знает, что его могут в любое время кильнуть, найдено не было. Может быть есть какие-нибудь идеи?

Dreyk 26 июл 2016 в 11:14

я вначале тоже неправильно понял, что вы называете процессом.

ну я для себя решил так, что если, допустим, воркер не идемпотентный (как того прям все требуют, но мы-то знаем, что это не всегда реально), то я просто выключаю конкретно ему ретрай и просто грохаю весь процесс сайдкика

aratak 26 июл 2016 в 20:54

Выключение ретрая и убиение процесса сайдкика переводит эту джобу в состояние "fail", а хотелось бы считать это успешным завершением.

Кроме того, при обилии такого рода задач, запуск нового сайдкик-процесса с поднятием всего окружения делает это неоправданно дорогой манипуляцией.

iqiaqqivik 26 июл 2016 в 11:58

Я всегда рассуждаю так: если мне надо убить запущенный sidekiq-worker, значит я облажался с архитектурой и мне нужно подкрутить логику вокруг этого воркера, а не доставать из кармана 45-й.

aratak 26 июл 2016 в 12:18

И вы совершенно правы. В случае, описанным в статье пришлось вовсе отказаться от сайдкика.

iqiaqqivik 26 июл 2016 в 12:40

Случай в статье не описан, но я убежден, что отказ от сайдкика — такой же беспомощный костыль, как и убийство воркера.

Envek 26 июл 2016 в 20:41

Интересно, можно ли наподобие этого сделать механизм автоматического перезапуска всего процесса Sidekiq после выполнения тяжёлой по памяти задачи (чтобы вернуть память ОС, потому что та память, которую Ruby съел, он уже не отдаст до самой своей смерти)?

Сейчас у нас для этой задачи monit запряжён, рестартует sidekiq'а спустя полчаса после того, как тот станет потреблять больше полугига.

aratak 26 июл 2016 в 20:48

Для этого у сайдкика есть официальный API по работе с процессами, хотя я согласен с вами, что перезапуск извне выглядит эффективнее и надежнее.

iqiaqqivik 27 июл 2016 в 09:53

А холодный перезапуск всего юнита выглядит вообще как панацея.

iqiaqqivik 27 июл 2016 в 09:43

> та память, которую Ruby съел, он уже не отдаст до самой своей смерти
Ruby отдаст все, кроме того, что было аллоцировано под новые Ruby Heaps. Писать код так, чтобы количество отъеденных RValues (от которого напрямую зависит размер локального хипа) — довольно просто, при некоторой сноровке.

Dreyk 27 июл 2016 в 10:54

по моим наблюдениям, со временем руби-процесс таки отдает практически все назад. Можете подсказать, где толково описано про RValues и Heap?

iqiaqqivik 27 июл 2016 в 12:27

https://ruby-hacking-guide.github.io/gc.html — про gc
https://blog.engineyard.com/2010/mri-memory-allocation-a-primer-for-developers — тоже полезно, чуть более прикладной вариант
http://stackoverflow.com/a/20608455/2035262 — совсем вкратце, мой ответ на SO про это

Надо бы заметку написать, но руки не доходят.

Nakilon 1 авг 2016 в 19:07

> сайдкик-процесс должен сам себя убивать, а мы лишь должны сказать ему когда это сделать

pipes? sockets? mmap?

> И в случае с руби лучше всего воспользоваться внешним механизмом передачи сообщений и редис в данном случае подойдет идеально.
> author: CTO at…

Рельсисты такие рельсисты…

Зарегистрируйтесь на Хабре, чтобы оставить комментарий