4

我使用 --trace_gc 标志运行我的应用程序，试图找出一些性能问题。嗯，看来我已经找到了……

 1288678 ms: Mark-sweep 498.8 (549.0) -> 488.8 (548.0) MB, 4085 ms [idle notification: finalize idle round] [GC in old space requested].

牛逼！超过4秒做GC。难怪我有问题。

现在，真正的问题是：我如何才能找到正在被 GC 处理的对象，更重要的是，如何找到它们的分配位置？我已经在 nodetime 中使用过堆快照，但是我没有看到足够的信息来帮助我发现这些对象的来源。我确实看到一些提示让我相信，也许，我在某处有一个循环引用（例如，在单个用户调用几个 API 之后，我在堆快照中看到数百个“用户”属性）。

是否有任何关于如何追踪这些大型垃圾收集时间的原因的好的教程或其他好的信息？或者也许我可以以某种方式打印分配的对象，以尝试找到循环引用......？

4

1 回答 1

3

实际上没有任何工具可以做到这一点，但我可以向您保证，循环引用不是问题。

我想知道您使用的是哪个版本的 V8。

可能导致长时间停顿的一件事是非常大的对象。V8 还不太擅长增量扫描数百万个元素数组或具有数十万个对象的对象。

您可能想要关闭节点中的空闲通知或使用 --nouse-idle-notification。我不确定通知是否总是在正确的时间触发。他们可以告诉 V8，VM 无事可做，现在是进行非增量式 stop-the-world GC 的好时机。

于 2012-10-15T11:55:23.343 回答