Hi Michael,
Sorry, but we don't have a reduced reproducible case, as this happens
when our large source-code+deps serve lot of traffic. But this happens
everytime we deploy our JudyArray using code in production, and start
serving traffic. (We face similar problems around 1 GB heap usage without
using JudyArrays, where though having sufficient memory, we keep seeing
last resort GCs).
Could you perhaps give me some patch of v8 or heap.cc that I can deploy
on production, run for some time, and it would emit logs that would help us
investigate this further ? Let us know what you think.
Regards,
Hitesh.
On Wednesday, June 5, 2013 8:52:20 PM UTC+5:30, Michael Starzinger wrote:
>
> 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]<javascript:>
> > 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] <javascript:>
>> 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] <javascript:>.
>> 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.
