--trace-gc-verbose should be used together with --trace-gc.
When enabled should produce something like:
1087 ms: Scavenge 2.6 (20.4) -> 1.6 (20.4) MB, 0 ms [allocation failure].
Memory allocator, used: 21409792, available: 746147840
New space, used: 0, available: 1048576
Old pointers, used: 1277824, available: 0, waste: 0
Old data space, used: 1173980, available: 38308, waste: 0
Code space, used: 1396000, available: 736, waste: 0
Map space, used: 131072, available: 0, waste: 0
Cell space, used: 98304, available: 0, waste: 0
Large object space, used: 0, available: 745066368
I need to see this kind of fine grained statistics to make a guess.
You can also try to update V8 inside node from 3.11.10.12 to 3.11.10.13 so that
CL improving memory usage
(https://chromiumcodereview.appspot.com/10699051) is included.
--
Vyacheslav Egorov
On Thu, Jul 5, 2012 at 9:40 AM, chusi <[email protected]> wrote:
>
> the --trace-gc-verbose parameter didn't print anything (at least not in the
> minute i waited) and until i reach the 50 MB (monitoring using --trace-gc)
> at least some hours have to pass by. I will try it later.
>
> here's a pic of running the same code once with node v0.6.17 (chris lea's
> packet) and node v.0.8.1 (my own compiled version).
>
> http://troll.ws/i/nJQJFr.png
>
> before I updated to the new node version i was fighting against some memory
> leaks in my code, but was able to fix them. when i switched to v.0.8.1 I was
> worried that they seemed to be back (when i saw the graph). besides the "red
> line" that goes crazy, i guess the rest can be explained by the new more
> lazy garbage collection approach.
>
> btw, the app is almost idle. the different modules shown in the graph just
> communicate from time to time with each other and only exchange tiny bits of
> data.
>
>
>
> On Wednesday, July 4, 2012 5:33:34 PM UTC+2, Vyacheslav Egorov wrote:
>>
>> If you run you app with --trace-gc what does it print (I am interested
>> in GC statistics for the time when app reaches 50MB)?
>>
>> I am also curious in --trace-gc-verbose output to see how memory is
>> distributed between different spaces in V8?
>>
>> It might be that the fragmentation in the heap became higher due to
>> lazyness of the new collector (it is tunes for interactive performance
>> so it tries to do things in small increments).
>>
>> Also I am not sure what the current situation with idle notifications
>> in node is but they are very important for the new collector to
>> perform bigger steps when app is idle.
>>
>> Additionally there were some changes recently that increased
>> aggressiveness with which new collector sweeps and compacts things out
>> from almost empty pages. You might be being bitten by this issues.
>>
>> --
>> Vyacheslav Egorov
>>
>>
>> On Wed, Jul 4, 2012 at 12:42 PM, Ben Noordhuis <[email protected]> wrote:
>> > On Wed, Jul 4, 2012 at 11:39 AM, chusi wrote:
>> >> On Tuesday, July 3, 2012 7:53:26 PM UTC+2, Ben Noordhuis wrote:
>> >>> Sanity check - what do `file /path/to/old/node` and `file
>> >>> /path/to/new/node` print?
>> >>
>> >> old 0.6.17:
>> >> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked
>> >> (uses shared libs), for GNU/Linux 2.6.15, stripped
>> >>
>> >> new 0.8.1
>> >> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked
>> >> (uses shared libs), for GNU/Linux 2.6.15, stripped
>> >>
>> >> node is installed using chis-lea's package as described here:
>> >>
>> >> https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager
>> >
>> > Output from `file` looks good. If one binary was built for ia32 and
>> > the other for x64, you'd expect to see different memory profiles, but
>> > that's not the case here.
>> >
>> > I don't know if Chris lands patches on top in a way that changes
>> > memory consumption. Do you see the same behavior with a (tarball, git)
>> > source build?
>> >
>> > One thing to note is that V8 has a new and improved (but also more
>> > lazy) garbage collector. Run your app with --expose-gc and call gc()
>> > from time to time if memory pressure is a real issue - but I would
>> > generally advise against that.
>> >
>> > --
>> > Job Board: http://jobs.nodejs.org/
>> > Posting guidelines:
>> > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> > You received this message because you are subscribed to the Google
>> > Groups "nodejs" group.
>> > To post to this group, send email to [email protected]
>> > To unsubscribe from this group, send email to
>> > [email protected]
>> > For more options, visit this group at
>> > http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
