Ooops. Now I see that I should have read the
entire thread. Sorry!
Igor Hjelmstrom Vinhas Ribeiro wrote:
> 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:33:09 2005