On Mon, Nov 8, 2010 at 9:09 PM, Chris Tashjian <ctash_at_thepond.com> wrote:
>
> On 11/8/2010 8:54 PM, Paul Burba wrote:
>>
>> On Mon, Nov 8, 2010 at 8:28 PM, Chris Tashjian<ctash_at_thepond.com> wrote:
>>>
>>> Paul - 1 more question. What happens when you run additional blame -g
>>> commands? Does the memory usage keep growing until it runs out of memory
>>> or
>>> will it cap itself at some point? In my tests it seems like memory
>>> wasn't
>>> getting released very often. Granted, memory usage spun up so fast, I'm
>>> not
>>> positive that it really had much of a chance for that to happen.
>>
>> Chris,
>>
>> I was describing *peak* memory use. The actual working set memory
>> drops from 71 MB to 7 MB once the blame -g is processed in my example.
>> Not sure how familiar you are with APR pools, but all the pools that
>> get allocated to process the request should be destroyed (freed) when
>> the server is done. If memory use is growing slowly after each blame
>> -g, then that isn't happening and we have a separate bug. I just did
>> a little ad hoc testing and there doesn't appear to be a problem.
>> After several blame -g hits, the peak working set for my svnserve.exe
>> process always returns to around 7 MB:
>>
>> 7464 K
>> 7652 K
>> 7500 K
>> 7596 K
>>
>> If you discover anything contrary to this please let us know on the dev
>> list.
>
> I just restarted our svn server and ran blame -g against a file. No one
> else is hitting the server right now and after 5 minutes mem usage is at
> 681,208K and the peak was 681,316K. (taskmgr screenshot:
> http://img215.imageshack.us/img215/2060/svnserve.jpg)
I just checked with a trunk build prior to r1032808 it while the
memory leak manifests itself while processing the blame -g request
(peak memory at 571 MB), the peak working set returns to 9 MB once the
blame is processed. So it's not a problem on trunk.
I do see what you are describing on 1.6.x though. Working memory
peaks at 591 MB and stays there! With r1032808 memory only peaks at
91 MB, but stay there...so yup there is another bug. But it will have
to wait till tomorrow for me :-)
Paul
Received on 2010-11-09 04:02:09 CET
