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

Re: Great variance in times of a checkout/update.

From: Alejandro Forero Cuervo <azul_at_freaks-unidos.net>
Date: 2005-08-24 20:03:59 CEST

> >Monitor the status of disk cache (`free -m`) on both the server and
> >the client. I bet you'd get a hit there. Or put a copy of the whole
> >repository in RAM disk (tmpfs) to test (do not commit there!).

Hmm, disk seems not to be the cause of the slowdowns. I just tested
using a tmpfs mount and it was pretty slow. Here is what I did, in
case you want to see the details:

Move my repos out of the way:

> # cd /home/alejo
> # mv svn svn-real

Mount the location of the repos in RAM:

> # mount -t tmpfs -o size=200m tmpfs svn

Copy the repos:

> # cp -Ra svn-real/flisol/ svn/flisol

Confirm everything looks as expected:
> # mount
> ...
> tmpfs on /home/alejo/svn type tmpfs (rw,size=200m)

Make a svn checkout in the RAM fs:

> # mkdir svn/out
> # cd svn/out
> # uptime && cat /proc/sys/kernel/random/entropy_avail && time svn checkout http://localhost/svn/flisol && uptime && cat /proc/sys/kernel/random/entropy_avail
> 14:30:52 up 23 days, 3:37, 5 users, load average: 0.22, 0.12, 0.05
> 3872

When this had taken over 5 minutes, I aborted it.

So, as I said, I don't think disk issues could be the cause for the
spurious bottlenecks. Other services seem not to suffer them. :/

> >Flaky network (but you said lunux)? Busy network?

As you see in the example above, I'm doing this locally (server and
client are the same maachine). I should have mentioned this
explicitly in my previous message.

> You should also try testing different access methods. If you can,
> first try svnserve to see if you have the same timing problems. If
> that doesn't solve the problem, try direct local access (file://) to
> see if it's network related.

I'll try that.

Interestingly, I tried running tests on this machine yesterday and
they all took very little to run. But today I got pretty much the
same strange behaviour that I reported.

I just noticed that restarting Apache and running svnadmin recover on
the repos seems to improve things very much (though I'm not sure just
restarting Apache would have sufficed). I just ran 60 updates after
doing this and all of them took less than 3 seconds. Perhaps Apache
is acquiring some locks on the repository and there's a limit to the
number of concurrent locks allowed? Currently we have a website where
all accesses require doing an svn up (edit.installfest.net) that I
disable while running these tests (but it isn't accessed that much
(most people access installfest.net, which has the same contents as
static files)).

I'll keep retrying periodically until I see performance degrade. Then
I'll try your suggestion of timing svnserve or accesses with a file://



---=( Comunidad de Usuarios de Software Libre en Colombia )=---
---=( http://bachue.com/colibri )=--=( colibri_at_bachue.com )=---

Received on Wed Aug 24 19:59:22 2005

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

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