Doug, are you running any custom server-side code? It is really easy introduce memory leaks if you are not careful.
Wes On Wed, Apr 6, 2011 at 6:32 PM, <[email protected]> wrote: > Sorry I didn't find the time to reproduce yet. > I run the bench tonight ! > > On Wed, 6 Apr 2011 15:04:48 -0700 (PDT), Doug <[email protected]> > wrote: > > Thanks Wes, > > > > Were you able to reproduce the problem, Anthony? > > > > Perhaps your higher memory (6GB) could solve / help the problem? > > > > Thanks, > > Doug > > > > On Apr 4, 11:09 am, Wes Garland <[email protected]> wrote: > >> On Sat, Apr 2, 2011 at 6:56 AM, Anthony Catel <[email protected]> > wrote: > >> > Hi Doug, > >> > >> > I've been running the test during 12 hours with : > >> > >> > - 4 users connected > >> > - 5 messages second (with your script running in a while(1){sleep(1) > >> > }). > >> > >> > It still working but take 0.4% on my 6GB memory (which is may be not > >> > normal). > >> > >> > Anyway, the problem may be a garbage collection issue with the > >> > javascript > >> > engine. > >> > I'll do more test this night (more user, more messages) ;) > >> > >> - ensure you are building --enable-threadsafe so that you get the > >> benefit > >> of background-thread finalization etc > >> - run a second thread in another context of the same compartment and > >> use > >> this to call JS_MaybeGC() on a timer (GPSEE uses a 2-second timer > >> IIRC) > >> - ensure all your code in libape_spidermonkey.c which can possibly > >> block > >> (any I/O calls, especially into mysql, read/write sockets, files, > >> etc) are > >> surrounded with JS_SuspendRequest()...JS_ResumeRequest() calls > >> - ensure that you do not leave active contexts "floating" -- either > >> end > >> them, destroy them, or suspend them > >> > >> If you follow these approaches, you will be able to do opportunistic > GC, > >> where the likelihood that you run your GC on one thread while another > is > >> in > >> I/O increases dramatically. So, you will run many short GC runs > >> (hopefully!) instead of rarely running GC when you have exceeded the > >> trigger > >> factor. > >> > >> IIRC, the default trigger factor is for the JS heap to have increased > to > >> 16 > >> times the size it was the last time you GC'd. You can adjust this > with > >> JS_SetGCTriggerFactor()(? -- IIRC) for JS 1.8.2, or > JS_SetGCParameter(rt, > >> JSGC_TRIGGER_FACTOR, value) for JS 1.8.5. > >> > >> Do not set the trigger below 200 (meaning 200% heap growth) because a > >> bug in > >> the way the trigger is evaluated in jsgc.cpp will cause the same > >> behaviour > >> as JS_SetGCZeal(cx, 1) and kill you on perf. > >> > >> You can see what's taking up your memory with JS_DumpHeap. This works > >> best > >> in a debug build, and IIRC, if you have good JSClass::name, and also, > if > >> you > >> name your GC roots. > >> > >> The key to keeping your heap size down is to use as little JS memory as > >> possible (obviously!), ensuring that you don't leave things like giant > >> closures lying around as props of the global variable but unused. That > >> is > >> for the JS coder. > >> > >> From the C side, we must make sure we run the garbage collector fairly > >> often. The opportunistic GC algorithm I described works because JSAPI > >> uses a > >> stop-the-world GC based on a mutex rendezvous, where the GC-initiating > >> thread waits on the mutex until all other active contexts have reported > >> that > >> they are waiting for that thread to mark/sweep the roots. This is why > we > >> call JS_MaybeGC() frequently and suspend around system calls -- the > other > >> thread waiting will mark/sweep as soon as the busy context suspends, > then > >> hopefully finishes before the system call so the GC was zero-cost. > Then > >> finalization (free) occurs in yet another thread. > >> > >> Wes > >> > >> -- > >> Wesley W. Garland > >> Director, Product Development > >> PageMail, Inc. > >> +1 613 542 2787 x 102 > > -- > You received this message because you are subscribed to the Google > Groups "APE Project" 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/ape-project?hl=en > --- > APE Project (Ajax Push Engine) > Official website : http://www.ape-project.org/ > Git Hub : http://github.com/APE-Project/ > -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 -- You received this message because you are subscribed to the Google Groups "APE Project" 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/ape-project?hl=en --- APE Project (Ajax Push Engine) Official website : http://www.ape-project.org/ Git Hub : http://github.com/APE-Project/
