1. 为什么需要PM2管理Node.js应用刚接触Node.js开发时我习惯直接用node app.js启动服务。直到有次半夜收到报警短信——线上服务挂了连滚带爬爬起来重启服务器的经历让我彻底明白了进程管理工具的重要性。Node.js的单线程架构就像杂技演员走钢丝任何一个未捕获的异常都会导致整个应用崩溃。PM2的核心价值在于把走钢丝变成安全网。我做过对比测试一个故意制造内存泄漏的应用裸跑Node.js平均存活2小时而用PM2管理的实例存活了整整30天。这得益于它的三大看家本领进程守护像贴身保镖一样盯着你的应用崩溃瞬间自动重启多核利用一键启动集群模式把单线程变成多线程战士零秒重载更新代码时无缝切换用户完全无感知实际项目中遇到过个典型场景某电商大促时API响应速度从200ms飙升到2秒。用PM2的-i max参数启动集群模式后吞吐量直接翻了4倍测试服务器是8核CPU。这比临时加服务器成本低多了老板看监控报表时眼睛都亮了。2. 五分钟快速上手PM2安装PM2比煮泡面还简单但有些细节决定了你是能用还是用好。先看安装命令npm install pm2 -g装完后别急着启动我强烈推荐先做两件事第一建立日志目录结构mkdir -p ~/logs/pm2第二创建基础配置文件后面会详细讲pm2 init simple现在可以启动你的第一个PM2应用了pm2 start app.js --name api-service \ --log ~/logs/pm2/api.log \ --error ~/logs/pm2/api-error.log \ --time这里有几个实用技巧--time参数会给日志加上时间戳排查问题时特别有用错误日志单独存放避免和正常日志混在一起给应用起个有意义的名称别再用默认的app了启动后试试这些常用命令# 查看应用状态 pm2 list # 监控资源占用 pm2 monit # 查看实时日志 pm2 logs3. 集群模式深度配置PM2最强大的功能莫过于集群模式但很多人只停留在-i max的层面。下面分享几个实战中的高阶配置CPU亲和性绑定适合计算密集型应用// ecosystem.config.js module.exports { apps: [{ name: cpu-intensive, script: ./server.js, instances: 4, exec_mode: cluster, instance_var: INSTANCE_ID, cpu_affinity: 0,1,2,3 // 绑定到指定CPU核心 }] }智能重启策略防止频繁重启死循环{ min_uptime: 60s, // 运行不足60秒视为异常 max_restarts: 10, // 10次异常重启后放弃 restart_delay: 5000, // 每次重启间隔5秒 autorestart: false // 开发环境可关闭自动重启 }内存监控重启防范内存泄漏{ max_memory_restart: 1G, // 内存超1GB自动重启 vizion: false // 关闭源码版本控制提升性能 }实际案例某SSR应用内存泄漏配置max_memory_restart后虽然没彻底解决问题但保证了服务可用性为修复争取了时间。监控显示内存使用呈锯齿状始终控制在1GB以内。4. 生产环境部署方案线上环境我推荐使用配置文件管理分享一个经过实战检验的模板// ecosystem.config.js module.exports { apps: [{ name: prod-api, script: dist/main.js, instances: max, exec_mode: cluster, // 错误日志记录完整堆栈 error_file: /var/log/pm2/api-error.log, out_file: /var/log/pm2/api-out.log, combine_logs: true, // 环境变量 env: { NODE_ENV: production, PORT: 3000, MAX_SOCKETS: 1000 }, // 高级配置 min_uptime: 60s, max_restarts: 5, listen_timeout: 5000, kill_timeout: 3000 }] }关键配置解析listen_timeout应用启动超时设置配合健康检查使用kill_timeout发送SIGKILL前的等待时间保证优雅退出combine_logs集群模式下合并日志方便追踪请求链路部署流程建议通过pm2 startOrReload实现无缝重启使用pm2 save保存进程状态配置pm2 startup实现开机自启5. 监控与问题排查PM2自带的监控已经很强大了但还有更专业的玩法自定义指标上报const pm2 require(pm2) // 上报业务指标 setInterval(() { pm2.sendDataToProcessId({ type: process:metric, data: { rps: getRequestPerSecond(), queueSize: getQueueLength() }, id: process.pm_id }, (err) {}) }, 5000)日志分析技巧# 查看最近1小时的错误日志 pm2 logs --lines 1000 --timestamp YYYY-MM-DD HH:mm | grep -E $(date -d 1 hour ago %Y-%m-%d %H:[0-9]{2}) | grep -i error内存泄漏排查步骤用pm2 monit观察内存增长趋势通过pm2 describe id查看重启次数对频繁重启的实例生成堆快照pm2 trigger id heapdump曾经用这个方法发现过一个隐蔽的缓存泄漏——某中间件缓存了用户会话但忘了设置TTL内存每小时增长2%。配置max_memory_restart后作为临时方案同时修复了缓存逻辑。6. 高级特性实战日志轮转配置避免磁盘爆满{ log_type: json, // JSON格式便于分析 log_date_format: YYYY-MM-DD HH:mm Z, rotate_logs: true, // 开启轮转 worker_interval: 3600, // 每小时检查 max_file_size: 10M, // 单个日志最大10MB retain: 30 // 保留30个文件 }多环境管理// ecosystem.config.js module.exports { apps: [{ name: app, script: ./app.js, env: { NODE_ENV: development, REDIS_HOST: localhost }, env_staging: { NODE_ENV: staging, REDIS_HOST: staging.redis.example.com }, env_production: { NODE_ENV: production, REDIS_HOST: cluster.redis.example.com } }] }启动时指定环境pm2 start ecosystem.config.js --env production与Docker集成FROM node:18-alpine RUN npm install pm2 -g COPY . /app WORKDIR /app # 注意这里要用pm2-runtime启动 CMD [pm2-runtime, ecosystem.config.js]关键点使用pm2-runtime替代pm2 start这是专为容器设计的入口在K8S中要配置正确的livenessProbelivenessProbe: httpGet: path: /health port: 3000 initialDelaySeconds: 30 periodSeconds: 107. 常见踩坑与解决方案坑1应用启动慢导致PM2误判现象频繁重启日志显示App timeout 解决{ listen_timeout: 10000, // 增加超时阈值 wait_ready: true, // 等待应用发出ready信号 kill_timeout: 30000 // 延长kill超时 }应用端需要添加健康检查const http require(http) const server http.createServer() server.listen(3000, () { // 通知PM2应用已就绪 if (process.send) { process.send(ready) } })坑2文件描述符泄漏现象运行几天后出现EMFILE错误 解决{ increment_var: NODE_APP_INSTANCE, instance_var: INSTANCE_ID, vizion: false // 关闭文件监听 }同时调整系统限制ulimit -n 100000 pm2 restart all坑3Graceful shutdown失效正确配置信号处理process.on(SIGINT, () { db.close(() { process.exit(0) }) })PM2配置对应调整{ shutdown_with_message: true, kill_timeout: 30000 }