[Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- Ruby's LEAK Fixed (Death To Mutex!)
carl.lerche at verizon.net
Sat Aug 26 16:29:44 EDT 2006
Thanks for the hard work, when I get home I'll try running this one
on my server and see how it holds!
On Aug 25, 2006, at 11:31 PM, Zed Shaw wrote:
> Howdy Folks,
> This release is after painstaking analysis of a memory leak that was
> reported by Bradley Taylor, reduced by myself, and then fixed after
> work. You should all thank Bradley for finding the bizarre fix.
> It turns out the Ruby has a memory leak when you use pretty much any
> thread locking primitive other than Sync (Mutex, Monitor, etc.):
> The fix (for whatever reason) is to use Sync and put it in a block:
> Those two scripts are mini versions of how Mongrel manages threads so
> that I could figure out a solution or get some input. The graph is
> reported ram usage samples 1/second. As you can see the first leaking
> graph goes up and doesn't go down, the second (fixed) graph cycles
> ** This is a Ruby issue, so if you have software using Mutex or
> change to Sync now. **
> Tests of this latest pre-release show that the RAM is properly
> cycled by
> the GC and that it's actually finally solved. If you run your app
> this release and you still have a leak then use the memory debugging
> tools mongrel has to rule out your code (see below).
> * No more allow_concurrency. Until Ruby's fixed I can't let people do
> this anymore.
> * USR1 debugging. If you're wondering about how Mongrel's locking of
> Rails impacts your application, or what is causing BAD CLIENT then
> hit your mongrel_rails with USR1 and Mongrel will tell you.
> * More extensive and accurate memory debugging. Use -B and look at
> log/mongrel_log/objects.log to get a good idea of counts of objects,
> delta changes in counts, and mean+standard deviation lengths of
> with length methods.
> * Fixes a few places where sockets are closed and left in CLOSE_WAIT.
> As per usual:
> sudo gem install mongrel --source=http://mongrel.rubyforge.org/
> Initial tests show it works on 1.8.5 and is actually faster, but
> this is
> unsupported for now.
> TESTING THIS RELEASE
> If you want to test the memory leak, here's the process:
> 1) Start your application in *production* mode:
> mongrel_rails start -e production
> 2) Hit it with USR1:
> killall -USR1 mongrel_rails
> 3) Start running something that prints out the ram (here's my fish
> while sleep 1
> ps aux | grep mongrel_rails | grep -v grep | grep -v gvim | ruby
> -e "puts split[4 .. 5].join(',')"
> 4) Thrash a simple rails controller with httperf:
> httperf --server 127.0.0.1 --port 3000 --num-conns 1000 --rate 120
> --uri /testuri
> What you want to do is adjust num-conns and rate until Mongrel reports
> "X threads waiting for /testuri..."
> The bug only manifests itself when threads pile up behind the guard
> around Rails dispatching. This is also how you'd find out which Rails
> actions are too slow.
> Please report any bugs you find in this release, and a Win32 release
> will come out after I'm sure it works for everyone else.
> Zed A. Shaw
> http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
More information about the Mongrel-users