n8n сообщает «JavaScript heap out of memory»? Вот как это исправить с помощью NODE_OPTIONS, режима файловой системы и execution pruning.
Ошибка «JavaScript heap out of memory» возникает в n8n, когда для выполнения workflow требуется больше памяти, чем доступно процессу Node.js, на котором работает n8n. Наиболее частыми причинами являются большие бинарные файлы, объёмные данные JSON, узел Code, а также ручные запуски, при которых n8n дополнительно хранит копию данных для интерфейса. Проблему можно решить, выделив процессу n8n больше памяти через переменную окружения NODE_OPTIONS с параметром --max-old-space-size, переключив обработку бинарных данных в режим файловой системы, а также с помощью регулярной очистки выполнений (execution pruning), которая автоматически удаляет старые данные о выполнениях. Актуально на июль 2026 года.
Ошибка возникает потому, что n8n как приложение на Node.js по умолчанию использует лишь ограниченный объём памяти для так называемого размера heap движка V8, и этот предел превышается при workflow с высоким потреблением памяти.
Согласно официальной документации n8n по устранению проблем с памятью, потребность в памяти при выполнении зависит прежде всего от объёма данных JSON, размера бинарных данных, количества одновременных выполнений, а также использования узла Code. Ручные запуски через редактор также увеличивают потребление, поскольку n8n при этом дополнительно хранит копию данных для отображения в реальном времени во фронтенде.
Вы увеличиваете доступную память, передавая процессу 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 автоматически удаляет завершённые выполнения вместе со связанными данными выполнения и бинарными данными по возрасту или количеству, чтобы база данных и память не росли бесконтрольно.
Согласно документации по управлению данными о выполнениях, pruning включён по умолчанию и срабатывает, как только выполнение становится старше значения EXECUTIONS_DATA_MAX_AGE в часах (по умолчанию: 336 часов, то есть 14 дней), либо общее число выполнений превышает значение EXECUTIONS_DATA_PRUNE_MAX_COUNT (по умолчанию: 10 000). Выполняющиеся, ожидающие или новые выполнения, а также выполнения с тегами или оценками, при этом никогда не удаляются. Кроме того, буфер безопасности через переменную EXECUTIONS_DATA_HARD_DELETE_BUFFER (по умолчанию: один час) обеспечивает то, что вы всё ещё можете просматривать недавно завершённые выполнения, пока память освобождается в фоновом режиме.
Помимо серверных настроек, наиболее эффективно снизить потребность в памяти можно непосредственно в дизайне workflow, обрабатывая данные небольшими порциями вместо загрузки всего сразу.
Документация n8n конкретно рекомендует разбивать данные на более мелкие блоки, например обрабатывать 200 записей за одно выполнение вместо 10 000, по возможности избегать узла Code и при больших объёмах данных запускать выполнение не вручную, а через триггер. Для очень больших объёмов данных документация предлагает разбивать workflow на суб-workflow с помощью узла Loop Over Items и узла Execute Workflow, чтобы в памяти хранились только данные текущего пакета, а затем снова освобождались. Если вы используете n8n продуктивно для более сложных автоматизаций и не хотите самостоятельно воссоздавать эти настройки, NordFlux поможет вам с настройкой и защитой workflow n8n, включая соответствующую конфигурацию сервера.
Документация не указывает фиксированное минимальное значение, а отмечает, что потребность зависит от объёма данных и числа параллельных выполнений. На практике вам следует предоставить столько памяти, чтобы значение max-old-space-size, заданное через NODE_OPTIONS, было также физически обеспечено, иначе проблема просто сместится.
Нет, более высокий лимит heap лишь даёт больше запаса, но не устраняет истинную причину, например неэффективные workflow или бесконтрольно растущие бинарные данные. Согласно документации, вам следует дополнительно уменьшить объём данных на одно выполнение и оставить execution pruning активным, чтобы потребность в памяти оставалась под постоянным контролем.
Без pruning завершённые выполнения вместе с данными выполнения и бинарными данными накапливаются в базе данных без ограничений. Согласно документации, это в долгосрочной перспективе приводит к растущему потреблению памяти, поэтому n8n по умолчанию включает очистку.
Потому что при ручном выполнении через редактор n8n дополнительно хранит копию данных выполнения для отображения в реальном времени во фронтенде. При больших объёмах данных это заметно увеличивает потребность в памяти, поэтому документация рекомендует запускать масштабные обработки через триггер, а не вручную.
NordFlux создаёт цифровых сотрудников для организаций: автоматизации и КИ-агентов, которые берут на себя повторяющуюся работу. Вы сохраняете контроль.
Почему агент n8n забывает историю чата, как работают ключи сессии и когда Simple Memory или Postgres Memory является правильным выбором.
ИИ-агента вы создаёте в n8n из четырёх компонентов: триггер, чат-модель, память и инструменты. Инструкция с практическими советами и типичными ошибками.
Сводная страница самых частых ошибок AI Agent node в n8n: prompt, rate limit, memory и Output Parser в одном обзоре, со ссылками на документацию n8n.
NODE_OPTIONS, обращение с бинарными данными и грамотная очистка выполнений (execution pruning) определяют, останется ли n8n стабильным под нагрузкой или продолжит падать с ошибкой «JavaScript heap out of memory». NordFlux берёт на себя сопровождаемую эксплуатацию n8n, включая подбор ресурсов, мониторинг памяти и очистку выполнений, чтобы растущие workflow не превращались в риск простоя. На первой встрече мы проанализируем ресурсы вашего сервера и найдём самые прожорливые по памяти workflow.
