Node 项目排查启动变慢,可以先看 --prof 生成的 CPU profile

52 次浏览3 条回复

Node 服务启动或某段脚本执行变慢时,可以先用 V8 自带的 profiler 采样,不用马上加一堆日志。环境:Node.js 18+。

node --prof app.js
node --prof-process isolate-0x*.log > processed.txt

第二条会把采样日志转换成人能读的结果,先看 JavaScript、C++ 和 shared library 各自占了多少时间。脚本正常退出后再处理日志;如果进程一直跑着,可以结束进程让它落盘。

它更适合找 CPU 热点,不太能说明数据库或网络等待。线上采样前也要留意日志文件体积和性能开销,定位到函数后再用更小范围的基准测试确认。

补充一个 Node 18+ 之后更顺手的选项:如果想直接在 Chrome DevTools 里看火焰图,可以试试 node --cpu-prof app.js,进程退出后会生成 .cpuprofile 文件,导入 Performance 面板即可。

不过启动变慢时最好先单独测冷启动和常驻请求,别把初始化阶段的热点跟服务运行期混在一起;两者的优化方向经常不一样。

uitfLv1#1

补充一个 Node 18+ 之后更顺手的选项:如果想直接在 Chrome DevTools 里看火焰图,可以试试 node --cpu-prof app.js,进程退出后会生成 .cpuprofile 文件,导入 Performance 面板即可。

不过启动变慢时最好先单独测冷启动和常驻请求,别把初始化阶段的热点跟服务运行期混在一起;两者的优化方向经常不一样。

--cpu-prof 生成的文件名和位置也可以显式控制,比如在容器或 CI 里加 --cpu-prof-dir=/tmp/profiles,排查时更容易收集。另一个小坑是要让进程正常退出,强制杀掉时可能来不及把 profile 写完整。

ZiorLv1#2

--cpu-prof 生成的文件名和位置也可以显式控制,比如在容器或 CI 里加 --cpu-prof-dir=/tmp/profiles,排查时更容易收集。另一个小坑是要让进程正常退出,强制杀掉时可能来不及把 profile 写完整。

再补个容易踩的坑:isolate-0x*.log 在本地目录里可能会匹配到上一次残留的日志,处理前最好放到干净的临时目录,或者给 --logfile 指定固定文件名。这样不会把不同启动过程的采样混在一起,尤其是脚本反复重跑时。