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

Bob Hutchison hutch at recursive.ca
Sat Aug 26 11:20:31 EDT 2006


On Aug 26, 2006, at 10:22 AM, Bob Hutchison wrote:

>
> On Aug 26, 2006, at 5:12 AM, ara.t.howard at noaa.gov wrote:
>
>> in any case, i'd carefully examine your tests (or the rails code  
>> if that is
>> indeed what it's modeled after) to make sure that they test
>> Mutex/Sync/Thread/Ruby and not your os virtual memory system and  
>> look closely
>> at the results again - like i said, i have had issues with sync.rb.
>>
>> the point here is that it is probably the code in question and not  
>> Mutex per
>> se that was causing your process to grow in vmsize.
>>
>
>
> I ran your test on OS/X looking at VSZ and RSS. And, like you,  
> initially got Sync with no leak visible, and mutex with what looks  
> like a bad leak. However, I notice that you only called GC once. I  
> have a years old habit of always running GC at least three times  
> when I really wanted GC to run (and in Java I had a loop that ran  
> GC until it stopped freeing stuff which in some cases was eight or  
> nine times). Superstition? Apparently not. On OS X, when I run GC  
> three times neither sync nor mutex show a memory leak.
>
> Zed, just for fun, try running GC a few times in a row (like  
> GC.start; GC.start; GC.start)

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:

       GC.start
       `sync; sync; sync`
       sleep 1
       GC.start
       `sync; sync; sync`
       sleep 1
       GC.start
       `sync; sync; sync`
       sleep 1
       GC.start
       `sync; sync; sync`
       sleep 1

and this made a bigger difference. The memory usage was much more  
tightly bound.

(And yes, the three calls to sync are also on purpose... in the late  
70s through the 80s, calling sync once didn't guarantee anything, you  
had to call it a few times, three generally worked... I don't know  
the current situation because it is easy enough to type  
sync;sync;sync (well, in truth, I usually alias sync to the three  
calls))

But of course, the point is that despite appearances there is likely  
no memory leak at all on OS X, just some kind of long term cycle of  
process resource utilisation -- this is a complex situation, Ruby GC,  
process resource utilisation/optimisation, and system optimisation  
all interacting. Who knows what's actually going on.

So.

Cheers,
Bob

----
Bob Hutchison                  -- blogs at <http://www.recursive.ca/ 
hutch/>
Recursive Design Inc.          -- <http://www.recursive.ca/>
Raconteur                      -- <http://www.raconteur.info/>
xampl for Ruby                 -- <http://rubyforge.org/projects/xampl/>





More information about the Mongrel-users mailing list