Judging from the GC trace attached to your mail V8 is triggering a
last-resort GC (that is a series of seven non-incremental GCs that cause
the ~2 second pauses). These GCs are marked with "[last resort gc]" in the
trace and should only happen after two consecutive allocation attempts
failed in a row. The more interesting question is why this happens even at
a heap usage of around 400MB (i.e. it shouldn't happen). One way to figure
this out is to set a breakpoint in Heap::CollectAllAvailableGarbage and
investigating which allocation site is failing repeatedly. Is there some
reduced repro case that I could run to investigate this further?

Best regards,
Michael


On Wed, Jun 5, 2013 at 2:52 PM, Hitesh Gupta <[email protected]>wrote:

> Hi,
>    We run an XMPP server on node.js, on ec2 medium instances, which have
> around 3.8 gigs memory available. While invoking node, we pass following v8
> flags :
> -- max-old-space-size=3000 --trace-gc --trace-gc-verbose . However, when
> our heap usage is around 1 GB, we were seeing exceptionally long pauses due
> to GC (the entire problem and stack trace can be found at :
> http://stackoverflow.com/questions/16586705/configuring-v8s-memory-management-to-be-smart-for-a-node-js-process
> ).
>
>   To prevent v8's Mark-sweep from working on a large number of objects, we
> tried to use an in-memory store of Judy Array to store most of our
> long-lived data objects (https://github.com/chaitanyagupta/node-judy).
> This uses a C implementation, with v8 / node bindings, exposing a
> Javascript function to create a JudyArray, and functions to set, get and
> delete keys in it. All the memory management for the Judy Array is done by
> the C code outside of the v8 heap / GC. This enables us to have 1
> Javascript object reference (1 Judy Array), containing almost all long
> lived objects of our app after being serialized.
>
>   Now, we invoked node.js with the following options :
>   node  --max-old-space-size=1500 --trace-gc  --trace-gc-verbose
> /opt/ssc_ios_rpm/src/main.js
>
>   However, we saw even weirder behavior from v8 GC. The process's RSS
> memory never went above 500 MB, and it looked like v8 was stuck in
> GarbageCollection. The process became completely unresponsive. Attached the
> gc trace around the time of the problem (gc.txt). Please note that there is
> 1.2 GB free in Large object space, and still there are frequent Mark-sweeps
> runs of 2 seconds.
>
> Regards,
> Hitesh.
>
>
>
>
>
>  --
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to