Brendan D. Gregg(DTrace书的作者)有一个有趣的分析变体:"Off-CPU"分析(和Off-CPU Flame Graph ; 幻灯片2013,p112-137),以查看线程或应用程序被阻止的位置(是不是由CPU执行,而是等待I/O,页面故障处理程序或由于CPU资源而导致的计划外停机:
这一次揭示了哪些代码路径在CPU外被阻塞和等待,以及准确的持续时间.这与传统的分析不同,后者通常以给定的间隔对线程的活动进行采样,并且(通常)只检查线程是否在CPU上执行工作.
他还可以将Off-CPU配置文件数据和On-CPU配置文件结合在一起:http://www.brendangregg.com/FlameGraphs/hotcoldflamegraphs.html
Gregg给出的示例是使用的dtrace,这在Linux OS中通常不可用.但是有一些类似的工具(ktap,systemtap,perf)和perf我认为最广泛的安装基础.通常perf生成On-CPU配置文件(这些功能在CPU上执行得更频繁).
perf成Linux中的分析工具?PS:来自LISA13,p124的幻灯片中有关于CPU外部火焰图的systemtap变体的链接:" Yichun Zhang创建了这些,并且已经在Linux上使用SystemTap来收集专业数据.请参阅:• http:// agentzh .org/misc/slides/off-cpu-flame-graphs.pdf " "(2013年8月23日的CloudFlare啤酒会议)
我尝试做使用Linux作为perf_events由布伦丹·格雷格描述的一些分析的NodeJS 这里.
工作流程如下:
--perf-basic-prof,这将创建/tmp/perf-(PID).map写入JavaScript符号映射的文件.perf record -F 99 -p `pgrep -n node` -g -- sleep 30stackcollapse-perf.pl脚本折叠堆栈flamegraph.pl脚本生成svg火焰图我得到以下结果(开头看起来非常好):

问题是有很多[unknown]元素,我认为应该是我的nodejs函数调用.我假设整个过程在第3点失败,其中perf数据应该使用由node/v8生成的映射来折叠--perf-basic-prof./tmp/perf-PID.map在节点执行期间创建文件并将一些映射写入其中.
如何解决这个问题呢?
我使用的是CentOS 6.5 x64,并且已经尝试使用节点0.11.13,0.11.14(预建和编译),但没有成功.