Всё работает, обрабатывает, по завершению выполняю закрытие соединений к БД, чистку кеша, слежу что бы ни где ни чего не накапливалось.
НО! PHP рожден умирать, и соответственно где то в недрах всё ровно идёт накопление по 1Мб и через какое то время consumer падает.
Автоматом приподнимается, и заново обрабатывает сообщение.
Утечки памяти в обработчиках сообщений AMQP, как вы с ними справляетесь?
По тексту непонятно где-же все таки утечки. В php-amqplib или в вашем коде. Нужен какой-то proof. Фрагмент лога. Или дамп памяти с указанием на исходник.
утечка не в коде и не в либе этой конкретно, много моментов может возникнуть, xprof вам ни чего не даст она настолько мала что не видно где. как искать их опыт есть. и находил в вендорах.
part_os, я этого не понимаю. Вы говорите что утечка ничтожно мала но в то-же время идет накопление чего-то там по 1 мегабайту за штуку что приводит к авариям.
Если так всё плохо - то берите совет Евгения. Перезапускайте периодически.
Я не глубокий специалист в PHP но если есть memory-dump то мы можем хотя-бы идентифицировать тип или класс объекта который флудит. И дальше от этой информации уже решать проблему. Другого пути я не вижу.
part_os, воркеры что в Symfony, что в Laravel вполне себе нормально работают без всяких перезапусков используя ровно php-amqplib. И исходя из этого скорее всего проблемы в коде консьюмера.
Дмитрий, нет, я на полном серьёзе, без стёба, рад что у вас получается. Ну это понятно что ту часть. А как вы ищите утечки? Есть какой то алгоритм у вас, инструменты?
part_os, последний раз утечки я искал лет 5 назад. 1 раз был модуль php-soap для 5.6. Потом был косяк в коде. В первом случае хватило гугла, во втором xhprof кажется.
С выходом 7-8 я уж и не помню что бы приходилось искать.
Утечки памяти в обработчиках сообщений AMQP, как вы с ними справляетесь?
Ограничивать время работы консюмера. После n часов/минут должен завершиться процесс после очередной итерации, после чего запущен новый процесс.
Завершать процесс при выделении памяти более допустимого объема. PHP считает выделенную память достаточно не точно, но попробовать можно memory_get_usage(), memory_get_peak_usage. -l флаг.
Завершать процесс после обработки n сообщений. -m флаг в упомянутой библиотеке php-amqplib/rabbitmq-bundle
Про сами утечки: надо дебажить и не допускать утечек :)
Верно, "рожден умирать". Рекомендовал бы не запускать скрипты на "вечно". Рано или поздно они повиснут (дело не в памяти, а в том что процесс фактически будет висеть, но ничего не делать).
Должен быть механизм убивающий слишком долго запущенные процессы. Отталкиваться можно от установленного времени работы скрипту.
ну или используя bin/console если sf поновее.
И в конфиге в секции consumers указать callback - сервис-обработчик для вашей queue.
Параметры по памяти, количеству сообщений передаются прямо в команду которая и запускает consumer: rabbitmq:consumer.
ps. Сейчас не игрался с либой, упомянул то вижу по документации.
