1. 项目概述为什么你需要一份靠谱的PM2命令手册如果你在用Node.js做后端开发或者部署前端应用PM2这个名字你肯定不陌生。它不是什么新潮玩意儿但绝对是生产环境里最让人省心的进程管理工具之一。我见过太多团队项目上线后Node进程动不动就挂了半夜被报警叫起来重启服务或者日志把磁盘写满了导致服务崩溃。这些糟心事用一个配置得当的PM2基本都能解决。网上搜“pm2命令”出来的结果五花八门有的过于简略只给几个例子有的又堆砌了所有参数让人眼花缭乱。新手看了不知道从哪入手老手想查个冷门参数也得翻半天。更头疼的是很多命令的上下文和实际使用场景是割裂的你只知道pm2 start app.js但为什么有时候要加--namecluster模式和fork模式到底差在哪出问题了怎么快速定位这些经验性的东西很少有文章系统讲透。所以我决定结合自己这些年踩过的坑、趟过的雷整理一份真正“能用”、“好用”的PM2常用命令汇总。这份汇总不会像官方文档那样事无巨细而是聚焦于你从开发到上线、从监控到排障最可能用到的那些命令并且会重点解释在什么场景下该用哪个命令、为什么要这么用以及背后那些容易忽略的细节。毕竟工具的价值不在于你知道多少命令而在于你能用多快的速度解决实际问题。2. PM2核心概念与工作模式解析在敲命令之前我们得先搞清楚PM2到底在管什么以及它是怎么管的。这能帮你理解后面所有命令的行为而不是死记硬背。2.1 进程管理模型Fork模式 vs Cluster模式这是PM2最核心的一个概念也直接影响到你应用的性能和稳定性。Fork模式是默认模式。当你执行pm2 start app.js时PM2会直接fork当前的Node.js进程来运行你的应用。这个模式简单直接但有个致命问题它只用一个CPU核心。如果你的服务器是4核甚至8核的其他核心就闲置了无法充分利用多核性能。我早期就犯过这个错误在一个4核服务器上跑一个计算密集型的API服务用Fork模式性能死活上不去后来才发现CPU只用满了25%。Cluster模式就是为了解决这个问题而生的。你需要通过pm2 start app.js -i max这样的命令来启动。PM2会创建一个主进程Master然后根据你指定的实例数-i参数fork出多个子进程Worker来运行你的应用代码。这些Worker进程共享同一个端口由主进程负责负载均衡。这样一来你的应用就能横向扩展到多个CPU核心上性能几乎是线性提升。注意不是所有应用都适合Cluster模式。如果你的应用有很强的状态依赖比如在内存里维护了全局的WebSocket连接映射切换到Cluster模式可能会导致状态不一致因为请求可能被路由到不同的Worker进程。通常无状态的API服务、静态文件服务最适合Cluster模式。2.2 生态系统文件告别冗长命令行的秘密你是不是经常看到一长串的启动命令像这样pm2 start app.js --name my-api --watch --ignore-watchnode_modules logs --max-memory-restart 300M --log /var/log/my-api.log --error /var/log/my-api-err.log每次启动都要敲这么一长串不仅容易出错也不好维护。PM2的生态系统文件通常叫ecosystem.config.js就是来解决这个问题的。它允许你把所有配置写在一个JS文件里。// ecosystem.config.js module.exports { apps: [{ name: my-api, script: ./app.js, instances: max, // 使用Cluster模式并利用所有CPU核心 exec_mode: cluster, watch: true, ignore_watch: [node_modules, logs], max_memory_restart: 300M, env: { NODE_ENV: development, }, env_production: { NODE_ENV: production, }, log_file: /var/log/my-api.log, error_file: /var/log/my-api-err.log, out_file: /var/log/my-api-out.log, merge_logs: true, log_date_format: YYYY-MM-DD HH:mm:ss }] };配置好后启动命令就简化成了pm2 start ecosystem.config.js。如果要启动生产环境配置可以用pm2 start ecosystem.config.js --env production。管理多个应用、进行团队协作时这个配置文件的价值就凸显出来了它是PM2配置的“唯一真相来源”。2.3 日志管理不仅仅是输出到控制台PM2的日志系统比很多人想象的要强大。默认情况下日志会输出到~/.pm2/logs/目录下以[app-name]-out.log和[app-name]-error.log分别保存标准输出和错误日志。但生产环境我们往往有更多需求日志轮转Log Rotation这是防止日志撑爆磁盘的必备操作。PM2内置了pm2-logrotate模块可以按时间或文件大小自动切割、压缩、删除旧日志。安装和配置命令如下pm2 install pm2-logrotate pm2 set pm2-logrotate:max_size 10M # 单个日志文件最大10M pm2 set pm2-logrotate:retain 30 # 保留30个备份文件 pm2 set pm2-logrotate:compress true # 压缩旧日志 pm2 set pm2-logrotate:dateFormat YYYY-MM-DD_HH-mm-ss我强烈建议在服务器初始化后就配置好这个不然等磁盘报警就晚了。日志聚合与格式化在Cluster模式下多个实例的日志默认是分开的。你可以通过配置merge_logs: true将它们合并到一个文件方便查看。同时log_date_format参数可以让你自定义时间戳格式便于后续用ELK、Sentry等工具进行采集和分析。3. 开发与部署全流程命令详解这一部分我们按照一个应用从本地开发到服务器上线的完整流程来梳理最核心的那些命令。3.1 启动与停止基础中的基础启动应用看似简单但选项很多。启动单个应用# 最基本启动 pm2 start app.js # 给应用起个名字方便后续管理 pm2 start app.js --name my-server # 启动并开启文件监听文件变化自动重启开发神器 pm2 start app.js --name my-server --watch # 启动Cluster模式利用所有CPU核心生产环境推荐 pm2 start app.js -i max --name my-server # 通过生态系统文件启动 pm2 start ecosystem.config.js pm2 start ecosystem.config.js --env production # 指定生产环境配置停止应用# 通过App name停止 pm2 stop my-server # 通过PM2分配的ID停止可以通过 pm2 list 查看ID pm2 stop 0 # 停止所有应用 pm2 stop all这里有个关键区别stop是优雅停止PM2会发送SIGINT信号给进程让你的应用有机会执行清理操作如关闭数据库连接。而delete是强制删除直接从PM2的进程列表里移除。所以通常流程是先stop再delete。3.2 状态查看与监控了解你的应用健康度启动后你不能当甩手掌柜得知道它跑得怎么样。列表与详情# 简洁列表查看所有进程状态 pm2 list # 或者 pm2 ls # 以更漂亮的表格形式展示monit命令的静态快照 pm2 monit # 查看某个应用的详细信息包括运行路径、参数、环境变量等 pm2 show my-server # 或 pm2 describe my-server日志查看# 查看指定应用的最新日志默认显示最后20行 pm2 logs my-server # 查看并实时尾随日志类似 tail -f pm2 logs my-server --lines 100 --raw # --raw 显示原始日志不格式化 # 只查看错误日志 pm2 logs my-server --err # 只查看标准输出日志 pm2 logs my-server --out # 清空某个应用的日志文件文件内容会被清空但进程不会重启 pm2 flush my-serverpm2 logs是我调试时用得最多的命令之一。--lines参数可以控制显示的历史行数--raw在排查一些特殊格式输出时非常有用。性能监控# 打开实时监控仪表板可以看到CPU、内存占用以及实时日志 pm2 monitpm2 monit会打开一个基于终端的图形化界面非常直观。但对于无GUI的服务器或者需要集成到监控系统时我们更需要数据接口。# 以JSON格式输出所有进程的详细状态信息便于脚本处理 pm2 jlist # 或者 pm2 list --json # 生成一个简单的Web API返回进程状态默认端口9615 pm2 webpm2 web启动后访问http://your-server-ip:9615就能得到一个包含状态信息的JSON接口可以很方便地和Zabbix、Prometheus等监控系统集成。3.3 进程生命周期管理重启、重载与删除应用更新或配置变更后需要让新代码生效。重启 vs 重载这是两个最容易混淆也最重要的命令。# 重启先停止再启动。服务会有短暂中断。 pm2 restart my-server pm2 restart all # 重启所有应用 # 重载仅Cluster模式零停机重启。逐个重启Worker进程始终保持有进程在服务。 pm2 reload my-server pm2 reload all实操心得对于Web服务生产环境更新代码时务必使用reload。restart会造成所有Worker同时下线导致正在处理的请求失败。而reload是“滚动手动”主进程会逐个创建新的Worker等待新Worker就绪后再关闭旧的从而实现无缝切换。这是PM2保障高可用的一个关键特性。删除应用# 从PM2列表中删除应用进程会被停止 pm2 delete my-server pm2 delete all # 删除所有并清空列表 # 删除并同时停止相关的日志轮转等设置 pm2 delete my-server --forcedelete之后应用将从pm2 list中消失。如果你只是临时停用建议用stop如果是永久移除再用delete。3.4 持久化与开机自启让服务稳如磐石服务器重启后如何让PM2管理的应用自动恢复这就需要用到保存和生成启动脚本的功能。# 将当前PM2进程列表和配置保存起来 pm2 save # 为当前系统生成开机自启动脚本并启用它 pm2 startup这是部署的最后一步也是至关重要的一步。pm2 save命令会将当前运行的应用列表快照保存到~/.pm2/dump.pm2文件中。而pm2 startup命令更神奇它会检测你的系统是systemd, upstart还是init.d然后生成并安装一个对应的服务脚本。这个服务脚本会在系统启动时自动运行pm2 resurrect命令读取之前保存的dump.pm2文件把所有应用原样拉起来。操作流程通常是启动你的所有应用并调整好状态。运行pm2 save。运行pm2 startup并按照它输出的命令通常是sudo env PATH$PATH:... pm2 startup ...执行一次完成服务安装。重启服务器验证应用是否自动恢复。注意pm2 startup生成的命令里包含了当前用户的PATH等信息。如果你切换了用户或者Node环境可能需要重新运行pm2 startup。另外在Docker容器中一般不需要这个因为容器本身通常不是持久化的。4. 高级运维与排障命令实战当应用出现问题时这些命令就是你的“手术刀”。4.1 深入性能剖析与内存快照应用变慢了或者内存泄漏了光看监控图表不够需要深入进程内部。V8分析器与堆快照# 生成一份60秒的CPU性能分析文件.cpuprofile pm2 profile my-server 60 # 生成一份堆内存快照文件.heapsnapshot pm2 heapdump my-server生成的文件默认在~/.pm2/目录下。你可以把这些文件下载到本地用Chrome DevTools的JavaScript Profiler和Memory标签页打开分析。这对于定位CPU热点函数和内存泄漏对象有奇效。我曾经用这个功能找到一个第三方库因为缓存策略错误导致的内存缓慢增长问题。实时交互与信号发送# 打开一个类似REPL的交互界面可以查看实时指标 pm2 interact # 向指定进程发送系统信号 pm2 send-signal my-server SIGUSR2send-signal允许你发送自定义信号。例如你的应用里监听了SIGUSR2信号用来执行一些热重载配置的操作就可以通过这个命令触发。4.2 多环境配置与变量管理现代应用通常有开发、测试、生产等多套环境PM2可以很好地管理环境变量。通过命令行传递pm2 start app.js --name my-app --env production -- --db-hostprod-db.example.com注意--的使用它之后的部分会作为参数传递给你的app.js而不是PM2。通过生态系统文件管理如前所述在ecosystem.config.js中定义env和env_production等对象是最清晰的方式。启动时用--env参数切换。使用PM2的模块系统管理密钥对于数据库密码、API密钥等敏感信息不建议硬编码在配置文件中。可以使用PM2模块pm2-module-db这是一个假设名称实际需寻找类似模块或更通用的方式如通过env引用系统环境变量然后在服务器上用export或通过Docker/K8s的Secret机制设置。4.3 模块系统扩展PM2的能力PM2本身是一个进程管理器但它的模块系统可以为其添加各种功能。# 列出已安装和可安装的模块 pm2 module:list pm2 module:available # 安装一个模块例如我们之前提到的日志轮转模块 pm2 install pm2-logrotate # 安装一个服务器监控模块一个真实的模块示例 pm2 install pm2-server-monit # 卸载模块 pm2 uninstall pm2-logrotate模块就像PM2的“插件”。除了日志轮转还有用于对接KeymetricsPM2的商业监控平台、邮件报警、甚至部署的模块。你可以通过pm2 module:available探索有哪些可用模块。5. 常见问题排查与实操陷阱实录理论说再多不如踩一次坑。下面是我和团队在实践中遇到的一些典型问题及解决方法。5.1 应用启动失败排错三板斧当你执行pm2 start后应用状态显示error或stopped可以按以下顺序排查查看详细错误日志pm2 logs my-app --err --lines 200这是第一步也是最重要的一步。90%的启动问题都能从错误日志里找到原因比如模块找不到、端口被占用、配置文件语法错误等。检查应用本身是否能独立运行 暂时抛开PM2直接到应用目录下运行node app.js或npm start看控制台是否有报错。这能排除PM2环境引入的干扰。检查PM2的启动配置pm2 show my-app仔细核对exec path执行路径、script path脚本路径是否正确。特别是使用相对路径时PM2的当前工作目录可能和你预期的不一样。最佳实践是在生态系统文件里使用绝对路径。5.2 Cluster模式下的常见陷阱端口占用错误Cluster模式下多个Worker进程尝试监听同一个端口如果配置不当可能冲突。确保你的应用代码如Express/Koa监听的是process.env.PORT或一个固定端口PM2的主进程会处理好端口共享。状态不同步如前所述避免在内存中保存全局状态如用户Session。应使用Redis、Memcached等外部存储。日志混乱如果不设置merge_logs: true每个Worker的日志会分开排查问题时需要聚合查看。设置后日志里会包含实例ID格式如my-app-0标准输出和my-app-0-err错误输出。5.3 内存与CPU异常排查流程在pm2 monit里看到某个应用内存持续增长或CPU居高不下初步定位使用pm2 list查看该进程的持续运行时间。如果内存只涨不降且时间很长内存泄漏嫌疑很大。生成堆快照在内存使用较高时执行pm2 heapdump my-app将快照文件下载到本地用Chrome分析。生成CPU剖析报告在CPU使用率高时执行pm2 profile my-app 60生成60秒的性能报告进行分析。隔离测试如果怀疑是特定请求或功能导致可以尝试在测试环境模拟请求同时用上述工具监控。5.4 配置文件与版本管理注意事项ecosystem.config.js应纳入版本控制Git但其中包含的敏感信息密码、密钥应通过环境变量或.env文件该文件在.gitignore中注入。可以使用dotenv模块在应用启动时加载。PM2版本兼容性升级PM2大版本时比如从4.x到5.x有时旧的dump.pm2文件可能不兼容。升级后建议先pm2 kill停止所有守护进程然后重新启动应用并pm2 save。最好在测试环境先验证。权限问题如果使用非root用户运行PM2这应该是一个好习惯并希望监听80或443等特权端口可以配置应用监听3000等高端口再用Nginx反向代理。或者使用authbind、setcap等工具赋予Node程序特定权限但这会带来安全风险需谨慎。最后再分享一个我常用的命令组合用于一键清理和恢复测试环境# 停止并删除所有应用清空日志 pm2 delete all pm2 flush all # 确认列表为空 pm2 list # 从配置文件中重新启动所有应用 pm2 start ecosystem.config.js --env development # 保存当前状态并确保开机自启已配置如果之前配过save即可 pm2 save这套组合拳能保证你的PM2环境处在一个干净、已知的状态对于排除一些因状态累积导致的诡异问题非常有效。记住对于进程管理工具清晰和可预测性比什么都重要。