n8n в queue mode: сколько воркеров нужно и как проверить это на своём VPS

MAATRIX · 17 октября 2026 · 8 мин чтения

Восемь воркеров звучат солиднее одного. На схеме такая система похожа на маленькую фабрику: задания идут по очереди, исполнители работают параллельно, руководитель доволен архитектурой. На практике фабрика иногда дружно ждёт ответа одного API, а PostgreSQL тем временем пытается обслужить неожиданно многочисленное собрание клиентов.

Queue mode нужен, когда выполнение сценариев хочется отделить от основного процесса n8n и управлять его масштабированием. Но количество воркеров само по себе ничего не говорит о производительности. Сначала нужно понять, что именно делают ваши сценарии: считают, ждут сеть, обрабатывают файлы или упираются в ограничения внешнего сервиса.

Разберём методику сравнения. В ней нет придуманных результатов «на тысячу заявок»: итоговые цифры вы получите на своей схеме, с собственными размерами данных и понятной границей допустимой задержки.

Почему десять одновременно не означает десять процессоров

В режиме очереди основной процесс принимает события, Redis участвует в передаче заданий, а воркеры выполняют сценарии и работают с общей базой. Каждому исполнителю нужны одинаковая версия n8n, доступ к PostgreSQL и Redis, а также общий ключ шифрования учётных данных. Базовая схема описана в руководстве n8n по queue mode.

Параметр concurrency определяет количество одновременно выполняемых заданий внутри воркера. Если сценарий большую часть времени ожидает HTTP-ответ, один процесс способен обслуживать несколько таких ожиданий. Если же он непрерывно преобразует большие массивы, увеличение параллельности может лишь усилить конкуренцию за процессор и память.

Поэтому фраза «у нас двадцать автоматизаций» почти бесполезна для расчёта. Один сценарий может приходить раз в сутки и завершаться за секунду; другой — получать сотни событий и отправлять каждое в медленную внешнюю систему. Считать нужно поступающие задания, длительность обработки и ресурсную стоимость одного задания.

Соберите стенд, который имеет смысл сравнивать

Для первого эксперимента используйте отдельную копию n8n. У неё должны быть тестовые интеграции и собственная база: нагрузочная проверка не должна отправлять клиентам письма или создавать настоящие счета. Исходящие запросы в платные API замените контролируемым тестовым сервисом, если цель — измерить именно вашу инфраструктуру.

Зафиксируйте версии образов, размер VPS, конфигурацию PostgreSQL, Redis, способ хранения вложений и правила сохранения истории выполнений. Между прогонами меняйте один параметр. Иначе сравниваться будут не воркеры, а два разных проекта, случайно имеющих похожее название.

Для проверки режима достаточно одного основного процесса, базы, Redis и одного воркера. Переменная EXECUTIONS_MODE=queue задаётся участвующим экземплярам. Команда процесса воркера может выглядеть так:

n8n worker --concurrency=5

Это команда уже настроенной установки, а не полная инструкция развёртывания. Пароли, подключения и N8N_ENCRYPTION_KEY передаются через защищённую конфигурацию. PostgreSQL и Redis не следует публиковать в интернет ради удобства теста.

Не смешивайте ограничение общей параллельности и число заданий конкретного воркера: их поведение зависит от режима. Перед экспериментом проверьте описание concurrency control для установленной версии и запишите фактически действующие ограничения.

Три сценария вместо одного красивого графика

Начните с короткой цепочки: webhook получает небольшое сообщение, проверяет обязательные поля и записывает результат в отдельную тестовую таблицу. Она покажет накладные расходы самой доставки задания и обращения к базе.

Во второй цепочке добавьте управляемое ожидание внешнего HTTP-сервиса. Пусть тестовый сервис отвечает с известной задержкой и иногда возвращает ограничение частоты запросов. Так станет видно, помогает ли параллельность и не превращает ли она повторные попытки в лавину.

Третья цепочка должна походить на самый тяжёлый рабочий процесс: например, разобрать крупный документ или преобразовать каталог товаров. Используйте обезличенные данные с реалистичным размером. Маленький JSON вместо двадцатимегабайтного файла создаёт приятную иллюзию запаса памяти, но не проверяет нужный случай.

Каждому входному событию присвойте уникальный идентификатор. Итоговый результат должен позволять ответить на три вопроса: сколько событий принято, сколько обработано успешно и сколько фактически записей создано. HTTP-ответ «принято» ещё не означает завершения процесса. Особенно если webhook отвечает до исполнения остальных узлов.

Как провести прогоны и не обмануть себя

Сначала отправьте небольшое число событий и проверьте правильность результата вручную. Затем создавайте нагрузку ступенями: спокойный поток, обычный рабочий пик и короткий всплеск. Генератор нагрузки запускайте отдельно, чтобы он не отнимал процессор у измеряемого сервера.

Для каждого профиля сравните один воркер, затем два при неизменной суммарной нагрузке. Только после этого меняйте concurrency. Вариант с большим количеством процессов и минимальной параллельностью не обязательно экономен: подключения к базе тоже стоят ресурсов.

Заполняйте таблицу собственными результатами. Пустые клетки здесь полезнее рекламных чисел, которые никто не измерял.

Задержку считайте от приёма события до завершения полезного результата, включая ожидание в очереди. Процентиль p95 помогает увидеть медленные выполнения, которые среднее значение прячет. После окончания подачи событий дождитесь опустошения очереди и включите это время в отчёт.

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

Читайте симптомы, а не только загрузку CPU

Очередь растёт, процессор почти свободен, внешнее API отвечает ошибками ограничения частоты — вероятно, нужны лимиты и разумные повторы. Дополнительные воркеры могут сделать внешнему сервису ещё хуже.

Очередь растёт, память заканчивается, процессы перезапускаются — уменьшайте одновременно обрабатываемый объём и изучайте тяжёлые узлы. Для работы с файлами важно проверить выбранный режим бинарного хранения. Возможности очереди и внешнего хранилища зависят от версии и редакции n8n; локальный каталог одного исполнителя не становится общим автоматически.

Воркеры заняты, а база показывает длительные запросы и множество соединений — сначала исследуйте PostgreSQL и объём сохраняемых выполнений. Настройки истории и очистки влияют на диск и обслуживание базы. Одинаковый тест с полной историей и с минимальным сохранением — разные условия эксперимента.

Наконец, медленный ответ клиенту может возникать уже после полезной работы: большой результат ещё нужно передать обратно через инфраструктуру очереди. Для выгрузок и тяжёлых файлов часто удобнее асинхронная задача с отдельной ссылкой на готовый результат, чем удерживаемое HTTP-соединение.

Проверка отказа входит в расчёт

Когда найдена приемлемая скорость, остановите один тестовый воркер посреди обработки и посмотрите, что произойдёт с заданиями. Проверяйте не только восстановление очереди, но и побочный эффект во внешней системе. Сценарий мог успеть создать запись, а подтверждение выполнения — потеряться.

Надёжный обработчик использует идентификатор события для защиты от повторного действия. Если внешняя система поддерживает ключ идемпотентности, передавайте его; если нет, проектируйте собственную проверку и журнал. Обычная повторная попытка не даёт гарантии «ровно один раз».

Запланированную остановку также протестируйте: прекратите новые поступления, дождитесь завершения текущих работ и только потом выключайте исполнителей. Нельзя объявлять схему устойчивой лишь потому, что контейнер умеет автоматически перезапускаться.

Полезный итог такого упражнения — небольшой журнал спорных событий. В нём видно, какое действие точно завершено, какое требует повторной проверки, а какое можно безопасно выполнить снова. Для платёжной интеграции эта таблица важнее ещё одного красивого графика загрузки процессора.

Как выбрать конфигурацию MAATRIX по результатам

Для лабораторного сравнения основной процесс, PostgreSQL, Redis и небольшой воркер можно разместить на Heka Standard с 4 vCPU и 8 ГБ памяти. Это старт для измерений: тяжёлые документы и несколько параллельных сценариев могут потребовать большего объёма. Maat Pro с 8 vCPU и 16 ГБ даст другой ресурсный запас, но его пользу должен подтвердить повтор того же теста.

Если исполнители вынесены на отдельные VPS, измеряйте задержку до общей базы и Redis. Распределение по разным странам ради красивой схемы способно ухудшить поведение гораздо заметнее, чем дополнительный процессор улучшит его. Начинайте с близкого размещения компонентов и закрытых соединений между ними.

В MAATRIX можно заказать VPS с n8n, а режим очереди настроить под свою схему отдельно. При этом несколько воркеров на одном сервере не обеспечивают независимость от отказа этого сервера. Несколько основных процессов — тоже отдельная возможность с условиями лицензии, а не бесплатное следствие включённой очереди.

Хорошая конфигурация определяется просто: она успевает обработать ваш пик, оставляет запас для восстановления и не создаёт неприемлемых дублей. Всё остальное, включая внушительное число прямоугольников на архитектурной схеме, — средство достижения этой цели.