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
Received on Sun Feb 13 03:52:36 2005