Hi,
Try to strace the svnserve process on the server to check when it forks and
what the child processes perform.
strace -t -f -p PID
I currently have a problem with generating random numbers (/dev/random takes
undefinied amount of time) which slows things very much.
That could explain the 'unpredictable' factor: maybe you don't have enough
random numbers on your system. But do a strace and it'll help understand
where the process 'hangs'.
-----Original Message-----
From: kfogel@collab.net [mailto:kfogel@collab.net]
Sent: zondag 13 februari 2005 03:36
To: Marton Fabo
Cc: users@subversion.tigris.org
Subject: Re: subversion _really_ slow
Thanks for the detailed description.
This is unexpectedly slow behavior. However, I'm not sure how to reproduce
it, since, clearly, it's not being that slow for any of the developers :-(.
The fact that it's unpredictable is also strange.
What kind of repository back end are you using -- BDB, or FSFS? If you
switch it, does that change anything?
-Karl
Marton Fabo <morton@eik.bme.hu> writes:
> I have a really unacceptable performance problem with subversion. I
> have searched the mailing lists for reports of similar problems, but I
> have not found any valuable information.
>
> We have a Linux file server running svnserve, with a repository
> holding around 60000 files. We also have a Linux development machine.
> We are using the command-line client for accessing the repository
> through svn:// URLs.
>
> On one branch, we made a change of modifying, adding and deleting of
> binary files, amounting to about 4000 items in total, and around 20 MB.
> Checking that change in took about 1.5-2 hours. Then we tried to merge
> those changes to another branch, which took almost 4 hours, but
> finally succeeded. Committing that back is still in progress, for
> almost 7 (!) hours, and it has processed around 1000 items out of the 4000
so far.
> However, it doesn't seem to have totally locked up, as every once in a
> while it advances a few files.
>
> Both the server and the client machines are mostly idle otherwise,
> they are not running other tasks that would influence performance.
> Both machines constantly run with CPU usage close to zero. The
> svnserve process uses virtually no memory, and the client uses around
> 70 MB, so I don't suspect memory trashing.
>
> Also, this behaviour seems to be quite unpredictable; during the
> course of using subversion on various test repositories of the same
> sources, sometimes it's performing acceptably (relative to what one
> may expect using such a large repository), sometimes it seemed totally
> hung up, only killable using kill -9, and leaving mysterious
> repository and working copy inconsistencies behind.
>
> Has anyone experienced any similar performance problems? Is this
> behaviour expectable with the mentioned transactions in our environment?
>
> Details:
>
> The svn binaries are version 1.1.1 (r11581) on both the server and the
> client, compiled locally.
> The client is running Linux kernel version 2.4.22-1.2115.nptl (Fedora
> Core 1) on a 3.2 GHz Intel PIV machine with 1 GB of RAM. Hard disk:
> SATA UDMA/133.
> The server is running kernel 2.4.21-27.TL (Tao Linux rel. 1) on a 1.6
> GHz PIV with 512 MB of RAM. Hard disk is ATA UDMA/100 connected.
> The two are connected on otherwise mostly idle 100 Mbit local network.
>
> thx
> mortee
>
> --
> The two basic principles of Windows system administration:
> * For minor problems, reboot
> * For major problems, reinstall
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 13 10:29:49 2005