Re: [nodejs] Memory management and tuning

[ben]

thanks for the info :)

On Sat, Nov 3, 2012 at 1:13 AM, Joel Rolfe <jro...@gmail.com> wrote:

Hi All,

Relatively new to node (about a month under the belt), from a java/relational stack background.  I spent today trying to understand memory management and configuration, as I found it difficult to find a single source of documentation on the various options and implications.

I've collected my research here, and would love some feedback, or any additional detail where possible.

http://code.osnap.us/wp/?p=21

Thanks!

--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Ben Noordhuis]

On Fri, Nov 2, 2012 at 6:13 PM, Joel Rolfe <jro...@gmail.com> wrote:
> Hi All,
>
> Relatively new to node (about a month under the belt), from a
> java/relational stack background. I spent today trying to understand memory
> management and configuration, as I found it difficult to find a single
> source of documentation on the various options and implications.
>
> I've collected my research here, and would love some feedback, or any
> additional detail where possible.
>
> http://code.osnap.us/wp/?p=21
>
> Thanks!

Nice article, good job.

> There had been discussion of rewriting the algorithm, but I have not been
> able to find any updated status.

The tracking issue is here: https://github.com/joyent/node/issues/3870

Admittedly, not much actual code has been written. The main issue is
that we can't introduce regressions for existing workloads.

Re: GC switches, let me know which ones you're not clear on. I can
probably fill you in.

[Joel Rolfe]

Thanks for the feedback Ben, I updated the use notifications section with a pointer to the open issue.

Re: GC switches that didn't get much love in the article - if I didn't understand why you'd want to toggle it, then I didn't say anything about it.  For example, why turn off the collect_maps option?  Or incremental_marking_steps (I'm probably not understanding that term - wouldn't incremental marking without steps be non-incremental marking?).  So basically, if there were any situations that you'd encountered where it had been useful to turn one of these off, then that's definitely something I'd want to capture.  Otherwise, I figured I'd just list them for completion's sake.  Other ones were:

--lazy_sweeping 

--flush_code
--cleanup_code_caches_at_gc

[Vyacheslav Egorov]

A lot of those flags exist solely for debugging purpose: it's
sometimes useful to switch something off and see if some issue stays
to be reproducible. This allows to quickly bisect things in a system
which has a lot of moving parts. Debugging flags are really not
intended for any other purposes and should not be used unless you have
an intimate understanding of V8.

Some flags outlived their usefulness (like --incremental_marking_steps
that was quite useful during initial development of incremental GC to
understand if there is an invariant violation between steps or the
problem is somewhere else entirely) and should be probably killed to
avoid confusion.

--collect_maps flag has a somewhat confusing name as well. Its name
implies that maps are not collected when it is turned off, however
this is not true. Maps just start to die in a different way. When
collect_maps is on then edges in map transition trees are reversed
during garbage collection and trees start dying from their leaves:
paths that do not lead to any live objects are cleared from the tree,
but roots are retained. When collect_maps is off transition trees are
just dying from their roots like a normal trees... It's likely that
less maps will die this way due to connection between initial map and
the constructor, but fully dead trees will be surely reclaimed. In
some cases application can exhibit pathological patterns of hidden
classes construction that cause performance degradation due to
frequent GCs when --collect_maps is enabled because parts in
transition tree reappear again and again after being pruned as dead.
But I would not recommend to touch this flag unless you deeply
understand how V8's hidden classes work.

Code flushing (--flush-code) tries to discard compiled code do reduce
memory consumption. Code will be recompiled if somebody needs to
execute this function again. At the moment only non-optimized code is
flushed but in the future V8 might start flushing generated optimized
code as well as it is known to cause increased memory pressure in some
pathological cases. Caches flushing (--cleanup_code_caches_at_gc)
clears inline caches and other suplemental caches used by V8 to
collect typefeedback and adapt for the application. Flushing them
reduces memory pressure (caches use small complied code stubs that can
reference other objects e.g. hidden classes that are no longer
"relevant") and ensures that feedback is not stale. Again both flags
should not be used unless you understand V8 code generation pipeline
from alpha to omega.

--
Vyacheslav Egorov

[Joel Rolfe]

Thanks for the detailed explanation Vyacheslav!  I've updated the post accordingly.