Marton,
I would *bet* that your problem is with the random number generator
configured in your APR. See the thread "FW: svnserve processes" started
at 2005-02-11 in this list to understand why I think that and some possible
solutions. In short: recompile APR with --with-devrandom=/dev/urandom
as said by Jani Averbach..
I hope that helps,
Igor.
kfogel@collab.net wrote:
>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 Wed Feb 23 22:29:51 2005