--- title: "Worker sizing в n8n: concurrency, RAM и CPU — Nodbot" source_url: "https://nodbot.ru/hosting/worker-sizing/" canonical_url: "https://nodbot.ru/hosting/worker-sizing/" language: "ru" content_type: "HostingGuide" section: "hosting" generated_at: "2026-05-30" word_count_source: 942 --- # Worker sizing в n8n: concurrency, RAM и CPU очереди без перегруза ## AI summary Production-гайд «Worker sizing в n8n: concurrency, RAM и CPU очереди без»: настройка n8n, инфраструктура, мониторинг, backup, rollback и ошибки эксплуатации. ## Best used for Страница объясняет «Worker sizing в n8n: concurrency, RAM и CPU — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Что влияет на размер worker - Базовая схема queue mode - Почему много маленьких workers не всегда лучше - Практический sizing по типам задач - Concurrency control в regular mode - PostgreSQL и Redis как ограничения - Как проводить нагрузочный тест - Ошибки sizing ## Source outline # 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 - Фактор | Как влияет | Что делать - HTTP/API workflow | часто упирается во внешний rate limit | умеренная concurrency + Wait/retry - файлы и OCR | съедает RAM и диск | меньше concurrency, binary storage, отдельный worker - AI/RAG | долгие ответы, большой контекст | лимит контекста, fallback, отдельная очередь по смыслу - PostgreSQL-heavy | много insert/upsert/select | индексы, batching, контроль connection pool - короткие webhooks | важен быстрый ответ | отдельные webhook processors и быстрый Respond ## Базовая схема 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 по типам задач - Тип workflow | Стартовое значение | Комментарий - простые CRM/API sync | 1 worker × concurrency 5 | следите за 429 и временем API - webhook intake | быстрый ответ + обработка отдельно | не держите HTTP-клиента до конца тяжёлой цепочки - PDF/OCR/файлы | 1 worker × concurrency 1–2 | важнее стабильность памяти - AI/RAG | concurrency 1–3 | ограничьте tokens/context и таймауты - массовый import | batch + controlled concurrency | сохраняйте checkpoint ## 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. ## Как проводить нагрузочный тест - Выберите один критичный workflow. - Подготовьте 100–500 тестовых событий с реалистичным payload. - Запустите на текущей concurrency. - Замерьте p50/p95 времени execution, ошибки API, RAM, CPU, Postgres connections. - Увеличьте concurrency на 2–5, повторите тест. - Остановитесь не на максимальной скорости, а на устойчивом профиле без всплесков ошибок. Для 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. ## Операционный runbook для self-hosted Для темы «Worker sizing в n8n» важно разделять настройку и эксплуатацию. Настройка отвечает на вопрос “запустилось ли”, эксплуатация — “сможем ли мы восстановиться, обновиться и расследовать инцидент без потери credentials и execution history”. Перед изменениями проверьте бэкап базы, значение N8N_ENCRYPTION_KEY, состояние volume, логи web-процесса и worker-процесса. Главный риск — поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key. - Слой | Что зафиксировать | Зачем - Вход | состояние контейнеров, очередь, переменные окружения, volume и последние строки логов | позволяет повторить проблему без доступа к production-секретам - Контроль | restart_count, memory_usage, queue_depth, worker_concurrency, failed_executions | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Worker sizing в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` 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 ``` ### Критерий готовности - есть свежий backup базы и проверено значение N8N_ENCRYPTION_KEY - web, worker, queue и database используют согласованные переменные окружения - после изменения проверены логи, healthcheck и запуск критичных workflow - записан rollback-план с командами и ответственным ## Связанные материалы - 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. ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.