On Mon, Nov 8, 2010 at 10:01 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> 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 :-)
Hi Chris,
I think we've reached the end of the road with this (in a good way :-)
The problem with svnserve not freeing memory was fixed on
^/subversion/branches/performance by Stefan Fuhrmann a few months
back:
http://svn.apache.org/viewvc?view=revision&revision=982355
And cherry-picked over to trunk a few weeks ago:
http://svn.apache.org/viewvc?view=revision&revision=1022675
With an unmodified 1.6.x_at_1033049 my blame -g example results in:
svnserve.exe starting working set memory 6,456 K
svnserve.exe peak working set memory 617,696 K
svnserve.exe ending working set memory 617,628 K
With r1022675 merged to 1.6.x my blame -g example results in:
svnserve.exe starting working set memory 6,572 K
svnserve.exe peak working set memory 616,996 K
svnserve.exe ending working set memory 11,364K
With r1022675 and r1032808 both merged to 1.6.x:
svnserve.exe starting working set memory 6,500 K
svnserve.exe peak working set memory 92,572 K
svnserve.exe ending working set memory 8,780 K
I nominated r1022675 for backport to 1.6.14. Now we just have to
await review/votes/vetoes.
Paul
Received on 2010-11-09 17:45:59 CET
