网站内页产品 首页推荐,聊城设计网站,中国vs菲律宾世预赛,最近免费字幕中文大全文章目录 背景v8引擎自带的profilelinux的perf采集wasm三方库性能分析编译debug版本wasmrust程序debug调试异常模型正常模型结论优化 参考 Node使用火焰图优化CPU爆涨 - 掘金 【Node.js丨主题周】理解perf 与火焰图-腾讯云开发者社区-腾讯云 Easy profiling for Node.js Applic… 文章目录 背景v8引擎自带的profilelinux的perf采集wasm三方库性能分析编译debug版本wasmrust程序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 start0x0000000e end0x000000fa (size0x000000ec) count: 35Import start0x00000100 end0x00000268 (size0x00000168) count: 7Function start0x0000026e end0x00000542 (size0x000002d4) count: 722Table start0x00000548 end0x0000054d (size0x00000005) count: 1Memory start0x00000553 end0x00000556 (size0x00000003) count: 1Global start0x0000055c end0x00000565 (size0x00000009) count: 1Export start0x0000056b end0x000005fb (size0x00000090) count: 7Elem start0x00000601 end0x00000663 (size0x00000062) count: 1Code start0x00000669 end0x00048a07 (size0x0004839e) count: 722Data start0x00048a0d end0x0004d858 (size0x00004e4b) count: 1Custom start0x0004d85e end0x0005b3f4 (size0x0000db96) nameCustom start0x0005b3fa end0x0005b475 (size0x0000007b) producersCustom start0x0005b47b end0x0005b4a7 (size0x0000002c) 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 start0x00062694 end0x0014bc2d (size0x000e9599) .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
如果页面乱了ctrll 可以恢复代码页面(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
优化后耗时27msend
