CentOS 上 Node.js 内存管理实战指南
一 内存模型与关键指标
- Node.js 基于 V8 引擎，内存由多部分组成：堆（Heap）、栈（Stack）、代码段以及堆外内存（如 Buffer 的数据）。V8 默认堆上限在 64 位系统约为 1.4GB，32 位系统约为 0.7GB；堆外内存不受 V8 堆上限限制，这也是处理大文件/二进制数据时 RSS 可能高于 heapTotal 的原因。常用观测方式：
- 在代码中调用 process.memoryUsage()，关注 rss、heapTotal、heapUsed、external、arrayBuffers 等指标，用于判断是堆内还是堆外占用偏高。
- 在系统层面用 top/htop 观察进程常驻内存（RSS）趋势，配合日志或定时采样定位增长来源。
二 设置与查看内存限制
- 调整 V8 堆上限（单位 MB）：在启动命令中设置 –max-old-space-size，例如将上限提升到 4GB：
- 命令行：export NODE_OPTIONS=“–max-old-space-size=4096” && node app.js
- 注意：该上限在进程启动时确定，运行中不可动态调整，需重启才能生效。
- 使用进程管理器 PM2 设置重启阈值（治标，便于自愈）：
- 启动：pm2 start app.js --max-memory-restart 4G
- 或在 ecosystem.config.js 中配置 env 与 max_memory_restart，便于统一运维。
- 在 systemd 服务中同时配置环境变量与系统级内存限制（双重保障）：
- Environment=“NODE_OPTIONS=–max-old-space-size=4096”
- MemoryMax=4G（当超过时 systemd 可终止进程，配合 Restart=on-failure 实现自动拉起）
- 变更后执行：systemctl daemon-reload && systemctl restart your-app。
三 定位与排查内存问题
- 快速确认是否泄漏：
- 用 top/htop 观察 RSS 是否随时间单调上升；结合 process.memoryUsage() 定期打点记录趋势（如每分钟一次），判断增长是否异常。
- 抓取与分析堆快照：
- 远程调试：node --inspect app.js，在 Chrome DevTools → Memory 面板采集 Heap Snapshot，对比多次快照中对象数量与保留路径，定位持续增长的根引用。
- 线上快照：使用 heapdump 在关键路径/定时任务中写入快照文件，离线分析：
- const heapdump = require(‘heapdump’); heapdump.writeSnapshot(‘/path/snap.heapsnapshot’);
- 辅助监测：使用 memwatch-next 监听 leak 事件，作为早期告警信号。
- 常见泄漏点与修复要点：
- 全局变量/缓存无限增长：避免向 global 写入大对象；为缓存设置 最大容量与淘汰策略（如 LRU），必要时用 WeakMap/WeakSet 弱化引用。
- 闭包引用不当：仅保留必要外部变量，避免无意间持有大对象。
- 定时器/事件监听器未清理：在组件卸载或不再需要时 clearInterval/clearTimeout 与 removeListener。
- 大对象/大文件一次性加载：改用 Stream 流式处理，降低峰值内存占用。
四 系统层面的优化与兜底
- 运行环境：
- 确保使用 64 位 Node.js 与 64 位 CentOS，避免 32 位进程地址空间受限（常见上限约 1.5GB）。
- 资源与架构：
- 使用 反向代理（如 Nginx） 承载静态资源、做负载均衡与连接管理，减轻 Node.js 事件循环压力。
- 采用 集群模式（cluster） 或多进程/多实例，分摊单进程内存与 GC 压力，提升整体稳定性与吞吐。
- 容器与 cgroups：
- Docker：运行时设置容器内存上限（docker run -m 4g），让容器 OOM 先于进程 OOM，便于编排与重启策略生效。
- cgroups：通过 memory.limit_in_bytes 精细控制进程组内存，配合 cgclassify 将 Node 进程纳入指定 cgroup，作为系统级兜底策略。