CPU и memory spike в n8n: runbook диагностики ¶

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

Intent: runbook CPU memory spike: найти workflow, node, payload или worker, который перегружает n8n
H1: CPU и memory spike в n8n: как найти тяжёлый workflow и стабилизировать workers
Schema: TechArticle, HowTo, FAQPage, BreadcrumbList
Old word count: 663
New word count: 792

Короткий ответ ¶

CPU или memory spike в n8n почти всегда связан с конкретным типом нагрузки: большой payload, бесконечный loop, тяжёлый Code node, массовые HTTP-запросы, AI/RAG-обработка, binary files или слишком высокая concurrency workers. Сначала определите, перегружен main instance или worker, затем найдите workflow по времени всплеска и execution history. Быстрый mitigation — остановить источник нагрузки, снизить concurrency, разбить batch и вынести тяжёлые операции из одного execution.

Симптомы ¶

Проблема может выглядеть как «n8n тормозит», но важно быстро разделить симптомы:

• UI долго открывается или теряет соединение;
• workflow запускается, но зависает на одном node;
• worker container перезапускается по OOM;
• Docker показывает 100% CPU у одного контейнера;
• queue растёт, хотя Redis доступен;
• AI workflow резко увеличил стоимость и latency;
• Postgres жив, но executions идут медленно;
• reverse proxy отдаёт 502/503 из-за недоступного upstream.

Если используется queue mode, main instance может выглядеть здоровым, а проблема будет только в одном worker.

1. Определить, какой процесс перегружен ¶

Начните с контейнеров:

docker stats

docker compose ps
docker compose logs --tail=100 n8n
docker compose logs --tail=100 n8n-worker

Если CPU/Mem растёт у worker — ищите production executions. Если у main — проверьте UI, manual executions, webhooks, cron triggers и frontend/API нагрузку.

Полезная классификация:

2. Найти workflow по времени ¶

Сопоставьте время spike с execution history. Ищите executions, которые:

• стартовали перед ростом CPU/RAM;
• имеют большой payload;
• долго находятся в running;
• падают на одном node;
• запускаются слишком часто;
• обрабатывают файлы, списки, AI-запросы или nested loops.

Если есть queue mode, посмотрите, все ли workers страдают одинаково. Один перегруженный worker часто указывает на конкретный job, а общий рост — на batch/cron/webhook storm.

3. Быстро снизить нагрузку ¶

Mitigation зависит от ситуации. Цель — остановить лавину, не потеряв критичные события.

Не лечите spike только увеличением ресурсов. Это может скрыть ошибку workflow и превратить разовый сбой в дорогую постоянную нагрузку.

4. Частые причины в workflow ¶

Большой batch без пауз.
Например, 20 000 строк из CRM идут в API без chunking. Решение: Loop Over Items, размер batch, Wait, checkpoint.

Code node держит всё в памяти.
Скрипт собирает огромный массив, сортирует, делает map/filter на full payload. Решение: обработка кусками, предварительная фильтрация, не хранить лишние поля.

AI/RAG workflow без ограничений.
Один входной запрос запускает десятки tool calls или retrieval по большой базе. Решение: max iterations, лимит документов, structured output, fallback.

Binary data в execution.
PDF, изображения, CSV и вложения резко увеличивают память и размер execution data. Решение: хранить файлы вне execution, передавать ссылки/ID.

Retry усиливает аварию.
Когда внешний API отдаёт 429/500, агрессивные retry создают ещё больше запросов. Решение: exponential backoff, dead-letter path, лимит попыток.

5. Что изменить после инцидента ¶

• Добавить лимит batch size.
• Описать допустимую concurrency для workers.
• Ввести guard condition для loop.
• Ограничить AI tools и max iterations.
• Не сохранять full payload, если он не нужен.
• Добавить correlation ID для поиска execution.
• Настроить alert на memory, CPU и queue depth.
• Вынести тяжёлые workflow на отдельные workers, если архитектура позволяет.

Мини-чеклист ревью тяжёлого workflow ¶

• Есть ли ограничение на количество items?
• Что будет, если внешний API вернёт 429?
• Есть ли Wait между пачками?
• Есть ли дедупликация входных событий?
• Можно ли обработать payload без хранения всех данных в памяти?
• Нужен ли этот файл внутри n8n или достаточно ссылки?
• Что произойдёт при повторном запуске execution?

FAQ ¶

Почему UI падает, хотя проблема в worker?
При общей нехватке ресурсов на сервере worker может забрать CPU/RAM так, что main instance, Postgres или proxy тоже начнут отвечать медленно.

Что лучше: добавить worker или уменьшить concurrency?
Если workflow CPU-bound или memory-heavy, сначала уменьшите concurrency и оптимизируйте payload. Добавление workers помогает только после устранения причины перегруза.

Как понять, что виноват AI workflow?
Смотрите время, количество tool calls, размер context, latency provider и стоимость. AI-ветки часто дают spike из-за повторов, длинного контекста и отсутствия ограничений.

Можно ли остановить running execution?
Да, но сначала зафиксируйте, какой бизнес-процесс будет затронут. Для платежей, CRM и уведомлений может потребоваться replay или ручная сверка.

{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}