> >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://
URL.
Thanks!
Alejo.
http://azul.freaks-unidos.net/
---=( 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