On Mon, Nov 8, 2010 at 9:13 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> 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.
>
> Chris,
>
> By a "bunch of revisions" what exactly do you mean? Many revisions
> which were the result of a merge? Or simply many changes made
> directly to the file (not the result of a merge)?
>
>> 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?
>
> Any luck?
Chris,
Don't sweat the replication effort too much, I think I'm on the trail
of this problem. Using a copy of the old (pre-ASF) Subversion
repository I'm seeing unexpectedly high memory use when using log -g
on a file with a "lot" of merge history:
1.6.13.client>svn blame ^/trunk/subversion/tests/cmdline/merge_tests.py
25 MB Peak Working Set Memory svnserve.exe
1.6.13.client>svn blame ^/trunk/subversion/tests/cmdline/merge_tests.py -g
291 MB Peak Working Set Memory svnserve.exe
More soon...
Paul
Received on 2010-11-08 16:35:55 CET