You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Johannes van der Vegt <Jo...@applicos.com> on 2018/06/05 08:16:15 UTC
SVN access became slow
Hi group,
Suddenly SVN access became very slow on my PC. Before, everything ran fine.
We have a small company network.
* "Server" PC: Win10 Pro (1709), runs the svnserve.exe service,
version 1.10.0
* My PC: Win10Pro (1803), using SVN 1.10.0-dev (Apr 14, 2018)
* Other PC: Win10Pro (1803)
When I run "svn info svn://server/RepoPath", I need to wait very long (over
40 seconds) before I get the response.
When I use the server's specific IPv4 address, it responds immediately.
When I use the server's specific IPv6 address, I get errors:
svn: E170013: Unable to connect to a repository at URL
'svn://[fe80::c0a0:7afa:1cxx:xx9d]/RepoPath'
svn: E730060: Can't connect to host 'fe80::c0a0:7afa:1cxx:xx9d': A
connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.
When I run "svn info svn://server/RepoPath" from another PC on our network,
it runs fine.
I thought there might be a NetBIOS name resolution issue. But running a
normal "ping server" immediately stars pinging via IPv6, so I figure NetBIOS
works fine here.
I have sniffed around with WireShark. I am really a novice here, so having
misinterpreted my observations Is very well possible. But I noticed that the
initial request (using the NetBIOS name) to the server goes via IPv6
addresses, but the data is returned via IPv4 addresses. This is on my PC,
and also on the other PC in our network. Would this be normal?
I already disabled the Windows firewall on both server and client, but to no
avail.
I'm not sure what to do next. Any clues?
I'm not subscribed to this mailing list, so being explicitly CC:ed in any
response would be appreciated.
Thanks,
Johannes
Re: SVN access became slow
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jun 05, 2018 at 01:40:10PM +0000, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, 05 Jun 2018 15:33 +0200:
> > If your SVN server has an IPv6 address but does not provide service
> > on that address, this is expected behaviour. There is no way for
> > the SVN client to know that it should not be trying this address.
>
> Well, connecting to the IPv6 address on TCP port 3690 could return a TCP
> RST or an ICMPv6 "Host unreachable" or the like, as opposed to no
> response at all (which I presume is what wireshark is showing).
Yes, it sounds like something might be dropping packets somewhere.
Re: SVN access became slow
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Tue, 05 Jun 2018 15:33 +0200:
> If your SVN server has an IPv6 address but does not provide service
> on that address, this is expected behaviour. There is no way for
> the SVN client to know that it should not be trying this address.
Well, connecting to the IPv6 address on TCP port 3690 could return a TCP
RST or an ICMPv6 "Host unreachable" or the like, as opposed to no
response at all (which I presume is what wireshark is showing).
Re: SVN access became slow
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Wed, 06 Jun 2018 15:18 +0200:
> On Wed, Jun 06, 2018 at 12:37:53PM +0200, Johannes van der Vegt wrote:
> > But... Can I have two processes (IPv4 and IPv6) running on the same port
> > together? And will they access the same database on the driver? That may
> > give trouble if two users connect simultaneously, right?
>
> No, that is not a problem. Writes to the same repository from
> different processes are always serialized properly.
> [...]
As Stefan said, having multiple, concurrent readers and writers is 100% supported.
At the network level there is no problem either. The IPv4 and IPv6
stacks are independent; the TCP/IPv4 and TCP/IPv6 sockets happen to use
the same port number, but that's not a problem in any way; it's exactly like
running two TCP/IPv4 listening sockets on different port numbers.
Re: SVN access became slow
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jun 07, 2018 at 09:27:46AM +0200, Johannes van der Vegt wrote:
> Ok, I have the two instances running simultaneously now, and everything
> seems to be working. I trust your advice, backed by Daniel Shahaf, that this
> is a normal and proper situation.
>
> About the slow 1.10.0 client experience I had: trying IPv6 first and then
> falling back to IPv4 is normal, you told me, correct?
This depends on the choices taken by implementors of the
operating system's DNS resolver. It has nothing to do
with either SVN or APR (unless APR's DNS API wrappers
change the results returned from the system for some
reason, but I'd doubt it was doing that).
> And (Tortoise)SVN 1.9.7 went straight to IPv4 because of APR 1.5.2? Does APR
> 1.5.2 not support (or not default to) IPv6?
I don't know, and I don't have time to find out.
You could ask this question to the APR project: https://apr.apache.org
> Then a lot of users must have ran into this issue, right? Namely: Every user
> running an APR 1.5 SVN server, and a (Tortoise)SVN 1.10.0 client.
Most servers use Apache HTTPD which supports dual-stack operation.
This problem is specific to server deployments using the svn://
repository access method on IPv6-enabled servers.
> Well, my issue is solved now. Thanks for the support!!!
Glad we could help. You're welcome :)
RE: SVN access became slow
Posted by Johannes van der Vegt <Jo...@applicos.com>.
Ok, I have the two instances running simultaneously now, and everything
seems to be working. I trust your advice, backed by Daniel Shahaf, that this
is a normal and proper situation.
About the slow 1.10.0 client experience I had: trying IPv6 first and then
falling back to IPv4 is normal, you told me, correct?
And (Tortoise)SVN 1.9.7 went straight to IPv4 because of APR 1.5.2? Does APR
1.5.2 not support (or not default to) IPv6?
Then a lot of users must have ran into this issue, right? Namely: Every user
running an APR 1.5 SVN server, and a (Tortoise)SVN 1.10.0 client.
Well, my issue is solved now. Thanks for the support!!!
-----Original Message-----
From: Stefan Sperling [mailto:stsp@elego.de]
Sent: Wednesday 6 June 2018 15:19
To: Johannes van der Vegt <Jo...@applicos.com>
Cc: users@subversion.apache.org
Subject: Re: SVN access became slow
On Wed, Jun 06, 2018 at 12:37:53PM +0200, Johannes van der Vegt wrote:
> The APR version gave me a hint in the right direction.
>
> Client SVN linked dependencies:
> SVN 1.10.0: - APR 1.6.3 (compiled with 1.6.3)
> SVN 1.9.7: - APR 1.5.2 (compiled with 1.5.2)
> (Did you mix up 1.10 and 1.9 in your list? Because my version numbers
> are swapped w.r.t. yours)
The 1.9 binaries I used were not compiled by me and do indeed use a newer
APR version. My 1.10 build is a custom build which happens to use an older
APR version.
> On the server:
> SVN 1.10.0: - APR 1.5.1 (compiled with 1.5.1) This was a version
> downloaded from CollabNet.
> I installed TortoiseSVN with the command-line-tools on the server.
> That gave the following version info:
> SVN 1.10.0-dev: - APR 1.6.3 (compiled with 1.6.3)
>
> Starting the server:
> svnserve -d --listen-port 3690 -6 -r "D:/[RepoPath]"
>
> IT WORKS!!! I now have an ipv6 service running, and accessing it from
> my main PC is fast!
OK, great.
> But... Can I have two processes (IPv4 and IPv6) running on the same
> port together? And will they access the same database on the driver?
> That may give trouble if two users connect simultaneously, right?
No, that is not a problem. Writes to the same repository from different
processes are always serialized properly.
It's the same situation as if you were running a multi-process or
multi-threaded SVN server, as is the case when Apache HTTPD is used with
mod_dav_svn, or when multiple users commit at the same time via svn+ssh://.
Running two svnserve in parallel is not an exceptional situation because it
can happen at any time when svn+ssh:// repository access is used. With
svn+ssh:// each client access spawns a new and separate svnserve process.
Re: SVN access became slow
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 06, 2018 at 12:37:53PM +0200, Johannes van der Vegt wrote:
> The APR version gave me a hint in the right direction.
>
> Client SVN linked dependencies:
> SVN 1.10.0: - APR 1.6.3 (compiled with 1.6.3)
> SVN 1.9.7: - APR 1.5.2 (compiled with 1.5.2)
> (Did you mix up 1.10 and 1.9 in your list? Because my version numbers are
> swapped w.r.t. yours)
The 1.9 binaries I used were not compiled by me and do
indeed use a newer APR version. My 1.10 build is a custom
build which happens to use an older APR version.
> On the server:
> SVN 1.10.0: - APR 1.5.1 (compiled with 1.5.1)
> This was a version downloaded from CollabNet.
> I installed TortoiseSVN with the command-line-tools on the server. That gave
> the following version info:
> SVN 1.10.0-dev: - APR 1.6.3 (compiled with 1.6.3)
>
> Starting the server:
> svnserve -d --listen-port 3690 -6 -r "D:/[RepoPath]"
>
> IT WORKS!!! I now have an ipv6 service running, and accessing it from my
> main PC is fast!
OK, great.
> But... Can I have two processes (IPv4 and IPv6) running on the same port
> together? And will they access the same database on the driver? That may
> give trouble if two users connect simultaneously, right?
No, that is not a problem. Writes to the same repository from
different processes are always serialized properly.
It's the same situation as if you were running a multi-process
or multi-threaded SVN server, as is the case when Apache HTTPD
is used with mod_dav_svn, or when multiple users commit at the
same time via svn+ssh://. Running two svnserve in parallel is
not an exceptional situation because it can happen at any time
when svn+ssh:// repository access is used. With svn+ssh:// each
client access spawns a new and separate svnserve process.
RE: SVN access became slow
Posted by Johannes van der Vegt <Jo...@applicos.com>.
The APR version gave me a hint in the right direction.
Client SVN linked dependencies:
SVN 1.10.0: - APR 1.6.3 (compiled with 1.6.3)
SVN 1.9.7: - APR 1.5.2 (compiled with 1.5.2)
(Did you mix up 1.10 and 1.9 in your list? Because my version numbers are
swapped w.r.t. yours)
On the server:
SVN 1.10.0: - APR 1.5.1 (compiled with 1.5.1)
This was a version downloaded from CollabNet.
I installed TortoiseSVN with the command-line-tools on the server. That gave
the following version info:
SVN 1.10.0-dev: - APR 1.6.3 (compiled with 1.6.3)
Starting the server:
svnserve -d --listen-port 3690 -6 -r "D:/[RepoPath]"
IT WORKS!!! I now have an ipv6 service running, and accessing it from my
main PC is fast!
But... Can I have two processes (IPv4 and IPv6) running on the same port
together? And will they access the same database on the driver? That may
give trouble if two users connect simultaneously, right?
@Stefan: Thanks for your time in supporting this so far!!.
-----Original Message-----
From: Stefan Sperling [mailto:stsp@elego.de]
Sent: Wednesday 6 June 2018 11:23
To: Johannes van der Vegt <Jo...@applicos.com>
Cc: users@subversion.apache.org
Subject: Re: SVN access became slow
On Wed, Jun 06, 2018 at 10:08:58AM +0200, Johannes van der Vegt wrote:
> I do "Telnet \\server 3690", and I get:
> Connecting To \\server...Could not open connection to the host, on
> port
> 3690: Connect failed
> I haven't used Telnet before, so maybe I'm doing something wrong?
>
> Running TCPView tool(from SysInternals) shows svnserve.exe with
> protocol 'TCP' on port 3690, while other ports (other services) do show
'TCPV6'.
>
> I installed SVN 1.10.0 client on the other client PC, and this also
> gets slow. Reverting to 1.9.7 solves this again (because it goes
> straight to IPv4).
> I'm puzzled... Why is 1.10.0 showing this behavior?
If svnserve is indeed not listening on an IPv6 socket even though the -6
option was provided, then that is unexpected behaviour.
There weren't any changes in svnserve between 1.9 and 1.10 which could
explain this, though, and it works as expected in a quick test on my system
(OpenBSD 6.3) with both SVN 1.10 and SVN 1.9:
$ netstat -an -finet6 | grep 3690
tcp6 0 0 *.3690 *.* LISTEN
If you can confirm that you're indeed seeing unexpected behaviour, then this
behaviour may depend on which version of APR was linked to svnserve because
svnserve is opening sockets via APR. The command 'svn --version -v'
should show the APR version under 'linked dependencies'.
The APR versions used by the SVN builds I've just tested successfully are,
respectively:
SVN 1.10: APR 1.5.2 (compiled with 1.5.2)
SVN 1.9: APR 1.6.3 (compiled with 1.6.3)
> Also: Why does SVNServe not provide an IPv6 service on our server PC?
As I mentioned before, svnserve does not support both IPv4 and IPv6 at the
same time. See https://issues.apache.org/jira/browse/SVN-2382
As documented there I made an attempt to add dual-stack support almost
10 years ago. There is no reason why it couldn't be made to work but I
failed at it back then and gave up on solving this task.
Starting one svnserve process per address family is the best workaround and
I am surprised that it does not work for you :-/
Re: SVN access became slow
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 06, 2018 at 10:08:58AM +0200, Johannes van der Vegt wrote:
> I do "Telnet \\server 3690", and I get:
> Connecting To \\server...Could not open connection to the host, on port
> 3690: Connect failed
> I haven't used Telnet before, so maybe I'm doing something wrong?
>
> Running TCPView tool(from SysInternals) shows svnserve.exe with protocol
> 'TCP' on port 3690, while other ports (other services) do show 'TCPV6'.
>
> I installed SVN 1.10.0 client on the other client PC, and this also gets
> slow. Reverting to 1.9.7 solves this again (because it goes straight to
> IPv4).
> I'm puzzled... Why is 1.10.0 showing this behavior?
If svnserve is indeed not listening on an IPv6 socket even though
the -6 option was provided, then that is unexpected behaviour.
There weren't any changes in svnserve between 1.9 and 1.10 which
could explain this, though, and it works as expected in a quick
test on my system (OpenBSD 6.3) with both SVN 1.10 and SVN 1.9:
$ netstat -an -finet6 | grep 3690
tcp6 0 0 *.3690 *.* LISTEN
If you can confirm that you're indeed seeing unexpected behaviour, then
this behaviour may depend on which version of APR was linked to svnserve
because svnserve is opening sockets via APR. The command 'svn --version -v'
should show the APR version under 'linked dependencies'.
The APR versions used by the SVN builds I've just tested successfully
are, respectively:
SVN 1.10: APR 1.5.2 (compiled with 1.5.2)
SVN 1.9: APR 1.6.3 (compiled with 1.6.3)
> Also: Why does SVNServe not provide an IPv6 service on our server PC?
As I mentioned before, svnserve does not support both IPv4 and IPv6
at the same time. See https://issues.apache.org/jira/browse/SVN-2382
As documented there I made an attempt to add dual-stack support almost
10 years ago. There is no reason why it couldn't be made to work but
I failed at it back then and gave up on solving this task.
Starting one svnserve process per address family is the best workaround
and I am surprised that it does not work for you :-/
RE: SVN access became slow
Posted by Johannes van der Vegt <Jo...@applicos.com>.
I do "Telnet \\server 3690", and I get:
Connecting To \\server...Could not open connection to the host, on port
3690: Connect failed
I haven't used Telnet before, so maybe I'm doing something wrong?
Running TCPView tool(from SysInternals) shows svnserve.exe with protocol
'TCP' on port 3690, while other ports (other services) do show 'TCPV6'.
I installed SVN 1.10.0 client on the other client PC, and this also gets
slow. Reverting to 1.9.7 solves this again (because it goes straight to
IPv4).
I'm puzzled... Why is 1.10.0 showing this behavior?
Also: Why does SVNServe not provide an IPv6 service on our server PC?
I think for now I will revert back to 1.9.7 on my main PC as well, until I
have a better view of what's going on.
-----Original Message-----
From: Stefan Sperling [mailto:stsp@elego.de]
Sent: Tuesday 5 June 2018 15:34
To: Johannes van der Vegt <Jo...@applicos.com>
Cc: users@subversion.apache.org
Subject: Re: SVN access became slow
On Tue, Jun 05, 2018 at 02:54:01PM +0200, Johannes van der Vegt wrote:
> Right... I installed a second service with the '-6' option. This did
> not make any difference.
Why does this not work? This should work. Can you connect to the SVN service
with telnet to the server's advertised IPv6 address on port 3690? Maybe
svnserve is not listening on the correct
IOPv6 address (see the --listen-host option)?
> Doing more wireshark sniffing:
> - At first, SVN client tries connecting from the local-link IPv6 address.
> There is no response. Two TCP retransmissions fail as well.
> - Second, SVN client tries connecting from the temporary IPv6 address.
> There is no response. Two TCP retransmissions fail as well.
> - Finally, SVN client falls back to IPv4. This is successful.
>
> The other client PC (Win10 Home 1803) runs an older SVN client
> (v1.9.7), and does not try IPv6 first; this one goes straight to IPv4.
> Running the 'svn info' command from that older version on my own PC
> also goes straight to IPv4.
>
> I believe there is no option to force the client to use IPv4?? (except
> specifically entering the IPv4 IP address) Have I found a bug?
I don't think there is a bug here. SVN will simply try addresses returned by
your client system's DNS resolver in turn. Maybe you could configure your
client system's DNS resolver to prefer IPv4 but that would not be a nice
solution.
If your SVN server has an IPv6 address but does not provide service on that
address, this is expected behaviour. There is no way for the SVN client to
know that it should not be trying this address.
If you do not intend to provide SVN service over IPv6, you could also
disable IPv6 entirely on the SVN server machine.
Re: SVN access became slow
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jun 05, 2018 at 02:54:01PM +0200, Johannes van der Vegt wrote:
> Right... I installed a second service with the '-6' option. This did not
> make any difference.
Why does this not work? This should work. Can you connect to the
SVN service with telnet to the server's advertised IPv6 address
on port 3690? Maybe svnserve is not listening on the correct
IOPv6 address (see the --listen-host option)?
> Doing more wireshark sniffing:
> - At first, SVN client tries connecting from the local-link IPv6 address.
> There is no response. Two TCP retransmissions fail as well.
> - Second, SVN client tries connecting from the temporary IPv6 address. There
> is no response. Two TCP retransmissions fail as well.
> - Finally, SVN client falls back to IPv4. This is successful.
>
> The other client PC (Win10 Home 1803) runs an older SVN client (v1.9.7), and
> does not try IPv6 first; this one goes straight to IPv4. Running the 'svn
> info' command from that older version on my own PC also goes straight to
> IPv4.
>
> I believe there is no option to force the client to use IPv4?? (except
> specifically entering the IPv4 IP address)
> Have I found a bug?
I don't think there is a bug here. SVN will simply try addresses
returned by your client system's DNS resolver in turn. Maybe you
could configure your client system's DNS resolver to prefer IPv4
but that would not be a nice solution.
If your SVN server has an IPv6 address but does not provide service
on that address, this is expected behaviour. There is no way for
the SVN client to know that it should not be trying this address.
If you do not intend to provide SVN service over IPv6, you could
also disable IPv6 entirely on the SVN server machine.
RE: SVN access became slow
Posted by Johannes van der Vegt <Jo...@applicos.com>.
Right... I installed a second service with the '-6' option. This did not
make any difference.
Doing more wireshark sniffing:
- At first, SVN client tries connecting from the local-link IPv6 address.
There is no response. Two TCP retransmissions fail as well.
- Second, SVN client tries connecting from the temporary IPv6 address. There
is no response. Two TCP retransmissions fail as well.
- Finally, SVN client falls back to IPv4. This is successful.
The other client PC (Win10 Home 1803) runs an older SVN client (v1.9.7), and
does not try IPv6 first; this one goes straight to IPv4. Running the 'svn
info' command from that older version on my own PC also goes straight to
IPv4.
I believe there is no option to force the client to use IPv4?? (except
specifically entering the IPv4 IP address)
Have I found a bug?
-----Original Message-----
From: Stefan Sperling [mailto:stsp@elego.de]
Sent: Tuesday 5 June 2018 12:12
To: Johannes van der Vegt <Jo...@applicos.com>
Cc: users@subversion.apache.org
Subject: Re: SVN access became slow
On Tue, Jun 05, 2018 at 10:16:15AM +0200, Johannes van der Vegt wrote:
> Hi group,
>
>
>
> Suddenly SVN access became very slow on my PC. Before, everything ran
fine.
>
>
>
> We have a small company network.
>
> * "Server" PC: Win10 Pro (1709), runs the svnserve.exe service,
> version 1.10.0
> * My PC: Win10Pro (1803), using SVN 1.10.0-dev (Apr 14, 2018)
> * Other PC: Win10Pro (1803)
>
>
>
> When I run "svn info svn://server/RepoPath", I need to wait very long
> (over
> 40 seconds) before I get the response.
>
> When I use the server's specific IPv4 address, it responds immediately.
>
> When I use the server's specific IPv6 address, I get errors:
svnserve supports either IPv4 or IPv6, but not both at the same time.
You could run two svnserve processes, one for IPv4 and one for IPv6.
There is a '--prefer-ipv6' option which makes svnserve use IPv6 instead of
IPv4, see the output 'svnserve --help'.
Re: SVN access became slow
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jun 05, 2018 at 10:16:15AM +0200, Johannes van der Vegt wrote:
> Hi group,
>
>
>
> Suddenly SVN access became very slow on my PC. Before, everything ran fine.
>
>
>
> We have a small company network.
>
> * "Server" PC: Win10 Pro (1709), runs the svnserve.exe service,
> version 1.10.0
> * My PC: Win10Pro (1803), using SVN 1.10.0-dev (Apr 14, 2018)
> * Other PC: Win10Pro (1803)
>
>
>
> When I run "svn info svn://server/RepoPath", I need to wait very long (over
> 40 seconds) before I get the response.
>
> When I use the server's specific IPv4 address, it responds immediately.
>
> When I use the server's specific IPv6 address, I get errors:
svnserve supports either IPv4 or IPv6, but not both at the same time.
You could run two svnserve processes, one for IPv4 and one for IPv6.
There is a '--prefer-ipv6' option which makes svnserve use IPv6 instead
of IPv4, see the output 'svnserve --help'.