[Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- Ruby's LEAK Fixed (Death To Mutex!)
zedshaw at zedshaw.com
Sat Aug 26 18:02:23 EDT 2006
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.lingr.com/room/3yXhqKbfPy8 -- Come get help.
More information about the Mongrel-users