I recall a similar issue
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
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.
> 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 14:59:52 CET