Демон для обработки очереди

[grigori]

Hi all.
Кто пишет демонов и разбирает очереди - расскажите, какие инструменты используете, как именно делаете?

Тут ряд вопросов.

1. PHP рожден чтобы умирать, но иногда он уподобляется Ильичу, и вместо падения просто зависает, и перестает реагировать. Как вы обрабатываете такое?

2. Работа в постоянном рабочем цикле с разными расширениями вроде ресайза фоток периодически приводит к утечкам памяти, и подобным проблемам.
Как вы следите за тем, чтобы процесс работал, и как вы его убиваете?

3. В задаче надо процессить деньги. Беру из очереди задание и ставлю ему статус "обрабатывается", чтобы другие не взяли, и текущее время. Если процесс умирает неестественно, джоба остается висеть в "обрабатывается", и непонятно сколько надо ждать, чтобы другой решился забрать задачу себе.
Как можно избежать бесполезного ожидания?

 

[fixxxer]

1. не сталкивался с таким
2. если про imagick, то проблема в нем, а не в php. Банально счетчик обработанных запросов.
3. мне всегда хватало "по таймауту". Альтернативный вариант - мониторить процессы, но не вижу смысла - процессы неестественно умирают крайне редко.

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

 

[WMix]

(2) на задачу новый процесс обычно создается, чтоб рожденный умирать умирал, демон да были моменты, вис, но уже 2 года ровненько.. ну те он нет нет перезапускается, когда деплоим (до 4х раз в неделю легко)
(3) таймаут + номер процесса

 

[grigori]

проблема 1 - это по памяти, много лет назад так было

чем запускаете процесс и перезапускаете при отмирании оного?

да, вопрос 4) как из fpm-процесса по событию на сайте дернуть демон?

 

[Adelf]

чем запускаете процесс и перезапускаете при отмирании оного?

да полно таких тулз. тот же supervisord.

4) как из fpm-процесса по событию на сайте дернуть демон?

задача в очередь ставится. которую демон возьмет. не надо веб-процессу с демоном напрямую общаться. не по-христиански это.

 

[fixxxer]

чем запускаете процесс и перезапускаете при отмирании оного?

Штатным инитом (systemd, upstart). SysV init уже почти нигде не встречается, давно, когда встречался - ставил runit (не заменяя sysv, просто сбоку).

как из fpm-процесса по событию на сайте дернуть демон?

Если это важно - как Adelf сказал, если что-то некритичное типа допускающей неточности статистики а-ля pinba - udp-пакетом.

 

[флоппик]

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

Как вы следите за тем, чтобы процесс работал, и как вы его убиваете?

Раньше штатным инитом, сейчас — supervisord (чутка удобней/универсальней деплоить конфиги для супервизора, чем штатные)

да, вопрос 4) как из fpm-процесса по событию на сайте дернуть демон?

Удп-пакетом, или нагло, сигналом (у меня в одном месте такое есть, не продакшн!)
Но в целом мы пихаем в очередь, и демон сам разбирает.
Еще из вариантов для событий (правда, между двумя демонами) мы использовали ZMQ он ничо так, но подтекал.

вы его убиваете?

3. В задаче надо процессить деньги. Беру из очереди задание и ставлю ему статус "обрабатывается", чтобы другие не взяли, и текущее время. Если процесс умирает неестественно, джоба остается висеть в "обрабатывается", и непонятно сколько надо ждать, чтобы другой решился забрать задачу себе.
Как можно избежать бесполезного ожидания?

Если прям хочется изолироватся, я бы форкал per-job процессы, хранил пид, мониторил сигнал смерти, и высвобождал задачу в мониторящем процессе если исполнитель умер. Правда немного кажется пушкой по воробьям, но могу представить задачу, где каждая милисекунда на счету.

Вообще, я раньше сильно топил за phpdaemon в котором поддержка мониторинга своих же воркеров/рестарт по памяти/IPC из-коробки, и у меня все еще есть код, написанный под него, на сервер с которым я не заглядывал пару лет, и он сам там крутится, но его код, и код написанный под него абсолютно невозможно мантейнить. Его можно написать, забыть и простить, но поддерживать очень тяжело.
Поэтому мы переезжаем на reactphp, он очень аккуратный, но кучу всего приходится писать самому.

 

[WMix]

Поэтому мы переезжаем на reactphp

для веба тоже или только демоном?

 

[флоппик]

для веба тоже или только демоном?

у нас веба кроме админок особо нет, и там мы тихонечко в сторону vue spa движемся. Я честно говоря, вот в эти штуки «запусти симфони через евентлуп что бы сайты сервить» не очень верю.

 

[WMix]

запусти симфони через евентлуп

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

 

[флоппик]

а ppm?

Вот я его и имел ввиду говоря про

вот в эти штуки «запусти симфони через евентлуп что бы сайты сервить» не очень верю.

 

[WMix]

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

 

[AnrDaemon]

1. PHP рожден чтобы умирать, но иногда он уподобляется Ильичу, и вместо падения просто зависает, и перестает реагировать. Как вы обрабатываете такое?

Зависает обычно не сам PHP а какие-то отдельные функции.
У меня это часто коннекты к внешним сервисам. Решается явным заданием таймаутов соединения и чтения. Уже лет пять нет проблем.

2. Работа в постоянном рабочем цикле с разными расширениями вроде ресайза фоток периодически приводит к утечкам памяти, и подобным проблемам.

imagick надо обновлять вовремя.

3. В задаче надо процессить деньги.
…
Как можно избежать бесполезного ожидания?

См. п.1.

 

[grigori]

Спасибо.
Думаю теперь, лень мне ставить редис для очереди, или не лень.
MySQL тяжеловат для этого - у меня много параллельных очередей вырисовывается. А кролика не хочу - он теряет при ребуте, для денег это недопустимо.

 

[WMix]

редис для очереди

зачем из базы очередь делать?

А кролика не хочу - он теряет при ребуте

и зачем из очереди базу

 

[AnrDaemon]

Думаю теперь, лень мне ставить редис для очереди, или не лень.
MySQL тяжеловат для этого - у меня много параллельных очередей вырисовывается. А кролика не хочу - он теряет при ребуте, для денег это недопустимо.

Это две разных задачи, не стоит пытаться их решить одним инструментом.
В БД хранится "постоянная" часть данных, а в очереди - очередь, т.е. то, что можно в любой момент восстановить.

 

[grigori]

А зачем, вообще, очередь? Записать задание в файл, и пнуть демон через posix_kill ... ну, или в открытый сокет свиснуть. Это плохо масштабируется и неудобно деплоится. Например, это плохо ложится в контеййнеры.
Задачу нужно передавать по сети, и хранить где-то в специальном месте.

Кролик делает pub/sub, трансляция состояния без гарантий доставки. Получается, что обработчику при старте надо заглянуть в базу, и забрать задания, а потом реагировать на уведомления о новых заданиях. Но уведомление можно как угодно отправить - просто соединением на tcp-порт, например.

Что я понимаю неправильно?

 

[fixxxer]

редис для очереди

теряет при ребуте, для денег это недопустимо

Кролик делает pub/sub, трансляция состояния без гарантий доставки.

Redis-овский pub-sub тогда тоже не подойдет. Но на redis можно сделать надежную очередь через RPOPLPUSH и LUA-скрипты: https://redis.io/commands/rpoplpush

 

[флоппик]

В ZMQ кстати, пакеты с подтверждением, хер потеряешь (даже если хочешь очередь сбросить )

 

[fixxxer]

ZMQ

Я его как-то боюсь. Слишком много магии. В продакшен потащить бы побоялся. Обосновать не могу, просто ощущение такое.