subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: subversion tunables
Date Wed, 14 Jul 2010 13:27:09 GMT
> -----Original Message-----
> From: Campbell Allan []
> Sent: Monday, July 12, 2010 2:09 PM
> To:
> Cc: west alto
> Subject: Re: subversion tunables
> On Thursday 08 Jul 2010, west alto wrote:
> > Hi Gurus,
> >
> > Any advise on initial tuning values for apache MinSpareServers,
> > MaxSpareServers, and StartServers, tcp tunings, ulimits, sysctl....
> >
> > I'm running svn 1.6 over apache2 pre-fork. System load goes high as
> > much as 10 during heavy usage.
> >
> > How does mod_dav_svn works on checkout? is every file =  1 thread?
> >
> > What would be your recommended MaxRequestsPerChild?
> >
> > I'm serving 91 repositories and 2 of them are at least access every 10
> > mins with 4 concurrent users.
> >
> > Thanks,
> >
> > West
> I was kind of hoping to see if anyone else replied to this. I've not
> personally tuned apache like this as I don't believe it to be a bottleneck in
> my environment. Pointing a browser at apache's /server-status page will tell
> you how many servers are actively processing requests and if you use
> something like munin then that will tell you more historical information and
> make it much easier to spot if any changes have positive effects.
> Creating threads is pretty expensive so I'd expect (but don't take this as
> correct) that mod_dav_svn uses the apache request processing thread to
> perform all operations. It might be there is an extra thread created per
> request so that there is one for comms and one for the actual subversion
> request. Definately not one per file though.
> IO wait and authentication checks seem to be the biggest problem in my
> install. To reduce the number of authentication checks I disabled per
> directory auth checks with the 'SVNPathAuthz off' directive. This made a big
> difference to checkouts, our AD authentication servers were temporarily
> blacklisting the subversion server as they were thinking it was DOS'ing them
> when I was performing a test checkout! I also have a patch for
> mod_auth_pam
> to cache some authentication details and also allow setting the name it
> provides to pam.
> The production installation is running on top of apache 2.0 which seems to
> have a minor memory leak or is over eager with caching data. To help reduce
> the impact of that there is a cron entry to gracefully restart the server 3
> times a day. This doesn't seem to be an issue on apache 2.2 though as I have
> an almost identical setup which doesn't suffer from that problem.


just my $0.02:

* Check what the server is doing most of the time: 
** is it spending its time in IO wait?
** is it spending its time in CPU?
** is it spending its time (god forbid!) paging?

I think the authentication is not a problem, that would be waiting for network, which doesn't
add to the load number. Also, Apache 2.2 caches some authentication credentials.

* Authorization* is something else - SVNPathAuthz can be very expensive, CPU-wise, so it is
a point to disable it. 
* Data compression can also be a pig, so don't use Deflate in the Apache configuration.
* IO wait can't usually be cured well by software, unless it's paging or swapping. You could
add more memory and/or faster disks.
* If the machine is swapping a bit, decrease the Maxclients setting, but be careful of setting
it not too low. We've seen long waits for clients while the machine was doing almost nothing,
the reason was a too low Maxclients setting, causing clients sitting idle hogging connections
while other clients were waiting for a connection to become available. 
* If you're running in a VMWare VM, check if there are enough CPUs available often enough
to handle the requests. (I read somewhere that ESX only gives a VM access to the processors
if it can reserve the number of CPUs assigned to the VM, which means, on a Host with 8 cores
and a bunch of VMs, a VM that has 4 cores assigned to it can only get CPU time when at leaset
4 CPUs are available and not doing anything for other VMs. Using 2 (or even just one) core
for that VM might actually result in the VM becoming faster!)
Try running with this:

Maxclients 100
Minspareservers 10
Maxrequestsperchild 500 # this can be much higher, but we reduced it when we saw a memory
leak that caused apache bloat (historically)
Startservers 10

We didn't tune tcp or other system parameters much. We are serving about 900 repositories
(most of them inactive) to about 1000 users, server is a IBM HS20 with 8 cores, 8GB of memory
and 700 GB Fibre Channel disks (SAN, 4 GBit uplink). Load on the machine usually <1.

Best regards,

Ullrich Jans

Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

View raw message