我使用--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].
Gadzooks！ GC超过4秒钟。难怪我遇到了问题。
现在，真正的问题是：如何找到GC的对象，更重要的是，它们被分配到哪里？我已经在nodetime中使用了堆快照，但是我没有看到足够的信息来帮助我发现这些对象的来源。我确实看到一些提示让我相信，或许我在某处有一个循环引用（例如，在单个用户进行几次API调用后，我在堆快照中看到了数百个“用户”属性）。
是否有任何好的教程或其他关于如何追踪这些大型垃圾收集时间原因的好信息？或者也许我可以以某种方式打印分配的对象，以尝试找到循环引用...？
答案 0 :(得分：3)
实际上没有任何工具，但我可以向您保证循环引用不是问题。
我想知道您使用的是哪个版本的V8。
可能导致长时间暂停的一件事是非常大的物体。 V8还不是很擅长增加扫描数百万个元素数组或具有数十万个对象的对象。
您可能希望在节点中使用--nouse-idle-notification关闭空闲通知。我不确定通知是否总是在正确的时间触发。他们可以告诉V8 VM无事可做，现在是进行非增量停止世界GC的好时机。