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