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/
