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/
