On Mon, Nov 8, 2010 at 9:13 AM, Paul Burba <ptbu...@gmail.com> wrote: > On Thu, Nov 4, 2010 at 8:59 PM, Chris Tashjian <ct...@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
