[Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- Ruby's LEAK Fixed (Death To Mutex!)

Luis Lavena luislavena at gmail.com
Sat Aug 26 19:26:01 EDT 2006


I have done some testings of the code on Win32 with ruby 1.8.4, please
check the included pictures [1].

I have compared both test scripts, using Process Explorer to monitor
their memory use and CPU use.

So far, Win32 behave way different than *nix in this matter. If you
see the pngs, using mutex actually releases memory (GC) and finish
faster than sync.

Sync, on the contrary, never released memory (like GC wasn't called at
all) and took longer to finish (I stopped it because took more than 6
minutes).

I could conclude that ruby implementations are too different to
compare between installations and platforms...

A solution for the memory leaking should be tested on any platform
before taking final decisions.

On 8/26/06, Kirk Haines <wyhaines at gmail.com> wrote:
[snip]
>
> On variations that launch exactly 1000 threads (which is easily done
> without using any other locking primitives), the difference boils down
> to how fast objects can be created and how long the GC has to clean
> them up.  Change the test() method to do something that creates some
> strings and other objects, and it becomes clear very quickly that if
> there is a burst of activity, a bunch of threads locking with a Mutex
> outrun the GC's ability to clean it up.  Memory consumption rises.

Please provide a sample script (pastie?) and I will test it too on Win32.

> This also seems consistent on my tests so far comparing 1.8.4 to
> 1.8.5, which you mentioned seemed to exhibit worse RAM use
> characteristics.  I still need to dig into the differences in the GC
> subsystem code between the two versions, but the experimental evidence
> that I have suggests that in 1.8.5 it is taking longer to get around
> to cleaning up objects.  It seems to be faster when it does, as my
> overall throughput is about 10% faster on 1.8.5, but I don't think I'm
> liking the tradeoff that I am seeing with memory consumption when it
> is pounded with objects.  Something looks wrong, there, but it's not
> related to Mutex.

I agree with you that something is wrong, not with mutex, but with ruby itself.

People will start yelling me about this, but is true.

Not just with mutex, but with threads (oh lovely select()) and
sockets. On every platform exceptions are thrown differently or in
some cases, not raised at all!

We must investigate this to find a workaround that works "almost good"
on every platform.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

[1] Cannot add pngs to this mail (40K limit) so uploaded them to my server:
http://www.mmediasys.com/mongrel/mutex.png
http://www.mmediasys.com/mongrel/sync-1.png
http://www.mmediasys.com/mongrel/sync-2.png


More information about the Mongrel-users mailing list