在分析nodejs程序时,我发现61%的滴答声是由“未知”引起的(见下文)。这可能是什么?我应该寻找什么?
GR,
科恩
Statistical profiling result from node, (14907 ticks, 9132 unaccounted, 0 excluded).
[Unknown]:
ticks total nonlib name
9132 61.3%
[Shared libraries]:
ticks total nonlib name
1067 7.2% 0.0% C:\Windows\SYSTEM32\ntdll.dll
55 0.4% 0.0% C:\Windows\system32\kernel32.dll
[JavaScript]:
ticks total nonlib name
1381 9.3% 10.0% LazyCompile: *RowDataPacket.parse D:\MI\packet.js:9
......
答案 0 :(得分:2)
您是否正在加载任何已构建依赖项的模块?
基本上由“未知”表示“下落不明”(请查看tickprocessor.js
以获取更多解释)。例如,GC将打印“scavenge,begin,...”等消息,但logreader.js
无法识别这些消息。
了解用于解析v8.log
文件的分析库将会有所帮助。
<强>更新强>
node-tick
包的更新时间超过一年,可能缺少很多最近的prof
命令。请尝试使用node-profiler。它由节点的维护者之一创建。如果你想要绝对最好的结果,你需要使用node-gyp
来构建它。
<强>更新强>
我使用node-profiler中的最新内容(v8.log
上的最新内容而非最新标记)解析了master
输出,并将结果发布在http://pastebin.com/pdHDPjzE
请允许我指出一些关键条目,这些条目大约有一半出现:
[GC]:
ticks total nonlib name
2063 26.2%
[Bottom up (heavy) profile]
6578 83.4% c:\node\node.exe
1812 27.5% LazyCompile: ~parse native json.js:55
1811 99.9% Function: ~<anonymous> C:\workspace\repositories\asyncnode_MySQL\lib\MySQL_DB.js:41
736 11.2% Function: ~Buffer.toString buffer.js:392
所有脚本类型的26.2%用于垃圾收集。这比它应该高得多。虽然它确实与Buffer.toString
花费的时间有关。如果正在创建那么多Buffers然后转换为字符串,那么当它们离开范围时都需要gc'd。
另外,我很好奇为什么LazyCompile
json.js
花费了很多时间。或者更重要的是,为什么在节点应用程序中甚至需要json.js
?
为了帮助您调整应用程序的性能,我在下面添加了一些链接,这些链接提供了有关如何操作和查找的良好说明。
漂亮的滑梯与基础:
https://mkw.st/p/gdd11-berlin-v8-performance-tuning-tricks/#1
优化技术的更高级示例:
http://floitsch.blogspot.com/2012/03/optimizing-for-v8-introduction.html
更好地使用闭合装置:
http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html
现在就为什么你无法实现相同的输出。如果你构建并使用了来自nprof
的{{3}}及其提供的master
,但它仍然不起作用,那么我将假设它与在Windows上有关。想想在GitHub上提交一个bug,看看他是否会帮助你。
答案 1 :(得分:1)
您正在使用64位版本的Node.JS来运行您的应用程序和32位版本的d8 shell来处理您的v8.log
。
使用32位版本的Node.JS和ia32作为d8 shell的构建目标,或使用64位版本的Node.JS(x64作为d8 shell构建目标)来解决您的问题。
答案 2 :(得分:0)
尝试构建具有分析支持的v8:
scons prof=on d8
确保使用与v8版本相对应的版本运行node --prof
然后tools/linux-tick-processor path/to/v8.log
会显示完整的个人资料信息。