JavaScript heap out of memory: решение проблем с памятью в n8n

Ошибка «JavaScript heap out of memory» возникает в n8n, когда для выполнения workflow требуется больше памяти, чем доступно процессу Node.js, на котором работает n8n. Наиболее частыми причинами являются большие бинарные файлы, объёмные данные JSON, узел Code, а также ручные запуски, при которых n8n дополнительно хранит копию данных для интерфейса. Проблему можно решить, выделив процессу n8n больше памяти через переменную окружения NODE_OPTIONS с параметром --max-old-space-size, переключив обработку бинарных данных в режим файловой системы, а также с помощью регулярной очистки выполнений (execution pruning), которая автоматически удаляет старые данные о выполнениях. Актуально на июль 2026 года.

Почему n8n сообщает об ошибке «JavaScript heap out of memory»?

Ошибка возникает потому, что n8n как приложение на Node.js по умолчанию использует лишь ограниченный объём памяти для так называемого размера heap движка V8, и этот предел превышается при workflow с высоким потреблением памяти.

Согласно официальной документации n8n по устранению проблем с памятью, потребность в памяти при выполнении зависит прежде всего от объёма данных JSON, размера бинарных данных, количества одновременных выполнений, а также использования узла Code. Ручные запуски через редактор также увеличивают потребление, поскольку n8n при этом дополнительно хранит копию данных для отображения в реальном времени во фронтенде.

• Большие объёмы данных: Множество объектов JSON или крупные бинарные файлы на одно выполнение.
• Узел Code: Собственная логика на JavaScript может значительно увеличить потребление памяти.
• Ручное выполнение: Дополнительная копия данных для отображения в реальном времени в редакторе.
• Параллельные выполнения: Несколько одновременно выполняющихся workflow суммируются.

Как выделить n8n больше памяти через NODE_OPTIONS?

Вы увеличиваете доступную память, передавая процессу Node.js через переменную окружения NODE_OPTIONS параметр --max-old-space-size с более высоким лимитом памяти в мегабайтах.

Согласно документации, при ошибке «JavaScript heap out of memory» имеет смысл увеличить так называемую область старой памяти (old memory) движка V8, либо через командную строку, либо через NODE_OPTIONS. Для самостоятельно размещённых (self-hosted) инсталляций это на практике означает следующее: вы задаёте, например, NODE_OPTIONS со значением --max-old-space-size=4096, чтобы выделить процессу около четырёх гигабайт старой heap-памяти, а затем перезапускаете n8n. Важно учитывать, что эта настройка действует только в том случае, если серверу или контейнеру действительно доступно достаточно физической памяти. Если этого недостаточно, документация рекомендует в целом оснастить инстанцию большими ресурсами или выбрать более крупный тарифный план в n8n Cloud.

Как предотвратить проблемы с памятью из-за бинарных данных?

По умолчанию n8n хранит бинарные данные, такие как файлы, изображения или PDF, непосредственно в памяти, из-за чего большие файлы быстро приводят к сбоям, если вы не переключите режим хранения на файловую систему.

Согласно документации по обработке бинарных данных, n8n по умолчанию хранит бинарные данные в памяти, что при больших файлах может приводить к сбоям. С помощью переменной окружения N8N_DEFAULT_BINARY_DATA_MODE режим можно переключить на filesystem, чтобы n8n вместо этого записывал данные на диск. В режиме очереди (queue), согласно документации, режим файловой системы не поддерживается, там вместо этого используется режим базы данных. Важно знать, что очистка бинарных данных также зависит от того, какая модель хранения активна в данный момент. При смене режима старые данные остаются в прежнем месте хранения, пока не будут удалены вручную.

Как execution pruning помогает против растущего потребления памяти?

Execution pruning автоматически удаляет завершённые выполнения вместе со связанными данными выполнения и бинарными данными по возрасту или количеству, чтобы база данных и память не росли бесконтрольно.

Согласно документации по управлению данными о выполнениях, pruning включён по умолчанию и срабатывает, как только выполнение становится старше значения EXECUTIONS_DATA_MAX_AGE в часах (по умолчанию: 336 часов, то есть 14 дней), либо общее число выполнений превышает значение EXECUTIONS_DATA_PRUNE_MAX_COUNT (по умолчанию: 10 000). Выполняющиеся, ожидающие или новые выполнения, а также выполнения с тегами или оценками, при этом никогда не удаляются. Кроме того, буфер безопасности через переменную EXECUTIONS_DATA_HARD_DELETE_BUFFER (по умолчанию: один час) обеспечивает то, что вы всё ещё можете просматривать недавно завершённые выполнения, пока память освобождается в фоновом режиме.

• EXECUTIONS_DATA_PRUNE: Включает автоматическую очистку, по умолчанию активна.
• EXECUTIONS_DATA_MAX_AGE: Удаляет выполнения по возрасту в часах, значение по умолчанию 336.
• EXECUTIONS_DATA_PRUNE_MAX_COUNT: Ограничивает общее число сохранённых выполнений, значение по умолчанию 10 000.

Какие изменения workflow дополнительно снижают потребность в памяти?

Помимо серверных настроек, наиболее эффективно снизить потребность в памяти можно непосредственно в дизайне workflow, обрабатывая данные небольшими порциями вместо загрузки всего сразу.

Документация n8n конкретно рекомендует разбивать данные на более мелкие блоки, например обрабатывать 200 записей за одно выполнение вместо 10 000, по возможности избегать узла Code и при больших объёмах данных запускать выполнение не вручную, а через триггер. Для очень больших объёмов данных документация предлагает разбивать workflow на суб-workflow с помощью узла Loop Over Items и узла Execute Workflow, чтобы в памяти хранились только данные текущего пакета, а затем снова освобождались. Если вы используете n8n продуктивно для более сложных автоматизаций и не хотите самостоятельно воссоздавать эти настройки, NordFlux поможет вам с настройкой и защитой workflow n8n, включая соответствующую конфигурацию сервера.

Часто задаваемые вопросы о проблемах с памятью в n8n

Сколько памяти должно быть как минимум у сервера n8n?

Документация не указывает фиксированное минимальное значение, а отмечает, что потребность зависит от объёма данных и числа параллельных выполнений. На практике вам следует предоставить столько памяти, чтобы значение max-old-space-size, заданное через NODE_OPTIONS, было также физически обеспечено, иначе проблема просто сместится.

Решает ли более высокая настройка NODE_OPTIONS любую проблему с памятью?

Нет, более высокий лимит heap лишь даёт больше запаса, но не устраняет истинную причину, например неэффективные workflow или бесконтрольно растущие бинарные данные. Согласно документации, вам следует дополнительно уменьшить объём данных на одно выполнение и оставить execution pruning активным, чтобы потребность в памяти оставалась под постоянным контролем.

Что произойдёт, если я отключу execution pruning?

Без pruning завершённые выполнения вместе с данными выполнения и бинарными данными накапливаются в базе данных без ограничений. Согласно документации, это в долгосрочной перспективе приводит к растущему потреблению памяти, поэтому n8n по умолчанию включает очистку.

Почему ошибка возникает в основном при ручных выполнениях?

Потому что при ручном выполнении через редактор n8n дополнительно хранит копию данных выполнения для отображения в реальном времени во фронтенде. При больших объёмах данных это заметно увеличивает потребность в памяти, поэтому документация рекомендует запускать масштабные обработки через триггер, а не вручную.