Кажется утечки как раз и дело «кривых рук».
Я бы не сказал, что они нас сильно беспокоят. За все время сильно утекала память при только использовании SoapClient, но после 7.0.5 проблему больше не замечали. Защита от утечек довольно простая, так что лучше подстраховаться и не ждать, пока нарвешься на какую-то сильно «подтекающую» функцию.
В случае очереди на БД, если 2 инстанса одной консольной команды одновременно потянутся за задачами есть шанс, что оба получать одну и ту же задачу и она выполниться дважды. На Redis-е этого можно избежать, ну а тот же RabbitMQ этой проблемы лишен, задача дойдет только одному консумеру. Я поэтому и написал, что если нет возможности использовать нормальный менеджер очередей — эту проблему придется решать.
У нас часть задач в очередях на БД, часть в RabbitMQ, не буду вдаваться в подробности, так было необходимо, поэтому для нас проблема актуальна.
Вы, конечно, правы, для этих целей можно использовать и супервизор. Даже кронами можно обойтись. Наше решение — всего лишь еще один способ решения задачи.
Спасибо за комментарий. Видно, что Вы лично прошлись по этим граблям :)
У нас сейчас работает 51 демон. Все работают с разным задачами, и многие из них весьма нетривиальны. Я бы не сказал что это «простое приложение». Проблему с коннекшенами мы решили и больше с ней не сталкиваемся. Руками мы ничего не завершаем и не перезапускаем, все делает Watcher, а команды ему мы даем из веб-интерфейса.
Поясните, пожалуйста, какая именно проблема с распределением нагрузки у Вас возникала?
По поводу перехвата ошибок, да проблема была в 5.6 (хотя некоторую часть неперехватываемых ошибок удавалось обрабатывать при помощи register_shutdown_function), но в 7-ке проблема уже не так актуальна. Если при выполнении задачи возникла ошибка, мы помечаем задачу, а дальше логи и newrelic, отлавливаем и фиксим.
Проблема с утечками тоже учтена.
«Не угодили» не совсем та фраза. Это хорошее решение. Но я бы не сказал, что это сильно проще — консольный команды для правильной работы с супервизором все равно нужно «допилить» — ну как минимум они должны хэндлить PCNTLсигналы и корректно завершать текущую задачу.
Для нас была важна потребность в параллельной обработке задач одним демоном. Да, супервизор может запускать несколько инстансов одной команды, но они всегда будут висеть в памяти (тут тоже можно поспорить, конечно, что лучше — лишний процесс в памяти или форк при необходимости), к тому же нужно будет решать проблему корректного распределения задач между ними (а у нас далеко не всегда есть возможность использовать нормальный менеджер очередей).
Во всех. Мы перешли на PHP 7 почти сразу после релиза, на нем получше, но от утечек никуда не денешься. Сильнее течет память в extensions.
Даже fpm воркеры рекомендуется перезапускать (pm.max_requests)
Я бы не сказал, что они нас сильно беспокоят. За все время сильно утекала память при только использовании SoapClient, но после 7.0.5 проблему больше не замечали. Защита от утечек довольно простая, так что лучше подстраховаться и не ждать, пока нарвешься на какую-то сильно «подтекающую» функцию.
У нас часть задач в очередях на БД, часть в RabbitMQ, не буду вдаваться в подробности, так было необходимо, поэтому для нас проблема актуальна.
Вы, конечно, правы, для этих целей можно использовать и супервизор. Даже кронами можно обойтись. Наше решение — всего лишь еще один способ решения задачи.
У нас сейчас работает 51 демон. Все работают с разным задачами, и многие из них весьма нетривиальны. Я бы не сказал что это «простое приложение». Проблему с коннекшенами мы решили и больше с ней не сталкиваемся. Руками мы ничего не завершаем и не перезапускаем, все делает Watcher, а команды ему мы даем из веб-интерфейса.
Поясните, пожалуйста, какая именно проблема с распределением нагрузки у Вас возникала?
По поводу перехвата ошибок, да проблема была в 5.6 (хотя некоторую часть неперехватываемых ошибок удавалось обрабатывать при помощи register_shutdown_function), но в 7-ке проблема уже не так актуальна. Если при выполнении задачи возникла ошибка, мы помечаем задачу, а дальше логи и newrelic, отлавливаем и фиксим.
Проблема с утечками тоже учтена.
Для нас была важна потребность в параллельной обработке задач одним демоном. Да, супервизор может запускать несколько инстансов одной команды, но они всегда будут висеть в памяти (тут тоже можно поспорить, конечно, что лучше — лишний процесс в памяти или форк при необходимости), к тому же нужно будет решать проблему корректного распределения задач между ними (а у нас далеко не всегда есть возможность использовать нормальный менеджер очередей).
Даже fpm воркеры рекомендуется перезапускать (pm.max_requests)