та ну

у меня (может только у меня)
с ларой всегда получается всё модульно и всё в чем зависимость это eloquent, хотя это не огромная проблема

оно скорее так кажется

У меня в докер-контейнере на локальной тачке крутится 8 воркеров, которые запускаются вот так:
artisan queue:work --tries=3 --delay=90 --timeout=1200

Насколько я понял, supervisorctl пулит воркеров раз в некоторое [малое] время, и каждый раз при таком пулинге происходит полная загрузка фреймворка, что приводит к практически постоянной загрузке cpu примерно на 25%

Есть ли какой-то дешевый выход из ситуации? Меня для дебага устроит, например, пулить раз в 10 секунд, или же мне проще переписать саму реализацию queue:work на кастомную, которая подгружает фреймворк один раз и висит в памяти.

он не пуляет а перезапускает в случае падения work

в случае безошибочной работы перезапуска не происходит

поставь на всякий horizon суть таже, но хоть какая то морда будет для просмотра событий ошибок и тп

та не supervisor просто держит процесс запущенным, это не так сильно жрет оп

если не перестараться) много раз писал, один раз запустил 50 воркеров по 10 процессов, впс вытягивал с рекавери мод только))

Хм, спасибо, сейчас попробую Horizon. Странно, я почти уверен что очередь пустая, но загруз CPU есть, и он большой для пустой очереди

очереди в простое вообще не жрут cpu практически, тк тупо моняторят редис

ram да а cpu не особо

эт если мы говорим про horizon как работает rabbitmq внутри  например, не оч знаю

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

rabitmq скорее всего висит слушатель и ждет своей очереди

то что евент листнер висит эт понятно) он всегда висит

я имею ввиду что в случае c redis это просто цикл (while) с паузой, а worker через rabittmq подключился и ждет команды

оно так все работает))

Не

иначе тупо не возможно