跳到主要内容

内存相关错误

n8n 不限制各节点可获取和处理的数据量。这提供了灵活性,但当工作流执行所需内存超过可用内存时,可能导致错误。本页介绍如何识别并避免这些错误。

信息

仅适用于自托管 n8n

本页介绍自托管 n8n时的内存相关错误。n8n Cloud 的内存限制请参阅 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(服务暂时不可用)等错误消息,表明 n8n 实例可能已不可用。

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

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

常见原因 ​

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

  • JSON 数据的数量。
  • 二进制数据的大小。
  • 工作流中的节点数量。
  • 部分节点的内存开销较大:Code 节点和旧版 Function 节点可能显著增加内存消耗。
  • 工作流是手动执行还是自动执行:手动执行时,n8n 会为前端复制一份数据,因此内存消耗更高。
  • 同时运行的其他工作流。

避免内存不足 ​

遇到内存不足时有两种选择:增加 n8n 可用内存,或减少内存消耗。

增加可用内存 ​

自托管 n8n 时,增加可用内存意味着为实例分配更多内存,可能产生额外的托管费用。

在 n8n Cloud 上,需要升级到更高规格的套餐。

减少内存消耗 ​

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

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

拆分工作流起初可能显得不符合直觉,因为通常至少还需要添加两个节点:用于将数据项分成小批次的 Loop Over Items(循环遍历数据项)节点,以及用于启动子工作流的 Execute Workflow(执行工作流)节点。

不过,只要由子工作流完成每个批次的主要处理,再仅向主工作流返回较小的结果集,就能减少内存消耗。原因在于,子工作流只在内存中保留当前批次的数据,处理完后便可释放这些内存。

增加老生代内存 ​

此方法适用于自托管 n8n。遇到 JavaScript heap out of memory(JavaScript 堆内存不足)错误时,为 V8 JavaScript 引擎的老生代区域分配更多内存通常有帮助。请通过 CLI 设置相应的 V8 选项 --max-old-space-size=SIZE,或通过 NODE_OPTIONS 环境变量设置。

相关资源 ​

本文为社区中文翻译。查看对应英文原文