Worker sizing в n8n: concurrency, RAM, CPU и очереди без перегруза

Обновлено: 2026-05-29

Worker sizing — это не “поставить побольше workers”. В n8n queue mode каждый worker выполняет jobs из Redis, использует PostgreSQL, ходит во внешние API и потребляет RAM/CPU. Если увеличить workers без расчёта, можно ускорить систему, а можно получить 429, таймауты, забитый connection pool и ещё более медленные executions.

Задача sizing — подобрать баланс: сколько jobs можно выполнять параллельно, сколько памяти нужно каждому типу workflow, где узкое место и когда нужен отдельный worker для тяжёлых задач.

Что влияет на размер worker

Базовая схема queue mode

services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
  n8n-worker:
    image: n8nio/n8n:latest
    command: worker --concurrency=5
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}

Начните с одного worker и --concurrency=5, затем измеряйте. Для тяжёлых файловых или AI workflow иногда лучше concurrency=1–3, чем много параллельных задач, которые конкурируют за память и внешний API.

Почему много маленьких workers не всегда лучше

Каждый worker создаёт подключения к PostgreSQL и Redis. Если запустить 20 workers с низкой concurrency на маленьком VPS, база может стать узким местом раньше, чем CPU. Поэтому масштабирование нужно проверять по четырём метрикам:

• длина очереди Redis;
• время ожидания job до старта;
• CPU/RAM каждого worker;
• PostgreSQL connections, locks и slow queries.

Если очередь растёт, но CPU свободен, можно добавить concurrency. Если CPU/RAM уже высокие — нужен отдельный сервер или оптимизация workflow. Если PostgreSQL упёрся в connections — увеличение workers навредит.

Практический sizing по типам задач

Concurrency control в regular mode

Если queue mode ещё не включён, но production executions запускаются слишком параллельно, можно ограничить concurrency на self-hosted инстансе:

N8N_CONCURRENCY_PRODUCTION_LIMIT=20

Это не замена queue mode, но хороший предохранитель для маленького инстанса: лишние production executions будут ждать свободного места, а не одновременно грузить event loop.

PostgreSQL и Redis как ограничения

Workers не существуют отдельно от базы. Проверьте:

SELECT count(*) FROM pg_stat_activity;

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state;

Если база забита активными запросами, workers будут ждать, даже если Redis и CPU выглядят нормально. Для Redis следите за memory, latency и доступностью. Потеря Redis в queue mode означает проблемы с доставкой jobs.

Как проводить нагрузочный тест

1. Выберите один критичный workflow.
2. Подготовьте 100–500 тестовых событий с реалистичным payload.
3. Запустите на текущей concurrency.
4. Замерьте p50/p95 времени execution, ошибки API, RAM, CPU, Postgres connections.
5. Увеличьте concurrency на 2–5, повторите тест.
6. Остановитесь не на максимальной скорости, а на устойчивом профиле без всплесков ошибок.

Для business-critical сценариев лучше иметь запас. Если система стабильно выдерживает 20 jobs/min, не обещайте 20 jobs/min как норму. Оставьте headroom для повторов, обновлений, внешних задержек и ручных запусков.

Ошибки sizing

• увеличивать workers, когда проблема во внешнем API rate limit;
• ставить одинаковую concurrency для лёгких webhooks и тяжёлых PDF;
• держать main, worker, PostgreSQL, Redis и AI-модель на одном слабом VPS;
• не учитывать manual executions и тесты команды;
• не ставить healthchecks и restart policy для workers.

docker compose ps
docker compose logs --tail=200 n8n
docker compose logs --tail=200 n8n-worker
printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_'
# перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY

Связанные материалы

• Queue mode в n8n
• Redis для queue mode
• Healthchecks и автоперезапуск
• Memory limit

Ответы на частые вопросы

Сколько workers нужно для n8n?

Начните с одного worker и concurrency около 5, затем измеряйте очередь, время выполнения, RAM, CPU и PostgreSQL. Для тяжёлых файловых или AI workflow concurrency часто нужно снижать.

Почему больше workers стало медленнее?

Возможные причины: PostgreSQL connection pool, Redis latency, внешний API rate limit, слишком большие payload или недостаточно RAM.

Можно ли ограничить параллельность без queue mode?

Да, для self-hosted regular mode есть N8N_CONCURRENCY_PRODUCTION_LIMIT. Это предохранитель, но для масштабирования лучше queue mode.