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

Re: time outs -- server taking >40m for PROPFIND

From: <kfogel_at_collab.net>
Date: 2005-01-23 02:22:01 CET

Someone in IRC had been seeing problems on the server side with a
similar environment. Have you looked in your Apache httpd error logs
to see if anything funny is going on? In particular I'm thinking of
"exit signal", "illegal instruction", or anything like that. Below
you quoted your access log, but not (I think) your error logs.

Also, have you tried using the 'svnserve' server, and avoiding Apache
entirely? If you try that, does it behave differently?

This is not expected behavior, no. 44010 files should not cause a 40
minute propfind.


"Earl A. Killian" <earl@killian.com> writes:
> I am running the apache2/subversion that comes with SuSE 9.2:
> subversion-perl-1.0.8-2
> subversion-devel-1.0.8-2
> subversion-viewcvs-1.0.8-2.2
> subversion-1.0.8-2
> subversion-server-1.0.8-2
> subversion-cvs2svn-1.0.8-2
> subversion-doc-1.0.8-2
> apache2-devel-2.0.50-7.2
> apache2-prefork-2.0.50-7.2
> apache2-2.0.50-7.2
> This is on a 2.8GHz EM64T Xeon CPU (so it is an SMP kernel because of
> hyperthreading) with 2GB of memory.
> I have created a repository with cvs2svn. I checked it out onto both
> the server and one client machine and then made some modifications on
> the server (like setting a lot of svn:mime-type properties). A "svn
> update" on the client times out:
> % time svn up
> svn: PROPFIND request failed on '/repos/www/trunk/...'
> svn: PROPFIND of '/repos/www/trunk/...': timed out waiting for server (https://...)
> 0.417u 0.048s 40:00.70 0.0% 0text 0data 0stack 0maxrss 0iw 0ow 0pf 0swap 4717re
> Exit 1
> (I edited the pathnames above for privacy.)
> I have been increasing the value of http-timeout (now 2400) but it
> makes no difference, as you can see above.
> Another attempt after I had restarted apache2 gave (again after the
> 40m http-timeout):
> % svn up
> svn: REPORT request failed on '/repos/www/!svn/vcc/default'
> svn: REPORT of '/repos/www/!svn/vcc/default': timed out waiting for server (https://svn.killian.com)
> Exit 1
> Doing "svn up" of just a few files works. The above "svn up" was done
> in a working directory with 7588 files.
> I have done a svnadmin verify on the repository.
> There is very little in the httpd logs, just:
> [21/Jan/2005:19:02:30 -0800] TLSv1 DHE-RSA-AES256-SHA "PROPFIND /repos/www/trunk/... HTTP/1.1" 1311
> [21/Jan/2005:19:02:30 -0800] TLSv1 DHE-RSA-AES256-SHA "PROPFIND /repos/www/trunk/... HTTP/1.1" 750
> for the most recent attempt.
> What can be done to make subversion work? Further increasing the
> http-timeout is silly. No one should have to wait even a fraction of
> 40 minutes to do an update, especially when only mime-types have
> changed. Are exponential algorithms being used or something?
> At the 40m of elapsed time the http2 process (running on an otherwise
> unloaded machine) had used 5:30 of CPU time:
> 23206 wwwrun 15 0 171m 30m 152m D 12.3 1.5 5:30.10 httpd2-prefork
> It kept on running after the client gave up.
> The repository is large:
> % du /b/srv/repos/www/
> 3546784 /b/srv/repos/www/db
> 4 /b/srv/repos/www/dav
> 4 /b/srv/repos/www/conf
> 20 /b/srv/repos/www/hooks
> 8 /b/srv/repos/www/locks
> 3546828 /b/srv/repos/www/
> The working directory contains 44010 files in 1020 directories.
> Is this project (which has many .jpg files -- photos of a construction
> project) just too large for subversion? Should I give up and revert
> to cvs?
> -Earl
> ---------------------------------------------------------------------
> 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 Jan 23 02:33:21 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.