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

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

From: Chris Tashjian <ctash_at_thepond.com>
Date: Thu, 04 Nov 2010 20:59:24 -0400

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 02:00:08 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.