内存相关错误#

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（服务暂时不可用）的错误消息，通常表明 n8n 实例已无法访问。

在自托管 n8n 时，你可能还会在服务器日志中看到诸如 Allocation failed - JavaScript heap out of memory（分配失败 - JavaScript 堆内存不足）之类的错误信息。

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

常见原因#

此类问题通常发生在工作流执行所需的内存超过了 n8n 实例的可用内存时。以下因素会增加单次工作流执行的内存消耗：

JSON 数据的数量。
二进制数据的大小。
工作流中的节点数量。
某些节点本身内存开销较大：例如 Code 节点和旧版 Function 节点，可能导致内存消耗显著上升。
手动或自动触发的工作流执行：手动执行会增加内存使用，因为 n8n 会为前端复制一份数据。
同时运行的其他工作流。

避免内存不足的情况#

当遇到内存不足（out of memory）的情况时，有两种选择：要么增加 n8n 可用的内存，要么减少内存消耗。

增加可用内存#

在自托管 n8n 时，增加 n8n 的可用内存意味着为 n8n 实例分配更多内存。这可能会导致你的云服务提供商产生额外费用。对于 n8n 云端版本（n8n cloud），你需要升级到更大的套餐计划。

减少内存消耗#

这种方法更为复杂，通常需要重构引发问题的工作流（workflow）。本节提供一些降低内存消耗的建议，并非所有建议都适用于每个工作流。

将处理的数据拆分为更小的批次（chunks）。例如，不要每次执行都获取 10,000 行数据，而是每次处理 200 行。
尽量避免使用 Code 节点（Code node）。
在处理大量数据时，避免手动触发执行。
将工作流拆分为多个子工作流（sub-workflows），并确保每个子工作流返回给父工作流的数据量是有限的。

将工作流拆分起初看起来可能有些违反直觉，因为通常需要额外添加至少两个节点：用于将数据项拆分为较小批次的 Loop Over Items 节点，以及用于启动子工作流的 Execute Workflow 节点。然而，只要你的子工作流为每个批次完成主要处理任务，并仅向主工作流返回一个较小的结果集，这种方式就能有效降低内存消耗。原因是子工作流在运行时仅将当前批次的数据保留在内存中，处理完成后内存即可被释放。

增加旧生代内存#

此方法适用于自托管 n8n 的场景。当遇到 JavaScript heap out of memory（JavaScript 堆内存不足）错误时，通常可以通过为 V8 JavaScript 引擎的旧生代内存区域分配更多内存来解决。为此，可通过命令行（CLI）或 NODE_OPTIONS 环境变量设置相应的 V8 选项：--max-old-space-size=SIZE。