subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: Branching slow 1.8.11 https
Date Sat, 28 Mar 2015 16:09:31 GMT


> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: vrijdag 27 maart 2015 22:03
> To: users@subversion.apache.org
> Subject: Branching slow 1.8.11 https
> 
> Does the following ring a bell for someone?
> 
> Recently upgraded our server (on Solaris 10 SPARC) from 1.5.4 to
> 1.8.11 (CollabNet package). Some time after that, we discovered that
> branching was very slow. I'm talking about pure server-side branching
> ('svn copy $URL/trunk $URL/branches/br1'). I'm testing with a 1.8.11
> client (tried both from same machine as the server, and from another
> machine on the LAN (100 Mbit)).
> 
> - Branching trunk (containing many directories and files): 6-8 minutes
> - Branching a subfolder of trunk: 20-30 seconds (still very slow)
> - Branching a single file is fast (< 0.5s or so).
> 
> So it seems the performance degrades depending on the depth or size of the
> tree.
> 
> Now, it gets more interesting:
> - The resulting rev file on the server is always very small (as it
> should be, it contains only a lightweight 'copy' of the trunk node).
> - Our repos is currently served via https (Apache 2.2.29).
> - Branching with file:/// urls is fast (branching trunk takes 0.6s).
> - When starting an svnserve instance serving the same repository, and
> branching with svn:// urls, it's fast as well (also 0.6s).
> - We reproduced it on a copy of the production repo.
> - Experimenting with the test copy, we found that
> $repos/dav/activities.d contains ~2000 files. When we clear that
> directory, the branching times go down by more than half (~2 minutes
> for trunk, ~10s for subdir of trunk --- i.e. still slow, but it
> definitely has an impact).
> - With a 1.7 client connecting with neon, the problem is the same.
> - During the 'svn copy', an httpd child consumes a lot of cpu (around
> half a core).
> - There is no authz configured for this repo (SVNPathAuthz off).
> - Backend is still in 1.5 format (we have not run svnadmin upgrade
> yet, a dump+load is planned in a couple of weeks).
> 
> So it seems clearly mod_dav_svn related (and not for instance related
> to the FSFS backend).
> 
> I don't think we have anything special in our httpd config:
> [[[
>    <Location /test_svn>
>       SVNInMemoryCacheSize 131072
>       SVNCacheFullTexts on
>       SVNCacheTextDeltas on
>       SSLRequireSSL
>       AuthName "TEST Subversion Repository"
>       AuthType Basic
>       AuthBasicProvider ldap
>       AuthBasicAuthoritative off
>       AuthLDAPURL "ldap://redacted:389"
>       AuthLDAPBindDN "redacted"
>       AuthLDAPBindPassword redacted
>       Require ldap-group redacted
>       DAV svn
>       SVNPath /path/to/test_repos
>       SVNPathAuthz off
>    </Location>
> ]]]
> 
> Any ideas?
> Why the cpu usage by the server, what's it doing?
> What is the dav/activities.d directory for? How come it contains so
> many files? Is it ok to purge the old files from that directory?

Httpd's mod_dav was updated in some recent version to do a full lock traversal on copies and
moves. I think we already applied some optimizations, but the real fix would be that mod_dav
shouldn't do this work (which our repos layer already does).

I'm not sure which release we applied the first set of optimizations.

	Bert
> 
> --
> Johan


Mime
View raw message