[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Great variance in times of a checkout/update.

From: William Nagel <bill_at_stagelogic.com>
Date: 2005-08-23 05:33:40 CEST

On Aug 22, 2005, at 8:27 PM, Kalin KOZHUHAROV wrote:

> Alejandro Forero Cuervo wrote:
>
>> Hi there.
>> We are experiencing a great variance in the time it takes to run a
>> svn checkout/update on a local repository. The following is a
>> list of
>> the times in seconds for 20 tests:
>> 33.752 17.996 11.997 3.998 0.993 2.053 0.942 17.998 21.997 11.997
>> 14.997 2.998 0.996 0.997 0.997 1.997 0.998 0.997 0.997 0.996
>> As you can see, the standard deviation is 9.2. I'm trying to
>> determine what could be the factors that cause some of these tests to
>> take soo long to complete.
>> While performing the tests I monitored the load of the server. It
>> never grew beyond 0.2 (indeed, it seemed to have little correlation
>> with the times).
>> I also monitored the value in /proc/sys/kernel/random/entropy_avail
>> (I'm using Linux 2.6.11) and the value remained constant during the
>> entire run. I was guessing this issues could have something to do
>> with running out of entropy but this doesn't seem to be the case. I
>> had read about this at
>> http://svn.haxx.se/dev/archive-2005-02/0619.shtml .
>> Sadly the archive seems to be broken so I can't get to the earlier
>> messages in the Archive.
>> I'm using svn, version 1.1.4 (r13838) in a Debian GNU/Linux machine.
>> Our repository is in revision 2899; du reports that it is using 62M.
>> It lives in a JFS filesystem. We use the default Subversion backend
>> (based in BDB) and access the repository though Apache (mod_dav_svn).
>> What would you recommend to determine possible causes for these
>> ocassional slowdowns?
>>
>
> Monitor the status of disk cache (`free -m`) on both the server and
> the client. I bet you'd get a hit there. Or put a copy of the whole
> repository in RAM disk (tmpfs) to test (do not commit there!).
>
> If you are hitting a CPU limit, you can prove that with 2-5 clients
> doing simultaneous checkout.
>
> Flaky network (but you said lunux)? Busy network?
>
>
>> This is strongly affecting us because some of our svn clients
>> (callers
>> to libsvn_client (though we ran the tests using the svn command-line
>> client)) are hanging for long amounts of time.
>>
>
> If you have time and resources, try to upgrade to 1.2.1 and FSFS
> backend.

You should also try testing different access methods. If you can,
first try svnserve to see if you have the same timing problems. If
that doesn't solve the problem, try direct local access (file://) to
see if it's network related.

-Bill

>
> Try to post more precise test procedure, so we can spot the
> possible misses.
>
> Kalin.
>
> --
> |[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
> +-> http://ThinRope.net/ <-+
> |[ ______________________ ]|
>
>
> ---------------------------------------------------------------------
> 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 Tue Aug 23 05:37:20 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.