Vyacheslav, just to clarify, must I replace the entire content of CollectAllAvailableGarbage with:
CollectGarbage(OLD_POINTER_SPACE, MARK_COMPACTOR, gc_reason, NULL) or CollectGarbage(OLD_POINTER_SPACE, gc_reason) ? Must I remove everything including things like: new_space_.Shrink(); UncommitFromSpace(); Shrink(); Your help is much appreciated. On Monday, November 5, 2012 4:43:30 PM UTC+2, Vyacheslav Egorov wrote: > > Hello Joran, > > "last resort gc" means that there was an allocation failure that a > normal GC could "resolve". Basically you are in a kinda OOM situation. > I am kinda curious what kind of allocation it is. Probably it is some > very big object. It can be that allocation attempt does not correctly > fall into allocating from LO space. > > One thing though is that last resort GC can be much more lightweight > for node.js application that it is currently. I doubt 7 GC in a row > are very helpful. As a workaround you can go into > Heap::CollectAllAvailableGarbage and replace everything inside with > > CollectGarbage(OLD_POINTER_SPACE, gc_reason); > > This should get rid of 7 repetitive GCs. I think for an application > like yours it makes perfect sense to set internal GC limits very high > and let incremental GC crunch things instead of falling back to > non-incremental marking. But there are currently no way to configure > GC like that. > Vyacheslav Egorov > > > On Mon, Nov 5, 2012 at 12:50 AM, Joran Dirk Greef > <[email protected]<javascript:>> > wrote: > > Max-old-space-size is measured in MB not KB as you suggest. > > > > Further, max-new-space-size makes no difference to the GC trace given > above, > > whether it's passed as flag or not, big or small. > > > > On Monday, November 5, 2012 10:21:11 AM UTC+2, Yang Guo wrote: > >> > >> The short answer is: don't mess with GC settings if you don't know what > >> you are doing. > >> > >> The long answer is: new space is the part of the heap where > short-living > >> objects are allocated. The GC scans new space on every collection and > >> promotes long-living objects into the old space. You are setting the > new > >> space to ~19GB, which takes a while to scan. Furthermore, you are > setting > >> the old space to only 19MB, limiting the part of the heap where > long-living > >> objects are being moved to, hence the last resort GC. What you probably > want > >> is to specify a large old space size, but leave the new space size at > >> default. > >> > >> Yang > >> > >> On Sunday, November 4, 2012 4:19:11 PM UTC+1, Joran Dirk Greef wrote: > >>> > >>> I am running Node v0.8.14 with --nouse_idle_notification --expose_gc > >>> --max_old_space_size=19000 --max_new_space_size=19000000. > >>> > >>> I have a large object used as part of a BitCask style store, keeping a > >>> few million entries. > >>> > >>> Calling gc() manually takes a 3 seconds which is fine as I call it > every > >>> 2 minutes. > >>> > >>> The machine has 32GB of RAM and all of this is available to the > process, > >>> there is nothing else running. > >>> > >>> The process sits at around 1.9GB of RAM. > >>> > >>> I have found an interesting test case where async reading a 1mb file > in > >>> Node takes longer and longer depending on how many entries are in the > large > >>> object discussed above: > >>> > >>> Node.fs.readFile('test', 'binary', End.timer()) > >>> 347745 ms: Scavenge 1617.4 (1660.4) -> 1611.1 (1660.4) MB, 0 ms > >>> [allocation failure]. > >>> 350900 ms: Mark-sweep 1611.5 (1660.4) -> 1512.2 (1633.4) MB, 3153 ms > >>> [last resort gc]. > >>> 354072 ms: Mark-sweep 1512.2 (1633.4) -> 1512.0 (1592.4) MB, 3171 ms > >>> [last resort gc]. > >>> 357247 ms: Mark-sweep 1512.0 (1592.4) -> 1512.0 (1568.4) MB, 3175 ms > >>> [last resort gc]. > >>> 360426 ms: Mark-sweep 1512.0 (1568.4) -> 1512.0 (1567.4) MB, 3178 ms > >>> [last resort gc]. > >>> 363620 ms: Mark-sweep 1512.0 (1567.4) -> 1512.0 (1567.4) MB, 3193 ms > >>> [last resort gc]. > >>> 366802 ms: Mark-sweep 1512.0 (1567.4) -> 1511.6 (1567.4) MB, 3182 ms > >>> [last resort gc]. > >>> 369967 ms: Mark-sweep 1511.6 (1567.4) -> 1511.6 (1567.4) MB, 3164 ms > >>> [last resort gc]. > >>> 2012-11-04T14:59:30.700Z INFO 22230ms > >>> > >>> Reading the 1mb file before the large object is created is fast, the > >>> bigger the object becomes the slower the file is to read. > >>> > >>> Why is last resort gc being called if gc is exposed and if the machine > >>> has more than enough RAM? > >>> > >>> What was interesting was that this behabiour does not happen for V8 > >>> 3.6.6.25 and earlier. > >>> > >>> The reason I can't use 3.6.6.25 however is that the heap is limited to > >>> 1.9GB and I need more head room than that. > >>> > >>> Is there anyway I can disable the last resort GC? > > > > -- > > v8-users mailing list > > [email protected] <javascript:> > > http://groups.google.com/group/v8-users > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
