"BRUGGEMAN Jens (JBRG)" <Jens.Bruggeman@seco-m.be> writes:
> 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'.
Oh, yeah, this happened to me too!
I recompiled APR with "--with-devrandom=/dev/urandom", then recompiled
my Subversion client against that APR, and the problem went away.
(One thing: I had thought the client only needed random numbers when
operating against an http:// repository. But perhaps that is wrong.)
-Karl
> -----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 Mon Feb 14 06:15:09 2005