Описание актуально для версий SuiteCRM 8.10.0+
SuiteCRM 8 использует Symfony Messenger для обработки фоновых заданий в отдельном воркере (процессе-обработчике), не блокируя работу веб-сервера. Без запущенного воркера асинхронные задания (миграция, массовый экспорт и т. д.) могут оставаться в статусе Ожидание неопределённо долго.
Асинхронные задания и их преимущества рассматриваются в разделе Асинхронные задания.
Все команды, указанные в этом разделе, должны выполняться от имени того же пользователя, под которым работает веб-сервер.
Как правило это следующие пользователи:
www-data (Debian/Ubuntu)
apache (RHEL/CentOS с Apache)
nginx (RHEL/CentOS с Nginx)
Если воркер запускается от имени другого пользователя, операции с файлами (загрузка, работа с хранилищем файлов) завершатся с ошибками доступа.
В описании в качестве примера используется пользователь www-data — замените его на фактического пользователя веб-сервера.
В рабочей среде воркер должен работать непрерывно и автоматически перезапускаться при остановке. Рекомендуемые варианты:
Супервизор — это менеджер процессов, который поддерживает работу воркера и перезапускает его при завершении работы (например, по истечении лимита времени).
Если у вас используется Supervisor, вы можете создать конфигурационный файл по следующему пути:
/etc/supervisor/conf.d/suitecrm-messenger.conf
[program:suitecrm-messenger]
command=php /path/to/suitecrm/bin/console messenger:consume internal-async --time-limit=3600 --memory-limit=256M
user=<web-server-user>
numprocs=1
autostart=true
autorestart=true
startsecs=0
startretries=10
process_name=%(program_name)s_%(process_num)02d
stderr_logfile=/var/log/supervisor/suitecrm-messenger.err.log
stdout_logfile=/var/log/supervisor/suitecrm-messenger.out.logЗамените <web-server-user> на имя пользователя веб-сервера (например, www-data, apache, nginx).
Затем перезагрузите Supervisor:
sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start suitecrm-messenger:*Установите параметр numprocs равным 1, если вы уверены, что ваши задания безопасно выполнять с несколькими параллельными рабочими процессами. Запуск нескольких рабочих процессов может привести к дублированию обработки, если задания не предназначены для параллельного выполнения.
Если у вас используется systemd supervisor, вы можете создать конфигурационный файл службы systemd по следующему пути:
/etc/systemd/system/suitecrm-messenger.service:
[Unit]
Description=SuiteCRM Messenger Worker
After=network.target
[Service]
Type=simple
User=<web-server-user>
Group=<web-server-user>
ExecStart=/usr/bin/php /path/to/suitecrm/bin/console messenger:consume internal-async --time-limit=3600 --memory-limit=256M
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.targetЗамените <web-server-user> на имя пользователя веб-сервера (например, www-data, apache, nginx).
Затем включите и запустите службу:
sudo systemctl daemon-reload
sudo systemctl enable suitecrm-messenger
sudo systemctl start suitecrm-messengerЕсли вы не можете использовать Supervisor или systemd, вы можете задействовать cron для периодического запуска рабочих процессов. Параметр --time-limit с указанным ограничением по времени гарантирует, что старые рабочие процессы завершатся до запуска новых.
Добавьте следующую запись в crontab пользователя веб-сервера (например, sudo crontab -u www-data -e):
* * * * * php /path/to/suitecrm/bin/console messenger:consume internal-async --time-limit=55 --memory-limit=256M > /dev/null 2>&1Здесь новый воркер запускается каждую минуту. Каждый воркер работает не более 55 секунд, тем самым гарантируя, что он завершится до запуска следующего воркера.
Подход с использованием cron менее эффективен, чем Supervisor или systemd, поскольку между перезапусками воркеров есть небольшой промежуток времени, в течение которого сообщения не обрабатываются.
Чтобы запустить воркер, выполните на сервере следующую команду:
php bin/console messenger:consume internal-async --time-limit=3600 --memory-limit=256MКоманда запускает воркер, который:
Слушает транспорт internal-async (очередь по умолчанию для всех асинхронных заданий).
Автоматически останавливается через 1 час (--time-limit=3600), чтобы предотвратить утечки памяти.
Останавливается, если использование памяти превышает 256 МБ (--memory-limit=256M).
Команда messenger:consume принимает несколько полезных параметров:
| Параметры | Описание |
|---|---|
|
Останавливает воркер через указанное количество секунд. Рекомендуется для предотвращения утечек памяти из-за длительно работающих процессов. |
|
Останавливает воркер, если использование памяти превышает этот лимит (например, |
|
Останавливает воркер после обработки указанного количества сообщений. |
|
Время ожидания (в секундах) при отсутствии сообщений перед повторным опросом. По умолчанию: |
|
Подробный вывод — показывает каждое полученное и обработанное сообщение. Полезно для отладки. |
В зависимости от выбранного варианта настройки, существует несколько способов проверить, активен ли воркер в системе. Общий способ:
ps aux | grep messenger:consumeЕсли рабочий процесс запущен, вы увидите процесс, соответствующий команде messenger:consume. Если результатов нет (кроме самой команды grep), воркер не запущен и его необходимо запустить.
Также можно проверить файл журнала (logs/prod/prod.messenger.log) на предмет недавней активности:
logs/<env>/<env>.messenger.log
При необходимости можно повысить уровень детализации журнала, прописав MESSENGER_LOG_LEVEL=info в файле .env.local (подробнее см. в разделе
Справочник по настройке).
Когда отправка сообщения завершается с ошибкой (например, из-за необработанного исключения), сообщение перемещается в транспорт обработки ошибок. SuiteCRM предоставляет несколько команд для проверки и управления сообщениями, отправка которых завершилась неудачей:
# Просмотреть все сообщения, отправка которых завершилась неудачей
php bin/console messenger:failed:show
# Повторить отправку конкретного сообщения, отправка которого завершилась неудачей, по его ID
php bin/console messenger:failed:retry <id>
# Удалить сообщение, отправка которого завершилась неудачей, по его ID
php bin/console messenger:failed:remove <id>Для асинхронных заданий (задания миграции и т. д.) ошибки также отслеживаются на уровне конктретного элемента внутри самого задания. Обычно не требуется напрямую взаимодействовать с транспортом ошибок — используйте кнопки Повторить неудачную отправку или Перезапустить в пользовательском интерфейсе задания.
По умолчанию SuiteCRM использует существующую базу данных в качестве транспорта сообщений — дополнительная инфраструктура не требуется. Это подходит для большинства односерверных установок.
Необходимая таблица messenger_messages создается автоматически при запуске
Быстрого восстановления.
В большинстве случаев никаких действий вручную не требуется.
Если по какой-либо причине таблица не была создана, вы можете создать ее вручную, выполнив команду:
php bin/console messenger:setup-transports
Поскольку SuiteCRM использует Symfony Messenger, для масштабирования за пределы одного сервера также доступны альтернативные транспортные протоколы, такие как RabbitMQ (AMQP) и Redis (RESP). Детальную информацию о параметрах транспортных протоколов см. в разделе Справочник по настройке.
Задания миграции — узнайте, как запускать задания миграции данных после обновления
Справочник по настройке — ознакомьтесь с переменными среды для Symfony Messenger и асинхронных заданий
Content is available under GNU Free Documentation License 1.3 or later unless otherwise noted.