--- title: "CPU и memory spike в n8n: runbook диагностики - Nodbot" source_url: "https://nodbot.ru/playbooks/runbook-cpu-memory-spike/" canonical_url: "https://nodbot.ru/playbooks/runbook-cpu-memory-spike/" language: "ru" content_type: "TroubleshootingGuide" section: "playbooks" generated_at: "2026-05-30" word_count_source: 1030 --- # CPU и memory spike в n8n: runbook диагностики ## AI summary Runbook для CPU/memory spike в n8n: как найти тяжёлый workflow, payload, worker, loop, AI-запрос или batch size и восстановить стабильность. ## Best used for Страница объясняет «CPU и memory spike в n8n: runbook диагностики - Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Симптомы - 1. Определить, какой процесс перегружен - 2. Найти workflow по времени - 3. Быстро снизить нагрузку - 4. Частые причины в workflow - 5. Что изменить после инцидента - Мини-чеклист ревью тяжёлого workflow ## Source outline # 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 нагрузку. Полезная классификация: - Где spike | Вероятные причины - Main instance | manual execution, UI, webhook burst, API calls, bad query - Worker | тяжёлый workflow, loop, AI/RAG, binary data, большой batch - Postgres | много execution data, slow query, retention, большой payload - Redis | очередь, burst jobs, network latency - Reverse proxy | DDoS/spam webhook, keepalive/timeouts ## 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 зависит от ситуации. Цель — остановить лавину, не потеряв критичные события. - Ситуация | Быстрый mitigation - Webhook storm | временно отключить источник, rate limit на proxy - Cron слишком частый | деактивировать workflow или увеличить интервал - Worker OOM | снизить concurrency, разбить batch, увеличить memory limit - AI cost/latency spike | отключить AI ветку, добавить лимиты и human approval - Loop без ограничения | остановить execution, добавить guard condition - Большие файлы | перенести обработку в отдельный поток/хранилище Не лечите 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 или ручная сверка. ## Как применять playbook в команде Playbook «CPU и memory spike в n8n» должен быть понятен человеку, который не писал workflow. Поэтому в нём нужны входной сигнал, частота запуска, критерий тревоги, ответственный и ожидаемое действие после срабатывания. Используйте этот материал как операционную инструкцию: что проверить, где посмотреть логи, как понять масштаб проблемы и когда эскалировать. - Слой | Что зафиксировать | Зачем - Вход | входной item по теме «CPU и memory spike в n8n»: источник события, внешний ID, время получения и нормализованные поля | позволяет повторить проблему без доступа к production-секретам - Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «CPU и memory spike в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "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": "..."} } ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.