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]
http://groups.google.com/group/v8-users
