Skip to content

内存相关错误#

n8n 不会限制每个节点可以获取和处理的数据量。虽然这给了您自由,但当工作流执行所需内存超过可用内存时,可能会导致错误。本页将介绍如何识别和避免这些错误。

仅适用于自托管 n8n

本页描述的是自托管 n8n 时的内存相关错误。如需了解 n8n Cloud 的内存限制,请参阅云数据管理

识别内存不足情况#

n8n 会提供错误消息来警告您某些内存不足的情况。例如显示 Execution stopped at this node (n8n may have run out of memory while executing it)(执行在此节点停止,n8n 可能在执行时内存不足)等消息。

包含 Problem running workflow(工作流运行问题)、Connection Lost(连接丢失)或 503 Service Temporarily Unavailable(503 服务暂时不可用)的错误消息表明 n8n 实例已不可用。

在自托管 n8n 时,您可能还会在服务器日志中看到 Allocation failed - JavaScript heap out of memory(分配失败 - JavaScript 堆内存不足)等错误消息。

在 n8n Cloud 或使用 n8n 的 Docker 镜像时,n8n 会在遇到此类问题时自动重启。但是当使用 npm 运行 n8n 时,您可能需要手动重启它。

典型原因#

当工作流执行所需内存超过 n8n 实例可用内存时,就会出现此类问题。增加工作流执行内存使用量的因素包括:

  • JSON 数据的数量
  • 二进制数据的大小
  • 工作流中的节点数量
  • 某些节点比较消耗内存:Code 节点和较旧的 Function 节点会显著增加内存消耗
  • 手动或自动工作流执行:手动执行会增加内存消耗,因为 n8n 会为前端复制数据
  • 同时运行的其他工作流

避免内存不足情况#

当遇到内存不足情况时,有两种解决方案:要么增加 n8n 可用的内存量,要么减少内存消耗。

增加可用内存#

在自托管 n8n 时,增加可用内存意味着为您的 n8n 实例配置更多内存。这可能会在您的托管服务提供商处产生额外费用。

在 n8n 云服务上,您需要升级到更大的套餐计划。

减少内存消耗#

这种方法更为复杂,意味着需要重新构建导致问题的工作流。本节提供了一些减少内存消耗的指导原则。并非所有建议都适用于所有工作流。

  • 将处理的数据拆分为更小的块。例如,每次执行不要获取10,000行数据,而是每次处理200行数据。
  • 尽可能避免使用 Code 节点。
  • 处理大量数据时避免手动执行。
  • 将工作流拆分为子工作流,并确保每个子工作流向其父工作流返回有限的数据量。

拆分工作流起初可能看起来有违直觉,因为这通常需要至少添加两个节点:Loop Over Items 节点用于将项目拆分为更小的批次,以及 Execute Workflow 节点用于启动子工作流。

然而,只要您的子工作流为每个批次执行繁重的处理任务,然后仅向主工作流返回少量结果集,这就能降低内存消耗。因为子工作流在内存中只保留当前批次的数据,处理完成后内存就会被释放。

增加老生代内存#

这适用于自托管 n8n。当遇到 JavaScript 堆内存不足错误时,通常为 V8 JavaScript 引擎的老生代内存区分配更多内存会很有帮助。为此,可以通过 CLI 或 NODE_OPTIONS 环境变量 设置相应的 V8 选项 --max-old-space-size=SIZE