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

Re: svnserve under Linux inetd hangs, burning CPU cycles, under too low TCP-sendbuffer.

From: Dr. Andreas Krüger <andreas.krueger_at_dv-ratio.com>
Date: Thu, 25 Feb 2010 12:58:20 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, all,

in short:

* The bug is reproducible with svnserve 1.6.
* The bigger the files get, the more TCP sendbuffer svnserve seems to
need.

Minute detail:

Installing

> Package: subversion Version: 1.6.4dfsg-1~bpo50+1

and

> Package: libsvn1 Version: 1.6.4dfsg-1~bpo50+1

from Debian Lenny backports.

Creating a repository /var/local/svn-bug-repository, by doing (in that
directory, owned by the svn user, as the svn user)

> svnadmin create .

In /tmp , I generate a 10 MB junk file and check it in:

> svn co file:///var/local/svn-bug-repository ws cd ws perl -we
> 'srand(42); for($i=0;$i<10000000;$i++) {print pack
C,int(rand(255))}' > random-binary-file.bin
> svn ci -m 'Just some arbitrary content.' .

This creates the first revision in that particular repository.

I also added user and password to
/var/local/svn-bug-repository/conf/password, and started svnserve, via

> svnserve --daemon --listen-port 7777 --foreground --root
/var/local/svn-bug-repository

Thus far, all commands on the server machine, with the svn user's id.

Now, on the home machine (which still has an svn 1.5 client):

> svn co --username ... --password ... svn://server:7777/ ws

And, again, on the server, the svnserve hangs and consumes CPU.

I tried to find the limit of what would and wouldn't work.

vzctl set NNN --tcpsndbuf 600k:900k # works
vzctl set NNN --tcpsndbuf 400k:700k # hangs
vzctl set NNN --tcpsndbuf 500k:800k # works
vzctl set NNN --tcpsndbuf 450k:750k # hangs
vzctl set NNN --tcpsndbuf 475k:775k # hangs
vzctl set NNN --tcpsndbuf 485k:785k # works
vzctl set NNN --tcpsndbuf 480k:780k # hangs
vzctl set NNN --tcpsndbuf 482k:782k # hangs
vzctl set NNN --tcpsndbuf 485k:785k # works (just checking)
vzctl set NNN --tcpsndbuf 483k:783k # hangs
vzctl set NNN --tcpsndbuf 484k:784k # hangs
vzctl set NNN --tcpsndbuf 485k:785k # works (just checking one more time)

On the particular machine, the CPU load of svnserve tends to stay
around 20% as long as all goes well. This happens to be an openvpn
network connection. I see quite a bit of openvpn load. When things
turn sour, the CPU load of svnserve rises to 99% and that of openvpn
drops to invisibility. So this does not look like outgoing network
traffic.

Does the limit depend on the material?

I produce, and check in (locally on the server machine, with file:///
- - repository URL), the 10x bigger random file generated by

perl -we 'srand(42); for($i=0;$i<100000000;$i++) {print pack
C,int(rand(255))}' > even-bigger-random-binary-file.bin

Now it hangs with 485k:785k, and also with 500k:800k, and also with
600k:900k, and also with 900k:1200k, at which point I give up.

Apparently, bigger files do need bigger TCP send buffers.

Regards, and thank you for providing fine software,

Andreas
- --
Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH
andreas.krueger_at_dv-ratio.com
GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7

DV-RATIO NORDWEST GmbH
Tel: +49 (0)211 / 577 996-0
Fax: +49 (0)211 / 577 996-26
http://www.dv-ratio.com <http://www.dv-ratio.com>
Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf
Registergericht Düsseldorf HRB 34330
USt-IdNr.: DE811321837
Steuer-Nr.: 809/44031
Geschäftsführung: Günter Gerstmann
Prokura: Trudbert Vetter, Uwe Wolfram

DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuGZdoACgkQ6hmq3P1EXreM9ACfedlS7PuGukQMZCkcWK53+6OQ
nQ8AnRzNWMfOVfyZUkVLgFfAuV46+XjI
=DE9K
-----END PGP SIGNATURE-----
Received on 2010-02-25 12:58:58 CET

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

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