我使用restify.js
进行了应用构建,并且检测到内存泄漏。我很幸运,因为内存泄漏“很重”,我可以很容易地重现它。它在我的本地Mac和运行应用程序的Heroku上的行为相同。作为一个证明,这是来自Heroku的Librato插件的内存使用统计数据:
当我做请求时内存使用率上升:)。不幸的是我无法跟踪内存泄漏的位置......它发生在所有路由/端点上,但是当请求需要更多时间才能完成时内存增长更快...无论如何我可以使用restify.js dtrace探测器,但只能获得中间件/处理程序延迟我正在使用以下DTRACE脚本:
#!/usr/sbin/dtrace -s
#pragma D option quiet
restify*:::route-start
{
track[arg2] = timestamp;
}
restify*:::handler-start
/track[arg3]/
{
h[arg3, copyinstr(arg2)] = timestamp;
}
restify*:::handler-done
/track[arg3] && h[arg3, copyinstr(arg2)]/
{
@[copyinstr(arg2)] = quantize((timestamp - h[arg3, copyinstr(arg2)]) / 1000000);
h[arg3, copyinstr(arg2)] = 0;
}
restify*:::route-done
/track[arg2]/
{
@[copyinstr(arg1)] = quantize((timestamp - track[arg2]) / 1000000);
track[arg2] = 0;
}
脚本的输出例如是:
handler-4
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
pre_apiVersion
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
pre_authenticate
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
pre_restifyCors
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
pre_restifyFullResponse
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
use_authorize
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
use_errors
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
use_language
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
use_modules
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
use_restifyBodyParserParseBody
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
use_restifyBodyParserReadBody
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
use_restifyQueryParser
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
use_restifyRequestLogger
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
use_validate
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7
1 | 0
pre
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 6
1 |@@@@@@ 1
2 | 0
use_restifyGzipResponse
value ------------- Distribution ------------- count
0 | 0
1 |@@@@@@ 1
2 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 6
4 | 0
handler
value ------------- Distribution ------------- count
16 | 0
32 |@@@@@@@@@@@ 2
64 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 5
128 | 0
route_module_list001
value ------------- Distribution ------------- count
16 | 0
32 |@@@@@@@@@@@ 2
64 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 5
128 | 0
我的问题是:
是否有任何选项可以编写此DTRACE脚本以不计算延迟,但计算内存使用量差异?然后我可以检查每个中间件它分配了多少内存?嗯,我猜V8中的javascript只在需要时分批分配内存,对不对?
也许您有任何其他想法如何调查此内存泄漏?我试图评论一些中间件等等,但仍然无法找到问题的根源:(。
编辑:这里是两个堆快照的比较 - 第一个是在1个请求之后完成的,第二个是在接下来的100个请求之后完成的。谁能告诉我它是什么意思?: