CentOS 上 Node.js 应用的常见性能瓶颈
在 CentOS 环境中，Node.js 的性能瓶颈通常集中在事件循环、系统资源、I/O 路径、数据库与外部依赖、以及部署架构等方面。下面按“现象—原因—快速定位”给出要点。
事件循环与 CPU 密集型任务
- 现象：请求 P95/P99 延迟升高、吞吐上不去、CPU 占用接近 100% 或起伏剧烈。
- 原因：Node.js 为 单线程事件循环，大量计算或 同步 I/O（如 fs.readFileSync） 会阻塞循环；正则回溯（ReDoS）、巨大的 JSON.parse/stringify 也会长时间占用事件循环。
- 快速定位：用 火焰图 看热点函数；用 off-CPU 分析 发现被阻塞的调用点（如同步读、复杂正则）。
- 优化要点：将计算拆分为 Worker Threads/子进程，避免同步 API，优化/简化正则与数据序列化。
内存与垃圾回收
- 现象：RSS 持续增长、频繁 GC 暂停、偶发 OOM、容器被 OOMKilled。
- 原因：内存泄漏（全局缓存无上限、闭包引用、事件监听未移除）、大对象/大文件一次性加载、V8 堆上限设置不当。
- 快速定位：抓取 heapdump 对比多份快照定位泄漏对象；结合 process.memoryUsage() 观察堆与驻留内存变化。
- 优化要点：限制缓存大小（如 LRU）、及时清理监听器、流式处理大文件、必要时用 –max-old-space-size 合理调大堆并配合 GC 日志分析。
I/O 与网络栈
- 现象：数据库/外部 API 调用慢、吞吐受限于 网络带宽/时延、连接建立耗时高。
- 原因：大量 数据库查询 无索引或未用连接池、同步文件读写、未压缩传输、TLS 握手与连接开销大。
- 快速定位：在 Chrome DevTools/Node 检查器 或 APM（如 New Relic/Datadog）查看慢事务与依赖耗时分布。
- 优化要点：为高频查询加索引、使用连接池、启用 流式 传输与压缩、用 NGINX 做反向代理与静态资源缓存、开启 HTTP/2 降低连接开销。
系统与部署架构
- 现象：单实例 CPU 打满、高峰时段整体吞吐上不去、部分实例异常拖垮整体。
- 原因：未做 负载均衡、单实例承载全部流量、系统 文件描述符/内核网络参数 过低、磁盘 I/O 成为瓶颈。
- 快速定位：用 top/htop、vmstat、iostat、free、df 观察 CPU、内存、I/O 与负载；检查 ulimit -n 与关键内核参数。
- 优化要点：多实例 + NGINX 负载均衡（Round Robin/Least Connections）、提升 fs.file-max 与网络参数（如 net.core.somaxconn）、使用 SSD、静态资源走 CDN/NGINX 缓存。
定位与优化工具清单
- 系统监控：top/htop、vmstat、iostat、free、df 观察资源使用与瓶颈所在。
- 进程与应用监控：PM2（集群/监控/日志）、New Relic/Datadog（APM/分布式追踪）。
- 性能剖析：Node 内置 –inspect/–prof、Chrome DevTools；Linux perf + 火焰图 做热点定位；heapdump 分析内存；必要时用 OpenResty XRay 进行低开销的在线动态追踪与火焰图分析。