[Mongrel] Problems with mongrel dying
wyhaines at gmail.com
Fri Nov 3 11:50:39 EST 2006
On 11/2/06, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> That's probably the best you can do until you can find out why it's leaking. My past
> experience has been to never trust Ruby's GC or any external C extensions you may be
> using. I've combed through Mongrel to insane levels to root out all possible leaks I can.
> Yet, the Sync vs. Mutex bug and recent Array patch from Eric M. shows that Ruby's GC has
> a long way to go.
I'll 1/2 second Zed's comments here. I've spent a lot of time poking
around in Ruby internals looking at memory usage. It is very easy for
someone to write a C extension that mismanages memory and causes Ruby
to leak, so always look suspiciously at an extension if you have a
leak that you can't find another cause for, unless you know with great
confidence that the extension is solid.
The Ruby GC itself is pretty simple and does what it is supposed to.
It will tend to have performance issues as the set of objects in RAM
increases, though there are strategies a person can sometimes use to
manage that, if needed.
The Sync vs Mutex thing, though, can not be laid at the foot of the
Ruby GC. The problem is with Array.c not releasing it's data in a way
that allows the Ruby GC to handle it. Refer back to the beginning of
this email about how easy it is to screw up memory management in C
Now, that said, if you are using arrays and are using push and shift
operations to manage an array like a queue (or any libraries, like
Mutex, that you are using do this), that _will_ bite you in the ass
with memory usage, because of this Array bug.
Mutex has much better performance than Sync, though, especially if
there are more than a very small number of threads, so in this
specific case I continue to use a Mutex, but have patched around the
problemlematic Array usage by creating my own copy of the Mutex class
that uses Array in a way that doesn't suffer from the bug.
More information about the Mongrel-users