You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Thorsten Schmitt-Rink <sc...@gmail.com> on 2008/04/28 17:13:26 UTC
performance issue concerning externals
Hi,
I' running svnserve v1.4.6 (r28521) standalone on debian-etch 4.1.1-21
32bit.
The apr to uses urandom instead of random.
The repositories on my server are configured to use the same user and group
file.
I checkout repositories using the svn protocol. svn co
svn://myserver.ip:port/repo
Everything runs fine as long as I don't have externals in my repositories.
When I add externals to a repository, checkouts and updates etc. become
really slow.
And I mean really slow. :(
I've searched the net and the subversion site, but couldn't find anyone with
a simular problem.
Does anyone have an idea what could be leading to this behaviour?
Thank you
Thorsten
Re: performance issue concerning externals
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Apr 29, 2008, at 9:55 AM, Karl Fogel wrote:
> Thorsten Schmitt-Rink writes:
>
>> Well I'll just have to trust the users. I guess people are ok
>> 'round here.
>> Eriks opinion to the prob is that I'm experiencing the known /dev/
>> random
>> problem.
>> I've reinstalled my apr to be 100% sure that it is set up
>> correctly and
>> suprise, it still hangs on the externals. :(
>
> I tried to reproduce, but the externals are set with hardcoded
> repository URLs using svn://, and I don't have a login on that
> repository server:
>
> $ svn checkout file://`pwd`/repos/ local-wc
> A local-wc/trunk
> A local-wc/trunk/site
> A local-wc/trunk/flash
> A local-wc/trunk/flash/apps
> A local-wc/trunk/flash/apps/FamuzWebsite
> A local-wc/trunk/flash/apps/FamuzWebsite/fla
> A local-wc/trunk/flash/apps/FamuzWebsite/fla/tests
> A local-wc/trunk/flash/apps/FamuzWebsite/fla/skins
> A local-wc/trunk/flash/apps/FamuzWebsite/fla/skins/default
> A local-wc/trunk/flash/apps/FamuzWebsite/fla/sharedlib.fla
> [...]
> A local-wc/trunk/flash/libs
> A local-wc/branches
> A local-wc/tags
>
> Fetching external item into 'local-wc/trunk/flash/tools'
> Authentication realm: <svn://78.46.66.102:10023>
> as3_flapp_tools_repo
> Password for 'kfogel':
> Authentication realm: <svn://78.46.66.102:10023>
> as3_flapp_tools_repo
> Username: C-c C-c
>
> subversion/svn/main.c:1021: (apr_err=200015)
> svn: Caught signal
> $
>
> I didn't bother setting up svn:// or http:// for my local checkout,
> since I'd obviously run into the same problem.
>
> Can you try the following? Upgrade your client to the latest trunk
> code
> (or to 1.5.0-rc4), and redo your svn:externals properties as relative
> URLs, as described in:
>
> http://subversion.tigris.org/svn_1.5_releasenotes.html#externals-
> relative-urls
>
> Be sure to read the section immediately before that too, since the
> externals syntax is different in 1.5 (the old syntax will still work,
> but it is deprecated and cannot be used for relative URLs).
>
> If you still have the problem, post that repository, and anyone should
> be able to run the same reproduction recipe, since the svn:externals
> URLs will be relative to whatever repository we're using.
Presumably you could munge the svn:externals URLs in the existing
dumpfile using svndumptool's transform-prop command?
http://svn.borg.ch/svndumptool/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: performance issue concerning externals
Posted by Karl Fogel <kf...@red-bean.com>.
"Thorsten Schmitt-Rink" <sc...@gmail.com> writes:
> Well I'll just have to trust the users. I guess people are ok 'round here.
> Eriks opinion to the prob is that I'm experiencing the known /dev/random
> problem.
> I've reinstalled my apr to be 100% sure that it is set up correctly and
> suprise, it still hangs on the externals. :(
I tried to reproduce, but the externals are set with hardcoded
repository URLs using svn://, and I don't have a login on that
repository server:
$ svn checkout file://`pwd`/repos/ local-wc
A local-wc/trunk
A local-wc/trunk/site
A local-wc/trunk/flash
A local-wc/trunk/flash/apps
A local-wc/trunk/flash/apps/FamuzWebsite
A local-wc/trunk/flash/apps/FamuzWebsite/fla
A local-wc/trunk/flash/apps/FamuzWebsite/fla/tests
A local-wc/trunk/flash/apps/FamuzWebsite/fla/skins
A local-wc/trunk/flash/apps/FamuzWebsite/fla/skins/default
A local-wc/trunk/flash/apps/FamuzWebsite/fla/sharedlib.fla
[...]
A local-wc/trunk/flash/libs
A local-wc/branches
A local-wc/tags
Fetching external item into 'local-wc/trunk/flash/tools'
Authentication realm: <svn://78.46.66.102:10023> as3_flapp_tools_repo
Password for 'kfogel':
Authentication realm: <svn://78.46.66.102:10023> as3_flapp_tools_repo
Username: C-c C-c
subversion/svn/main.c:1021: (apr_err=200015)
svn: Caught signal
$
I didn't bother setting up svn:// or http:// for my local checkout,
since I'd obviously run into the same problem.
Can you try the following? Upgrade your client to the latest trunk code
(or to 1.5.0-rc4), and redo your svn:externals properties as relative
URLs, as described in:
http://subversion.tigris.org/svn_1.5_releasenotes.html#externals-relative-urls
Be sure to read the section immediately before that too, since the
externals syntax is different in 1.5 (the old syntax will still work,
but it is deprecated and cannot be used for relative URLs).
If you still have the problem, post that repository, and anyone should
be able to run the same reproduction recipe, since the svn:externals
URLs will be relative to whatever repository we're using.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: performance issue concerning externals
Posted by Thorsten Schmitt-Rink <sc...@gmail.com>.
Nice one :(
Well I'll just have to trust the users. I guess people are ok 'round here.
Eriks opinion to the prob is that I'm experiencing the known /dev/random
problem.
I've reinstalled my apr to be 100% sure that it is set up correctly and
suprise,
it still hangs on the externals. :(
2008/4/29 Karl Fogel <kf...@red-bean.com>:
> "Thorsten Schmitt-Rink" <sc...@gmail.com> writes:
> > I dumped the repository.
> > I'm adding the dump as an attachement, because posting in place too
> public,
> > gives me a small headache, since the sources contained are kinda
> confedential.
>
> Um, I think you just posted it to a public mailing list, though...
>
Re: performance issue concerning externals
Posted by Karl Fogel <kf...@red-bean.com>.
"Thorsten Schmitt-Rink" <sc...@gmail.com> writes:
> I dumped the repository.
> I'm adding the dump as an attachement, because posting in place too public,
> gives me a small headache, since the sources contained are kinda confedential.
Um, I think you just posted it to a public mailing list, though...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: performance issue concerning externals
Posted by Thorsten Schmitt-Rink <sc...@gmail.com>.
I dumped the repository.
I'm adding the dump as an attachement, because posting in place too public,
gives me a small headache, since the sources contained are kinda
confedential.
2008/4/28 Karl Fogel <kf...@red-bean.com>:
> "Thorsten Schmitt-Rink" <sc...@gmail.com> writes:
> > I'm no pro, so I don't know how the correct debug approach would be for
> this
> > case.
> > I did a strace on the proccess and saw that it started hanging when
> waiting for
> > input from the stream.
> > Here's the corresponding part of the strace output:
> >
> > socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
> > connect(4, {sa_family=AF_INET, sin_port=htons(10023),
> sin_addr=inet_addr("
> > 78.46.66.102")}, 16) = 0
> > read(4, "( success ( 1 2 ( ANONYMOUS ) ( "..., 4096) = 76
> > write(4, "( 2 ( edit-pipeline svndiff1 abs"..., 100) = 100
> > read(4, "( success ( ( CRAM-MD5 ) 14:as3s"..., 4096) = 47
> > write(4, "( CRAM-MD5 ( ) ) ", 17) = 17
> > read(4,
> >
> > Then nothing would happen for a while.
> > After the usual 5 - 8 minutes, it continued.
>
> Ugh.
>
> Can you post the repository? That is, 'svnadmin dump' the repository,
> put that somewhere, and offer it up for others to try to reproduce this?
> If we could narrow this down to knowing that the problem is unique to
> your server, that would help.
>
Re: performance issue concerning externals
Posted by Erik Huelsmann <eh...@gmail.com>.
On Mon, Apr 28, 2008 at 11:36 PM, Thorsten Schmitt-Rink
<sc...@gmail.com> wrote:
> Just before the I received the mail, I deleted my apr and did a new clean
> install on svnserve,
> including the ./configure --with-dev-random=/dev/urandom for apr.
> Still the same issue.
> I did the configure just in case, since I found that suggestion in the
> subversion.tigris.org FAQ a couple of days ago.
> It would be intresting to know, what actually happens when the prossess
> hangs on:
>
>
> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
> connect(4, {sa_family=AF_INET, sin_port=htons(10023),
> sin_addr=inet_addr("78.46.66.102")}, 16) = 0
> read(4, "( success ( 1 2 ( ANONYMOUS ) ( "..., 4096) = 76
> write(4, "( 2 ( edit-pipeline svndiff1 abs"..., 100) = 100
> read(4, "( success ( ( CRAM-MD5 ) 14:as3s"..., 4096) = 47
> write(4, "( CRAM-MD5 ( ) ) ", 17) = 17
> read(4,
>
> Is that one of the places where random numbers are needed?
Yes, absolutely. That's why I kept on harping on the /dev/random vs
/dev/urandom issue.
Bye,
Erik.
> 2008/4/28 Karl Fogel <kf...@red-bean.com>:
> >
> >
> >
> >
> > "Erik Huelsmann" <eh...@gmail.com> writes:
> > > Karl, may I suggest this is not related to the repository, but rather
> > > to the server running out of entropy?
> > >
> > > Search the list archives for solutions to the problem of servers
> > > drawing from /dev/random and blocking because of it.
> >
> > Ah, yes. For some reason that seems to have come up a lot in the last
> > few days -- maybe the solar system is running out of entropy or
> > something.
> >
> > Thorsten Schmitt-Rink, can you rebuild APR to use /dev/urandom instead
> > of /dev/random, and then rebuild Subversion against the new APR? Uh,
> > I'm not sure whether both client and server need this done (and in fact,
> > the answer may be different for http:// vs svn://), so do both to be
> > safe. I just can't remember all the circumstances in which we need
> > random numbers.
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: performance issue concerning externals
Posted by Thorsten Schmitt-Rink <sc...@gmail.com>.
Just before the I received the mail, I deleted my apr and did a new clean
install on svnserve,
including the ./configure --with-dev-random=/dev/urandom for apr.
Still the same issue.
I did the configure just in case, since I found that suggestion in the
subversion.tigris.org FAQ a couple of days ago.
It would be intresting to know, what actually happens when the prossess
hangs on:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(10023), sin_addr=inet_addr("
78.46.66.102")}, 16) = 0
read(4, "( success ( 1 2 ( ANONYMOUS ) ( "..., 4096) = 76
write(4, "( 2 ( edit-pipeline svndiff1 abs"..., 100) = 100
read(4, "( success ( ( CRAM-MD5 ) 14:as3s"..., 4096) = 47
write(4, "( CRAM-MD5 ( ) ) ", 17) = 17
read(4,
Is that one of the places where random numbers are needed?
2008/4/28 Karl Fogel <kf...@red-bean.com>:
> "Erik Huelsmann" <eh...@gmail.com> writes:
> > Karl, may I suggest this is not related to the repository, but rather
> > to the server running out of entropy?
> >
> > Search the list archives for solutions to the problem of servers
> > drawing from /dev/random and blocking because of it.
>
> Ah, yes. For some reason that seems to have come up a lot in the last
> few days -- maybe the solar system is running out of entropy or
> something.
>
> Thorsten Schmitt-Rink, can you rebuild APR to use /dev/urandom instead
> of /dev/random, and then rebuild Subversion against the new APR? Uh,
> I'm not sure whether both client and server need this done (and in fact,
> the answer may be different for http:// vs svn://), so do both to be
> safe. I just can't remember all the circumstances in which we need
> random numbers.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: performance issue concerning externals
Posted by Karl Fogel <kf...@red-bean.com>.
"Erik Huelsmann" <eh...@gmail.com> writes:
> Karl, may I suggest this is not related to the repository, but rather
> to the server running out of entropy?
>
> Search the list archives for solutions to the problem of servers
> drawing from /dev/random and blocking because of it.
Ah, yes. For some reason that seems to have come up a lot in the last
few days -- maybe the solar system is running out of entropy or
something.
Thorsten Schmitt-Rink, can you rebuild APR to use /dev/urandom instead
of /dev/random, and then rebuild Subversion against the new APR? Uh,
I'm not sure whether both client and server need this done (and in fact,
the answer may be different for http:// vs svn://), so do both to be
safe. I just can't remember all the circumstances in which we need
random numbers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: performance issue concerning externals
Posted by Erik Huelsmann <eh...@gmail.com>.
On Mon, Apr 28, 2008 at 10:18 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "Thorsten Schmitt-Rink" <sc...@gmail.com> writes:
>
> > I'm no pro, so I don't know how the correct debug approach would be for this
> > case.
> > I did a strace on the proccess and saw that it started hanging when waiting for
> > input from the stream.
> > Here's the corresponding part of the strace output:
> >
> > socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
> > connect(4, {sa_family=AF_INET, sin_port=htons(10023), sin_addr=inet_addr("
> > 78.46.66.102")}, 16) = 0
> > read(4, "( success ( 1 2 ( ANONYMOUS ) ( "..., 4096) = 76
> > write(4, "( 2 ( edit-pipeline svndiff1 abs"..., 100) = 100
> > read(4, "( success ( ( CRAM-MD5 ) 14:as3s"..., 4096) = 47
> > write(4, "( CRAM-MD5 ( ) ) ", 17) = 17
> > read(4,
> >
> > Then nothing would happen for a while.
> > After the usual 5 - 8 minutes, it continued.
>
> Ugh.
>
> Can you post the repository? That is, 'svnadmin dump' the repository,
> put that somewhere, and offer it up for others to try to reproduce this?
> If we could narrow this down to knowing that the problem is unique to
> your server, that would help.
Karl, may I suggest this is not related to the repository, but rather
to the server running out of entropy?
Search the list archives for solutions to the problem of servers
drawing from /dev/random and blocking because of it.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: performance issue concerning externals
Posted by Karl Fogel <kf...@red-bean.com>.
"Thorsten Schmitt-Rink" <sc...@gmail.com> writes:
> I'm no pro, so I don't know how the correct debug approach would be for this
> case.
> I did a strace on the proccess and saw that it started hanging when waiting for
> input from the stream.
> Here's the corresponding part of the strace output:
>
> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
> connect(4, {sa_family=AF_INET, sin_port=htons(10023), sin_addr=inet_addr("
> 78.46.66.102")}, 16) = 0
> read(4, "( success ( 1 2 ( ANONYMOUS ) ( "..., 4096) = 76
> write(4, "( 2 ( edit-pipeline svndiff1 abs"..., 100) = 100
> read(4, "( success ( ( CRAM-MD5 ) 14:as3s"..., 4096) = 47
> write(4, "( CRAM-MD5 ( ) ) ", 17) = 17
> read(4,
>
> Then nothing would happen for a while.
> After the usual 5 - 8 minutes, it continued.
Ugh.
Can you post the repository? That is, 'svnadmin dump' the repository,
put that somewhere, and offer it up for others to try to reproduce this?
If we could narrow this down to knowing that the problem is unique to
your server, that would help.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: performance issue concerning externals
Posted by Thorsten Schmitt-Rink <sc...@gmail.com>.
I'm no pro, so I don't know how the correct debug approach would be for this
case.
I did a strace on the proccess and saw that it started hanging when waiting
for input from the stream.
Here's the corresponding part of the strace output:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(10023), sin_addr=inet_addr("
78.46.66.102")}, 16) = 0
read(4, "( success ( 1 2 ( ANONYMOUS ) ( "..., 4096) = 76
write(4, "( 2 ( edit-pipeline svndiff1 abs"..., 100) = 100
read(4, "( success ( ( CRAM-MD5 ) 14:as3s"..., 4096) = 47
write(4, "( CRAM-MD5 ( ) ) ", 17) = 17
read(4,
Then nothing would happen for a while.
After the usual 5 - 8 minutes, it continued.
2008/4/28 Karl Fogel <kf...@red-bean.com>:
> "Thorsten Schmitt-Rink" <sc...@gmail.com> writes:
> > thank you for the fast reply.
> > Yes the externals are running on the same server, in the same repository
> root
> > as the other repositories.
> > When I directly checkout one of the externals, the performance is great.
> > As soon as I check out the main repository, the proccess hangs for about
> 8
> > minutes each time it reaches an external.
> > The repositories are all really small and don't contain big files.
> > I hope I didn't miss to provide important data.
> >
> > P.S.:
> > A colleague just reported, he is experiencing the same issue on svn via
> apache.
>
> Something is *definitely* wrong with 8 minutes.
>
> Can you debug into the client and figure out where it's spending that
> time? Is it delaying on some request?
>
Re: performance issue concerning externals
Posted by Karl Fogel <kf...@red-bean.com>.
"Thorsten Schmitt-Rink" <sc...@gmail.com> writes:
> thank you for the fast reply.
> Yes the externals are running on the same server, in the same repository root
> as the other repositories.
> When I directly checkout one of the externals, the performance is great.
> As soon as I check out the main repository, the proccess hangs for about 8
> minutes each time it reaches an external.
> The repositories are all really small and don't contain big files.
> I hope I didn't miss to provide important data.
>
> P.S.:
> A colleague just reported, he is experiencing the same issue on svn via apache.
Something is *definitely* wrong with 8 minutes.
Can you debug into the client and figure out where it's spending that
time? Is it delaying on some request?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: performance issue concerning externals
Posted by Thorsten Schmitt-Rink <sc...@gmail.com>.
Hi,
thank you for the fast reply.
Yes the externals are running on the same server, in the same repository
root as the other repositories.
When I directly checkout one of the externals, the performance is great.
As soon as I check out the main repository, the proccess hangs for about 8
minutes each time it reaches an external.
The repositories are all really small and don't contain big files.
I hope I didn't miss to provide important data.
Kind regards
Thorsten
P.S.:
A colleague just reported, he is experiencing the same issue on svn via
apache.
2008/4/28 Karl Fogel <kf...@red-bean.com>:
> "Thorsten Schmitt-Rink" <sc...@gmail.com> writes:
> > I' running svnserve v1.4.6 (r28521) standalone on debian-etch 4.1.1-21
> > 32bit. The apr to uses urandom instead of random. The repositories
> > on my server are configured to use the same user and group file. I
> > checkout repositories using the svn protocol. svn co
> > svn://myserver.ip:port/ repo Everything runs fine as long as I don't
> > have externals in my repositories. When I add externals to a
> > repository, checkouts and updates etc. become really slow. And I mean
> > really slow. :( I've searched the net and the subversion site, but
> > couldn't find anyone with a simular problem. Does anyone have an idea
> > what could be leading to this behaviour?
>
> Are these externals pointing to the same repository? The same server?
> Different servers entirely?
>
> IOW, some more data would help here. Give us the transcripts and the
> actual timings, and we may be able to shed some light on it (no
> guarantees of course).
>
> Good luck,
> -Karl
>
Re: performance issue concerning externals
Posted by Karl Fogel <kf...@red-bean.com>.
"Thorsten Schmitt-Rink" <sc...@gmail.com> writes:
> I' running svnserve v1.4.6 (r28521) standalone on debian-etch 4.1.1-21
> 32bit. The apr to uses urandom instead of random. The repositories
> on my server are configured to use the same user and group file. I
> checkout repositories using the svn protocol. svn co
> svn://myserver.ip:port/ repo Everything runs fine as long as I don't
> have externals in my repositories. When I add externals to a
> repository, checkouts and updates etc. become really slow. And I mean
> really slow. :( I've searched the net and the subversion site, but
> couldn't find anyone with a simular problem. Does anyone have an idea
> what could be leading to this behaviour?
Are these externals pointing to the same repository? The same server?
Different servers entirely?
IOW, some more data would help here. Give us the transcripts and the
actual timings, and we may be able to shed some light on it (no
guarantees of course).
Good luck,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org