Node v8 Garbage Collector :: how to debug long mark-sweep markups?

I ran an application with the --trace_gc flag to try and find some performance issues. Well, it looks like I found it ...

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! More than 4 seconds to make a GC. No wonder I have problems.

Now, the real question is: how can I find which GC'd objects, and more importantly, where were they allocated? I have already used heap snapshots in nodetime, but I do not see enough information to help me find out where these objects come from. I see some hints that make me believe it is possible that I have a circular link somewhere (for example, I see hundreds of "user" properties in a heap snapshot after just one API call from one user).

Are there any good tutorials or other good information on how to trace the cause of these large garbage collections? Or maybe I could somehow print the selected objects to try to find a circular reference ...?

+4
Oct. 14 '12 at 10:12
source share
1 answer

In fact, there are no tools for this, but I can assure you that circular references are not a problem.

I wonder what version of V8 you are using.

One thing that can cause long pauses is very large objects. V8 is still not very good at incrementing the scan of multimillion-dollar arrays of elements or objects with hundreds of thousands of objects.

You can turn off downtime notifications in node or with -nouse-idle-notification. I'm not sure that notifications always shoot at the right time. They can tell V8 that the virtual machine has nothing in common, and now is the right time to execute a non-incremental GC-stop-world.

+3
Oct 15 '12 at 11:55
source share



All Articles