On Aug 26, 2006, at 10:22 AM, Bob Hutchison wrote:
>
> On Aug 26, 2006, at 5:12 AM, [EMAIL PROTECTED] 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/>
_______________________________________________
Mongrel-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-users
