On Sat, 2006-08-26 at 11:20 -0400, Bob Hutchison wrote: > On Aug 26, 2006, at 10:22 AM, Bob Hutchison wrote: >
> Well I tried your test on OS X. The Sync had no problem, the mutex > showed the memory growth (though it eventually (fifth iteration I > think) cleaned itself up). I modified your test to create exactly > 1000 threads and call GC three times at the end, things were better, > i.e. it released its memory more quickly than without, but still not > good. I ended up with: Thanks Bob, but I've gotta say this one more time, this test is not about 1000 threads. The test is about how *Mongrel* processes threads, a specific bug when many threads are put into a ThreadGroup and wait behind a Mutex, and how to stop that from leaking. If you change the way the test is written so that it creates exactly 1000 threads, then this isn't simulating Mongrel. You're most likely using additional synchronization primitives not used in Mongrel so your test is wrong. I mean, Mongrel doesn't wait for 1000 threads, it just cranks on them and sometimes it's too slow so you build a log jam. In this situation, we were seeing memory leaks. Other people also report the memory leaks and even reported this fixed it in other systems unrelated to Mongrel. Yes, you can write something else to not have memory leaks, but then you're not testing our leaking situation. The point is that the script with Mutex leaks, the one with Sync doesn't. The number 1000 was just a number picked at random so that I knew when to stop simulating requests and start calling GC. And, if you notice there's a loop that calls GC.start about 3-4 times. There's no way I'm going to put into Mongrel's loop three calls to GC. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
