On Fri, Nov 5, 2010 at 2:54 PM, Chris Tashjian <ctash_at_thepond.com> wrote:
> Paul - I'll see if I can get a test repo up with the error. In the
> meantime, would a copy of the svn:mergeinfo help?
No harm in sending it along, though barring something very odd I don't
hold out much hope it's going to tell us much.
> On 11/5/2010 9:59 AM, Paul Burba wrote:
>>
>> Chris,
>>
>> I recall a similar issue
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3397.
>> Unfortunately nothing conclusive came of that.
>>
>> When I wrap up what I am working on now I will take a look at this.
>> In the meantime, any chance you could try to reproduce the problem
>> using a simple test repository? No worries if you can't, but
>> obviously being able to reproduce the problem on our side would be
>> very helpful.
>>
>> Paul
>>
>> On Thu, Nov 4, 2010 at 8:59 PM, Chris Tashjian<ctash_at_thepond.com> wrote:
>>>
>>> I posted this on the users list, but I'm confident that this is a bug.
>>>
>>> Background:
>>> For a while now (off and on for over a year, but more frequently in the
>>> last
>>> 6+ months) we've been having problems with svn "crashing", yet there's no
>>> error in the log file. In talking to someone the users list it sounds
>>> like
>>> svn is actually just hanging. Clients get the following response:
>>>
>>> svn: Can't connect to host 'svn': No connection could be made
>>> because the target machine actively refused it.
>>>
>>> Our repository has 129K revisions. The format is "4 layout linear", it
>>> was
>>> created with svnadmin 1.4.x and has since had "svnadmin upgrade" run both
>>> in
>>> 1.5 and 1.6. We're currently running SlikSVN 1.6.13 (Win32), but I have
>>> previously had this problem dating back to versions of 1.5, both stock
>>> and
>>> from CollabNet. The issue now happens numerous times per day and it
>>> looks
>>> like I've discovered why....
>>>
>>>
>>> As a test I ran "svn blame -g" on a file with a bunch of revisions and
>>> watched memory usage on the server spin up to 2GB.
>>>
>>> I restarted the server and then tried "svn blame" (no -g) on the same
>>> file
>>> and it ran quickly, with no major up-tick in memory usage.
>>>
>>> I tried it again with -g and it blew up to 2GB.
>>>
>>> Next, (after restarting the server) I tried another file with more
>>> revisions. "svn blame" spins memory usage to 45MB and then eventually
>>> comes
>>> back with output.
>>>
>>> "svn blame -g" on this same file, causes svnserve to quickly (in about 45
>>> seconds) climb to 2GB of memory usage and doesn't come back (at least
>>> after
>>> 5 minutes). At that point, I just killed svnserve.exe on the server.
>>>
>
Received on 2010-11-05 20:05:20 CET