I've been building a blogging app for the past few weeks with Node.
I'm close to be able to deploy, but I'm noticing an alarming rise in
memory usage when I'm refreshing a page over and over (once a sec) and
it never seems to release it.
Is there a way I can inspect/sample JS object allocation, etc, in
Node?
Thanks
- Alex
You can have a look at the V8 memory usage with process.memoryUsage().
Note that V8 has a really lazy garbage collector and is still
currently tuned for use in Chrome. My daemons tend to grow to about
30mb RSS before they start aggressively collect garbage.
In my simple (manual) test I was seeing a rise from ~10MB to ~27MB for
refreshing the same page over and over. I'll check later to see if I
can get it to go much higher.
- Alex
V8::IdleNotification()
To do a complete collection,
// V8::IdleNotification() returns a bool
while( V8::IdleNotification() ){}
-Louis
> --
> 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.
>
>
This came up on the serving 100k connections thread and AFAICT it's
not accessible from the JS sandbox. Is there any reason this can't be
exposed to javascript in something like sys.runGCSync()?
Would be nice to have access to it. Maybe expose it as sys.gc()? (as
it implies being synchronous there would be no need for the "Sync"
suffix and as nothing is "run", the "run" prefix is redundant).
sys.gc() +1
I tried looking at running the v8-options, but it looks like they
aren't being handled?
- Alex
On Feb 19, 9:27 am, Ryan Dahl <coldredle...@gmail.com> wrote:
http://github.com/felixge/node/commit/5874f2b3f62dd3d03f95fa938c3a77cc79a12387
Let me know if you like it.
-- fg
We talked a bit about this on IRC. Basically - I think we can make
pretty good decisions about when the process is idle - and I think
shrugging off GC control to the user will just have it be misused. So
instead I did this patch:
http://github.com/ry/node/commit/daacb81d3ab8008d0aa3437216df32394e46186e
Basically once a second a timer fires and checks if the libev is doing
anything - if it isn't, then it starts an idle watcher - which will
call V8::IdleNotification() on each tick - but only if the process
isn't doing anything. In this way there aren't long period of GC
without returning to the event loop.
This patch has the effect of dramatically compacting process memory
usage while (at least with my trivial benchmarks) not making it any
slower. Try it out and let me know what you think.
From early observations - my apps RSS now fluctuates between 9MB and
12MB on a regular basis ... awesome Ryan ;)
I'll test some more in the next day or so, but is definitely better
than it was before.
Thanks again for looking into this,
- Alex
On Feb 20, 6:42 pm, Ryan Dahl <coldredle...@gmail.com> wrote:
> 2010/2/20 Felix Geisendörfer <fe...@debuggable.com>:
>
> > Ryan: I just implemented a wrapper for V8::IdleNotification() here:
>
> >http://github.com/felixge/node/commit/5874f2b3f62dd3d03f95fa938c3a77c...
>
> > Let me know if you like it.
>
> We talked a bit about this on IRC. Basically - I think we can make
> pretty good decisions about when the process is idle - and I think
> shrugging off GC control to the user will just have it be misused. So
> instead I did this patch:
>
> http://github.com/ry/node/commit/daacb81d3ab8008d0aa3437216df32394e46...