Memory limit в n8n: как найти утечку, большие payload и нехватку RAM

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

Ошибка памяти в n8n почти никогда не решается одним действием. Иногда действительно не хватает RAM на VPS, но чаще память съедает конкретный workflow: большой JSON, файл в binary data, неограниченный цикл, Code node, RAG-контекст, массовый HTTP Request или несколько параллельных executions. Если просто увеличить память контейнера, проблема вернётся на следующем пике.

Цель диагностики — понять, где именно растёт потребление: в основном процессе n8n, worker, task runner, PostgreSQL, Redis, reverse proxy или конкретной ноде. После этого можно выбрать правильное решение: уменьшить payload, вынести файлы, включить queue mode, ограничить concurrency, переписать Code node или изменить хранение binary data.

Как выглядит проблема

Быстрая диагностика на сервере

Сначала зафиксируйте состояние, а не меняйте env вслепую:

docker stats --no-stream

docker compose ps

docker compose logs --tail=200 n8n

docker inspect n8n --format '{{.State.OOMKilled}} {{.State.ExitCode}} {{.State.RestartCount}}'

Если OOMKilled=true, контейнер убила система из-за памяти. Если контейнер жив, но workflow получил timeout или 500, проблема может быть в конкретной ноде, внешнем API или прокси, а не в RAM.

Что проверить в самом workflow

1. Запустите workflow на одном минимальном payload.
2. Посмотрите, на какой ноде резко вырос размер данных.
3. Проверьте, не передаёте ли вы весь исходный ответ API дальше по цепочке.
4. Уберите лишние поля сразу после HTTP Request через Edit Fields.
5. Разбейте массив на пачки через Loop Over Items.
6. Для файлов сохраняйте ссылку, hash и размер, а не сам файл во всех последующих нодах.

Классическая ошибка: получить 10 000 записей из CRM, обогатить каждую, сохранить полный ответ каждого API-вызова и потом отправить всё в AI-ноду. Такой workflow расходует память даже на хорошем сервере.

Docker Compose: лимиты и базовая защита

Если вы запускаете n8n в Docker, задайте ресурсы осознанно. Лимит должен защищать сервер, но не маскировать плохую архитектуру workflow.

services:
  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    environment:
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=336
      - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
    volumes:
      - n8n_data:/home/node/.n8n
      - n8n_files:/files
    deploy:
      resources:
        limits:
          memory: 2g
        reservations:
          memory: 1g

В обычном docker compose поведение deploy.resources зависит от режима запуска, поэтому проверяйте фактические лимиты через Docker и мониторинг. Для небольшого инстанса часто разумнее начать с 2–4 GB RAM, PostgreSQL отдельно и без тяжёлых AI/файловых workflow на том же сервере.

Binary data: самая частая причина OOM

PDF, изображения, аудио, Excel и вложения писем нельзя гонять по workflow как обычный маленький JSON. Для файлового сценария минимальная схема должна быть такой:

Webhook / Gmail / Drive → сохранить файл → извлечь нужные поля → удалить лишнее → передать дальше ссылку и metadata

Для обычного режима n8n используйте filesystem mode. Для queue mode учитывайте, что filesystem mode не подходит, если worker и main не имеют общего безопасного доступа к тем же файлам; тогда лучше database mode или внешнее S3-хранилище, если оно доступно в вашей лицензии и архитектуре.

Code node: как не съесть всю память

В Code node опасны три вещи: копирование больших массивов, вложенные циклы и сохранение промежуточных данных. Плохой паттерн — собрать все items в один объект, потом несколько раз мапить и фильтровать его. Лучше обрабатывать только нужные поля.

return items.map(item => ({
  json: {
    external_id: item.json.id,
    email: item.json.email,
    amount: item.json.total,
    updated_at: item.json.updated_at,
  }
}));

Если нужно обработать тысячи записей, разбейте их на пачки и сохраняйте результат после каждой пачки. n8n — это оркестратор, а не замена аналитической базе данных для обработки гигантских массивов в памяти.

Queue mode и worker sizing

Queue mode помогает не тем, что “магически добавляет память”, а тем, что тяжёлые executions уходят на workers. Это позволяет изолировать падение, масштабировать количество workers и задавать concurrency. Для одного тяжёлого workflow лучше один worker с умеренной concurrency, чем много workers, которые одновременно добьют PostgreSQL и внешний API.

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 падает только на одном workflow, не увеличивайте concurrency. Сначала уменьшите размер данных, включите batching и уберите лишние поля.

Когда можно увеличивать лимиты

Увеличение RAM или Node heap имеет смысл только после диагностики. Оно допустимо, если workflow действительно обрабатывает крупные, но контролируемые данные, а не бесконечно растущий массив. В крайних случаях можно передать Node-параметры через NODE_OPTIONS, но это не должно быть первым шагом:

environment:
  - NODE_OPTIONS=--max-old-space-size=4096

Если после этого память снова доходит до потолка, причина не устранена. Возвращайтесь к payload, binary data, циклам и concurrency.

Проверка после исправления

• запустить workflow на маленьком, среднем и крупном payload;
• сравнить memory usage до и после проблемной ноды;
• проверить, что execution data не хранит лишние файлы и большие ответы API;
• проверить, что worker не уходит в restart loop;
• добавить alert на память контейнера и свободное место диска.

Хороший результат — не “ошибка исчезла один раз”, а предсказуемый профиль нагрузки: вы понимаете, сколько памяти нужно workflow на 100, 1000 и 10 000 items.

{
  "execution_id": "exec_...",
  "workflow_id": "wf_...",
  "node_name": "node_with_symptom",
  "error_message": "точный текст ошибки без токенов",
  "input_item_id": "external_or_dedupe_id",
  "last_successful_run": "timestamp",
  "changed_before_error": ["credentials", "payload", "version", "env"]
}

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

• Binary data и файлы в n8n
• Worker sizing и concurrency
• Execution timed out
• Pruning executions

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

Почему n8n падает по памяти?

Чаще всего из-за больших payload, файлов в binary data, неограниченного цикла, тяжёлого Code node или слишком высокой параллельности. Сначала нужно найти ноду, где растёт объём данных.

Поможет ли просто увеличить RAM?

Иногда поможет, но это не должно быть первым шагом. Если workflow копит лишние данные или обрабатывает файлы в памяти, проблема вернётся при следующем росте нагрузки.

Что делать с большими файлами?

Не передавать файл через все ноды без необходимости. Сохраняйте файл во внешнее хранилище или filesystem/database mode, а дальше передавайте ссылку, hash, размер и нужные metadata.