Perhaps it's just me, but I don't like cross-posting. Please post to each mailing list separately, if you don't mind. :)
On 8/25/06, Zed Shaw <[EMAIL PROTECTED]> 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 much > 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.): > > http://pastie.caboo.se/10194 > > The fix (for whatever reason) is to use Sync and put it in a block: > > http://pastie.caboo.se/10317 > > 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 > properly. > > ** This is a Ruby issue, so if you have software using Mutex or Monitor, > 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 using > this release and you still have a leak then use the memory debugging > tools mongrel has to rule out your code (see below). > > > CHANGES > > * 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 just > hit your mongrel_rails with USR1 and Mongrel will tell you. > * More extensive and accurate memory debugging. Use -B and look at the > log/mongrel_log/objects.log to get a good idea of counts of objects, > delta changes in counts, and mean+standard deviation lengths of objects > with length methods. > * Fixes a few places where sockets are closed and left in CLOSE_WAIT. > > > INSTALLING > > As per usual: > > sudo gem install mongrel --source=http://mongrel.rubyforge.org/releases/ > > 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 > code): > while sleep 1 > ps aux | grep mongrel_rails | grep -v grep | grep -v gvim | ruby > -aln > -e "puts split[4 .. 5].join(',')" > end > > 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.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 > -- Cheers, Kevin "Any sufficiently advanced technology is indistinguishable from Magic." - Arthur C. Clarke _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
