參考
Node使用火焰圖優(yōu)化CPU爆漲 - 掘金
【Node.js丨主題周】理解perf 與火焰圖-騰訊云開發(fā)者社區(qū)-騰訊云
Easy profiling for Node.js Applications | Node.js
Diagnostics - Flame Graphs | Node.js
perf性能分析工具使用分享

背景

一個(gè)node服務(wù)在處理模型的時(shí)候，發(fā)現(xiàn)超時(shí)了，并且超過了3分鐘的上限觸發(fā)了報(bào)警。行吧，一般來說十幾秒足夠處理了，初步定位是mikktspace-wasm庫的性能問題。

wasm正逐漸走進(jìn)我們的程序生活，不少計(jì)算庫都在用高性能語言重寫，并通過wasm作為第三方包提供能力。例如博主最近用到的渲染相關(guān)的計(jì)算包，基本都是用c++和rust實(shí)現(xiàn)的，然后web端直接調(diào)用wasm即可。

寫這篇博客呢，是因?yàn)椴┲饕婚_始只是定位到三方庫有問題就暫停了，畢竟是做后端的，也是存在一定的認(rèn)知障礙吧，對不熟的東西也存在敬畏之心。然而根因不找到實(shí)在是難受，一路debug和性能分析下來，回頭看看也沒那么難。希望以后遇到類似的問題也可以乘風(fēng)破浪，一路追下去，技術(shù)都是相通的，不應(yīng)該存在壁壘。

v8引擎自帶的profile

1、運(yùn)行程序并采集
node --prof index.js xxx
v8會自動(dòng)采集，并生成isolate-xxx文件
2、生成txt
node --prof-process isolate-xxx > processed.txt
vim直接打開，就可以查看采集的結(jié)果。采集結(jié)果分析參考以上鏈接。
3、查看火焰圖npm install -g flamebearer
node --prof-process --preprocess -j isolate-xxx | flamebearer安裝flamebearer，并執(zhí)行上面的命令，會自動(dòng)打開瀏覽器，查看生成的火焰圖。

注意
運(yùn)行node程序需要帶兩個(gè)參數(shù)：
–perf-basic-prof

通過--perf-basic-prof或 --perf-basic-prof-only-functions我們都可以啟動(dòng)支持
perf_events 的Node.js 應(yīng)用程序。
--perf-basic-prof-only-functions產(chǎn)生較少的輸出，因此它是開銷最小的選項(xiàng)。
生成的文件在/tmp/perf-PID.map

–interpreted-frames-native-stack

Node.js 8.x 及更高版本對 V8 引擎中的 JavaScript 編譯管道進(jìn)行了新的優(yōu)化，這有時(shí)會導(dǎo)致
性能無法訪問函數(shù)名稱/引用。使用以上參數(shù)可以解決。

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項(xiàng)目，然后使用該項(xiàng)目提供的腳本生成火焰圖即可。3、瀏覽器打開
python -m http.server 8000
瀏覽器訪問ip:8000/perf.svg即可4、運(yùn)行的時(shí)候查看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，導(dǎo)致只能看到庫函數(shù)占用了97%的cpu，但是卻看不到細(xì)節(jié)。針對這種情況可以考慮編譯對應(yīng)第三方庫版本的debug版wasm文件，替換一下，重新采樣。

編譯debug版本wasm

例如：https://github.com/donmccurdy/mikktspace-wasm 這個(gè)庫，是用rust編譯成wasm的
（1）安裝rust環(huán)境
https://developer.mozilla.org/zh-CN/docs/WebAssembly/Rust_to_Wasm
（2）編譯debug版本

1、編譯target為nodejs，對應(yīng)commonjs標(biāo)準(zhǔn)
~/.cargo/bin/wasm-pack build --dev --target nodejs -d ./pkg/main --out-name mikktspace_main解釋：--dev: 編譯debug版本-d : 指定輸入結(jié)果目錄，設(shè)置為pkg/main--out-name: 指定生成的文件名前綴，wasm文件會自動(dòng)加上_bg.wasm后綴2、編譯target為bundler，對應(yīng)打包工具的導(dǎo)入標(biāo)準(zhǔn)
~/.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"可以看到?jīng)]有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采集數(shù)據(jù)，生成svg

成功采集到mikktspace這個(gè)庫的調(diào)用棧以及cpu耗時(shí)。

（5）對比正常和異常情況下的火焰圖

正常

相比上面的火焰圖，可以發(fā)現(xiàn)正常的火焰圖：

1. cpu耗時(shí)分布較合理
2. 無長時(shí)間耗時(shí)函數(shù)分布
3. 異?；鹧鎴D耗時(shí)較久的函數(shù)DegenEpilogue在正?；鹧鎴D中并沒有。

因此重點(diǎn)看下DegenEpilogue函數(shù)即可。

rust程序debug調(diào)試

參考：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默認(rèn)編譯出來的就是debug版本。指定編程生成的程序名為debug
cargo build --example debug2、rust-gdb調(diào)試
rust-gdb調(diào)試指令和gdb一樣。
(1) 進(jìn)入gdb
rust-gdb debug
(2) 設(shè)置斷點(diǎn)
b xxx.rs:10(3) 開啟可視化
layout src
如果頁面亂了，ctrl+l 可以恢復(fù)代碼頁面(4) 調(diào)試
n : 下一步
s : 進(jìn)入函數(shù)內(nèi)部
c: 運(yùn)行到下一個(gè)斷點(diǎn)

異常模型

1、generateTspace部分，iNrActiveGroup = 19w,循環(huán)19w次，速度較快，10s執(zhí)行完整個(gè)函數(shù)。
2、運(yùn)行到DegenEpilogue， iNrTrianglesIn = 24w，
while t < iTotTris {} 這個(gè)循環(huán)耗時(shí)90s

// iDegenTriangles = 32412
// iDegenTriangles代表不合法的三角形面
iNrTrianglesIn = iTotTris - iDegenTriangles;

while t < iNrTrianglesIn {} 不耗時(shí)

正常模型

1、generateTspace部分，iNrActiveGroup = 172w,16s運(yùn)行完整個(gè)函數(shù)
2、運(yùn)行到DegenEpilogue， iNrTrianglesIn = 58w
while t < iTotTris {} 這個(gè)循環(huán)沒走
原因是不符合whilet條件，t= iTotTris ,關(guān)鍵就在上一步傳過來的iNrTrianglesIn和iTotTris

// iDegenTriangles = 0
// iDegenTriangles代表不合法的三角形面
iNrTrianglesIn = iTotTris - iDegenTriangles;

while t < iNrTrianglesIn {} 不耗時(shí)

結(jié)論

異常的模型中，不合法三角形的數(shù)量較多，需要通過DegenEpilogue函數(shù)進(jìn)行輔助處理。正常的模型因?yàn)椴缓戏ㄈ切蚊鏀?shù)量較少，因此不需要進(jìn)行DegenEpilogue函數(shù)處理。

mikktspace計(jì)算切面算法有多種語言實(shí)現(xiàn)，其中rust程序和c++程序?qū)Ρ葋碚f，c++使用了二分來提升性能，rust和c程序均采用遍歷的方式?？梢钥紤]使用hash表減少循環(huán)層數(shù)或者二分提升查詢性能。

mikktspace的c++庫：https://github.com/naetherm/mikktspace
mikktspace的c庫：https://github.com/mmikk/MikkTSpace

優(yōu)化

rust程序中，存在雙層循環(huán)如下：

// iTotTris - t = 3w
while t < iTotTris {// iNrTrianglesIn * 3 = 72wwhile bNotFound && j < 3i32 * iNrTrianglesIn {}
}雙層循環(huán)情況下，性能較差。內(nèi)部的循環(huán)使用hash表代替，直接通過key去獲取。優(yōu)化后單次循環(huán)耗時(shí)從ms級
優(yōu)化到ns級。優(yōu)化前耗時(shí)：90s
優(yōu)化后耗時(shí)：27ms

end