[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "svn blame -g" causing svnserve to hang & mem usage to hit 2GB

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 9 Nov 2010 11:45:22 -0500

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

This is an archived mail posted to the Subversion Dev mailing list.