文章目录
- 背景
- v8引擎自带的profile
- linux的perf采集
- wasm三方库性能分析
- 编译debug版本wasm
- rust程序debug调试
- 异常模型
- 正常模型
- 结论
- 优化
参考
Node使用火焰图优化CPU爆涨 - 掘金
【Node.js丨主题周】理解perf 与火焰图-腾讯云开发者社区-腾讯云
Easy profiling for Node.js Applications | Node.js
Diagnostics - Flame Graphs | Node.js
perf性能分析工具使用分享
背景
一个node服务在处理模型的时候，发现超时了，并且超过了3分钟的上限触发了报警。行吧，一般来说十几秒足够处理了，初步定位是mikktspace-wasm库的性能问题。
wasm正逐渐走进我们的程序生活，不少计算库都在用高性能语言重写，并通过wasm作为第三方包提供能力。例如博主最近用到的渲染相关的计算包，基本都是用c++和rust实现的，然后web端直接调用wasm即可。
写这篇博客呢，是因为博主一开始只是定位到三方库有问题就暂停了，毕竟是做后端的，也是存在一定的认知障碍吧，对不熟的东西也存在敬畏之心。然而根因不找到实在是难受，一路debug和性能分析下来，回头看看也没那么难。希望以后遇到类似的问题也可以乘风破浪，一路追下去，技术都是相通的，不应该存在壁垒。
v8引擎自带的profile
1、运行程序并采集
node --prof index.js xxx
v8会自动采集，并生成isolate-xxx文件
2、生成txt
node --prof-process isolate-xxx > processed.txt
vim直接打开，就可以查看采集的结果。采集结果分析参考以上链接。
3、查看火焰图npm install -g flamebearer
node --prof-process --preprocess -j isolate-xxx | flamebearer安装flamebearer，并执行上面的命令，会自动打开浏览器，查看生成的火焰图。
注意
运行node程序需要带两个参数：
–perf-basic-prof
通过--perf-basic-prof或 --perf-basic-prof-only-functions我们都可以启动支持
perf_events 的Node.js 应用程序。
--perf-basic-prof-only-functions产生较少的输出，因此它是开销最小的选项。
生成的文件在/tmp/perf-PID.map
–interpreted-frames-native-stack
Node.js 8.x 及更高版本对 V8 引擎中的 JavaScript 编译管道进行了新的优化，这有时会导致
性能无法访问函数名称/引用。使用以上参数可以解决。
linux的perf采集
1、perf采集
perf record -F 99 -g -- node --perf-basic-prof-only-functions index.js会在本地目录生成perf.data文件。2、生成火焰图
perf script | /home/xxx/FlameGraph/stackcollapse-perf.pl | /home/xxx/FlameGraph/flamegraph.pl > perf.svg下载FlameGraph项目，然后使用该项目提供的脚本生成火焰图即可。3、浏览器打开
python -m http.server 8000
浏览器访问ip:8000/perf.svg即可4、运行的时候查看cpu占用
perf top -p pid
使用js的三方库生成火焰图
1、采集perf （同上）
2、安装stackvis库
npm install -g stackvis3、script解析perf.data
perf script > perf.out4、生成火焰图的html
stackvis perf < perfs.out > flamegrap.htm5、浏览器查看（同上）
wasm三方库性能分析
如上所示，有些库使用wasm，导致只能看到库函数占用了97%的cpu，但是却看不到细节。针对这种情况可以考虑编译对应第三方库版本的debug版wasm文件，替换一下，重新采样。
编译debug版本wasm
例如：https://github.com/donmccurdy/mikktspace-wasm 这个库，是用rust编译成wasm的
（1）安装rust环境
https://developer.mozilla.org/zh-CN/docs/WebAssembly/Rust_to_Wasm
（2）编译debug版本
1、编译target为nodejs，对应commonjs标准
~/.cargo/bin/wasm-pack build --dev --target nodejs -d ./pkg/main --out-name mikktspace_main解释：--dev: 编译debug版本-d : 指定输入结果目录，设置为pkg/main--out-name: 指定生成的文件名前缀，wasm文件会自动加上_bg.wasm后缀2、编译target为bundler，对应打包工具的导入标准
~/.cargo/bin/wasm-pack build --dev -d ./pkg/bundler --out-name mikktspace_module3、查看编译的wasm是否是debug的（1）安装wabtsudo pacman -Si wabtwabt自带的有wasm-objdump，可以查看wasm的头信息(2)wasm-objdump -h mikktspace_main_bg.wasmmikktspace_main_bg.wasm: file format wasm 0x1Sections:Type start=0x0000000e end=0x000000fa (size=0x000000ec) count: 35Import start=0x00000100 end=0x00000268 (size=0x00000168) count: 7Function start=0x0000026e end=0x00000542 (size=0x000002d4) count: 722Table start=0x00000548 end=0x0000054d (size=0x00000005) count: 1Memory start=0x00000553 end=0x00000556 (size=0x00000003) count: 1Global start=0x0000055c end=0x00000565 (size=0x00000009) count: 1Export start=0x0000056b end=0x000005fb (size=0x00000090) count: 7Elem start=0x00000601 end=0x00000663 (size=0x00000062) count: 1Code start=0x00000669 end=0x00048a07 (size=0x0004839e) count: 722Data start=0x00048a0d end=0x0004d858 (size=0x00004e4b) count: 1Custom start=0x0004d85e end=0x0005b3f4 (size=0x0000db96) "name"Custom start=0x0005b3fa end=0x0005b475 (size=0x0000007b) "producers"Custom start=0x0005b47b end=0x0005b4a7 (size=0x0000002c) "target_features"可以看到没有debuginfo信息。4、配置cargo.toml
参考：https://rustwasm.github.io/docs/wasm-pack/cargo-toml-configuration.html[package.metadata.wasm-pack.profile.dev.wasm-bindgen]
dwarf-debug-info = false5、重新编译并查看
Custom start=0x00062694 end=0x0014bc2d (size=0x000e9599) ".debug_info"多了一些debuginfo信息。（3）替换node_moudles中的mikktspace/dist下的main和module目录
（4）重新perf采集数据，生成svg
成功采集到mikktspace这个库的调用栈以及cpu耗时。
（5）对比正常和异常情况下的火焰图
正常
相比上面的火焰图，可以发现正常的火焰图：
- cpu耗时分布较合理
- 无长时间耗时函数分布
- 异常火焰图耗时较久的函数DegenEpilogue在正常火焰图中并没有。
因此重点看下DegenEpilogue函数即可。
rust程序debug调试
参考：https://github.com/fucking-translation/blog/blob/main/src/lang/rust/14-%E4%BD%BF%E7%94%A8GDB%E8%B0%83%E8%AF%95Rust%E5%BA%94%E7%94%A8.md
1、编译debug版本
cargo默认编译出来的就是debug版本。指定编程生成的程序名为debug
cargo build --example debug2、rust-gdb调试
rust-gdb调试指令和gdb一样。
(1) 进入gdb
rust-gdb debug
(2) 设置断点
b xxx.rs:10(3) 开启可视化
layout src
如果页面乱了，ctrl+l 可以恢复代码页面(4) 调试
n : 下一步
s : 进入函数内部
c: 运行到下一个断点
异常模型
1、generateTspace部分，iNrActiveGroup = 19w,循环19w次，速度较快，10s执行完整个函数。
2、运行到DegenEpilogue， iNrTrianglesIn = 24w，
while t < iTotTris {} 这个循环耗时90s
// iDegenTriangles = 32412
// iDegenTriangles代表不合法的三角形面
iNrTrianglesIn = iTotTris - iDegenTriangles;
while t < iNrTrianglesIn {} 不耗时
正常模型
1、generateTspace部分，iNrActiveGroup = 172w,16s运行完整个函数
2、运行到DegenEpilogue， iNrTrianglesIn = 58w
while t < iTotTris {} 这个循环没走
原因是不符合whilet条件，t= iTotTris ,关键就在上一步传过来的iNrTrianglesIn和iTotTris
// iDegenTriangles = 0
// iDegenTriangles代表不合法的三角形面
iNrTrianglesIn = iTotTris - iDegenTriangles;
while t < iNrTrianglesIn {} 不耗时
结论
异常的模型中，不合法三角形的数量较多，需要通过DegenEpilogue函数进行辅助处理。正常的模型因为不合法三角形面数量较少，因此不需要进行DegenEpilogue函数处理。
mikktspace计算切面算法有多种语言实现，其中rust程序和c++程序对比来说，c++使用了二分来提升性能，rust和c程序均采用遍历的方式。可以考虑使用hash表减少循环层数或者二分提升查询性能。
mikktspace的c++库：https://github.com/naetherm/mikktspace
mikktspace的c库：https://github.com/mmikk/MikkTSpace
优化
rust程序中，存在双层循环如下：
// iTotTris - t = 3w
while t < iTotTris {// iNrTrianglesIn * 3 = 72wwhile bNotFound && j < 3i32 * iNrTrianglesIn {}
}双层循环情况下，性能较差。内部的循环使用hash表代替，直接通过key去获取。优化后单次循环耗时从ms级
优化到ns级。优化前耗时：90s
优化后耗时：27ms
end
