[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: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 01 Mar 2010 17:45:48 +0000

"Dr. Andreas Krüger" <andreas.krueger_at_dv-ratio.com> writes:

>> strace should show you whether or not the server is writing any
>> data, and whether or not the writes are failing.   Is it writing any
>> data at all?
> Yes.
>> Are the writes failing?
> No!

How big are the writes? In my test I saw things like:

write(4, " ) ) ( textdelta-chunk ( 2:c1 9:\0"..., 4096) = 4096 <0.074322>
write(4, "a\256\372wS|:\35\330\6\353\201\321k\27\327\360\307\325e\337\267\372\256\224\"\305\251\5\227\303Z]"..., 98422) = 98422 <2.678038>

> (I had actually mentioned that much in an earlier mail.)
> Could indeed be an openvpn bug, somehow.
> But why would subversion keep eating CPU cycles?

Somebody (you probably) needs to debug it. There are loops in
apr_socket_send but they should only apply if the writes are failing.
In one of your earlier mails you indicated there were a mixture of
read, write and poll calls so that seems to indicate that it's looping
in the Subversion code rather than the apr code. If the write system
calls don't fail then svnserve will keep on going. As I understand it
OpenVZ involves a custom kernel with it's own network drivers, perhaps
the write syscall is doing something unexpected.

Received on 2010-03-01 18:46:31 CET

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