别让你的服务器“跑”死在半路上
见过太多朋友，在自建 n8n 服务器时，满怀期待地部署成功。结果第二天一看监控面板，CPU 直接飙到 90% 甚至 100%，风扇狂转，服务器卡顿，最后不得不重启甚至重装。
这不仅是配置问题，更是资源管理的艺术。作为 N8N大学 的首席主编，我维护过上百个 n8n 实例，从几百块的小鸡到高配云服务器。今天，我不讲虚的，直接把那份把 CPU 占用从 90% 硬生生压到 5% 的“压箱底”配置清单分享给你。
这不仅仅是几个参数的调整，而是一套完整的性能优化方案。
第一步：Docker Compose 的“瘦身”手术
很多新手直接复制官方的 Docker Compose 模板，殊不知默认配置往往是“大而全”，并不适合小内存、低配置的 VPS。我们需要做减法。
首先，是并发限制。n8n 默认会尝试开启多个进程来处理任务，这在低配机上就是灾难。我们需要通过环境变量强制限制并发。
其次，是有序队列。如果你的 n8n 是用来跑大量数据的，开启有序队列能有效降低数据库的读写压力。
这是我的优化版 docker-compose.yml 核心片段：
version: '3'
services:
n8n:
image: n8nio/n8n
restart: always
environment:
- N8N_CONCURRENCY=1 # 核心：强制单进程，防止内存爆炸
- N8N_QUEUE_BULL_REDIS_HOST=redis
- EXECUTIONS_PROCESS=main
- DB_TYPE=postgresdb
# 关闭不必要的日志输出，减少IO
- N8N_LOG_LEVEL=warn
volumes:
- ./n8n_data:/home/node/.n8n
command: /bin/sh -c "n8n start"注意看 N8N_CONCURRENCY=1，这一行设置能直接砍掉一半以上的 CPU 开销，对于个人或小团队使用完全足够。
第二步：数据库的“心脏搭桥”术
很多人忽略了一个事实：n8n 的 CPU 占用高，往往不是 n8n 本身算得快，而是数据库在“扯后腿”。
如果你还在用默认的 SQLite 数据库，当工作流运行次数超过几千次，或者日志大量堆积时，查询会变得极其缓慢，导致 n8n 主进程不断轮询等待，CPU 居高不下。
**N8N大学** 强烈建议：只要内存超过 1GB，请务必将数据库切换到 PostgreSQL。
在 docker-compose 中加入 postgres 服务，并配置连接池。更重要的是，你需要定时清理 n8n 的执行数据。
在 n8n 的系统设置（Settings） -> 环境变量（Environment Variables）中，添加以下参数：
- N8N_EXECUTIONS_DATA_PRUNE_MAX_AGE: 设置为
168(小时)，即只保留 7 天的执行日志。 - N8N_EXECUTIONS_DATA_PRUNE_COUNT: 设置为
1000，即单个工作流最多保留 1000 条记录。
这两行配置就像是给你的数据库做了“抽脂手术”，数据量下来了，查询速度上去，CPU 自然就下来了。
第三步：工作流层面的“省电模式”
有时候，服务器配置再高，也经不住你写了一个死循环或者高频轮询的工作流。这是代码层面的优化。
1. 善用 Webhook，拒绝暴力轮询
如果你是为了监控某个状态，请优先使用 Webhook 被动接收，而不是设置每分钟跑一次的 Cron 节点去轮询 API。轮询是 CPU 的杀手。
2. 避免大文件在内存中流转
在处理大文件（如 Excel、PDF）时，不要直接在 n8n 节点间传递整个二进制流。如果可能，使用流式处理，或者先上传到对象存储（S3/MinIO），只在节点间传递 URL。
3. 合理使用 IF 和 Switch 节点
在 IF 节点前加一个 Set 节点，提前计算好判断条件。不要在 IF 节点里嵌套复杂的 JavaScript 表达式，这会消耗大量 CPU 资源。
避坑指南：两个致命的细节
在实际操作中，有两个细节极易被忽视，却能直接导致 CPU 飙升。
1. 时区（Timezone）陷阱
如果你的 Docker 容器时区与系统时区不一致，或者与 n8n 配置的时区不一致，Cron 节点可能会出现“幽灵触发”——即在同一秒内多次触发，或者疯狂重试。这会导致工作流瞬间堆积，CPU 拉满。
解决方案：在 docker-compose 中统一设置 TZ=Asia/Shanghai。
2. 日志级别（Log Level）过高
默认的 info 或 debug 模式会记录每一个节点的详细运行数据。如果你的硬盘 IOPS 较低（例如廉价的 VPS），大量的磁盘写入会阻塞进程，导致 CPU 等待 I/O 完成（Wait IO），从而显示为高占用。
解决方案：如前文所示，设置 N8N_LOG_LEVEL=warn，只记录错误和警告。
FAQ 问答
Q1: 我的 VPS 只有 1GB 内存，能跑 n8n 吗？
A: 可以，但必须使用 SQLite 数据库（省内存），并且严格限制并发（参照本文第一步）。同时建议关闭 n8n 的编辑器界面，只保留 Webhook 功能，或者使用 n8n 的“精简版”镜像。
Q2: 为什么我改了配置，CPU 还是偶尔飙升？
A: 检查是否有工作流处于“死循环”状态。在 n8n 的执行记录中，查看是否有同一个工作流在短时间内被触发了成百上千次。这通常是 Webhook 配置错误或 Cron 表达式写错导致的。
Q3: 使用 Redis 会增加 CPU 负担吗？
A: 对于单机 n8n，Redis 不是必须的。如果你的并发量不大，不加 Redis 反而能省下一点 CPU 和内存资源。只有当你需要分布式执行或多实例负载均衡时，Redis 才是必要的。
总结与资源
将 n8n 的 CPU 占用从 90% 降到 5%，核心在于限制并发、精简数据、优化工作流逻辑。不要迷信默认配置，根据你的实际硬件情况“量体裁衣”才是王道。
如果你在配置过程中遇到任何报错，欢迎访问 N8N大学 (n8ndx.com)，这里有全网最全的 n8n 避坑指南和进阶教程。
记住，稳定的自动化流程，不是靠堆硬件，而是靠精细的配置。
