Re: Slow connections in Debian squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7-12-2009 1:15, Andrew Sackville-West wrote: On Sun, Dec 06, 2009 at 04:08:11PM -0800, Andrew Sackville-West wrote: On Mon, Dec 07, 2009 at 01:56:06AM +0200, Andrei Popescu wrote: On Sun,06.Dec.09, 15:39:59, Andrew Sackville-West wrote: there are clearly some differences. the lenny machine is making a ? request (whatever that means) while the squeeze machine is making both a A? and ? requests. And the responses are different. This behavior is consistent across attempts. This sounds like an ipv4/ipv6 issue. Maybe this NEWS.Debian entry for libc6 has the solution: glibc (2.9-8) unstable; urgency=low Starting with version 2.9-8, unified IPv4/IPv6 lookup have been enabled in the glibc's resolver. This is faster, fixes numerous of bugs, but is problematic on some broken DNS servers and/or wrongly configured firewalls. If such a DNS server is detected, the resolver switches (permanently for that process) to a mode where the second request is sent only when the first answer has been received. This means the first request will be timeout, but subsequent requests should be fast again. This behaviour can be enabled permanently by adding 'options single-request' to /etc/resolv.conf. Andrei, I owe you a beer! That's done it right there. Now it's just a matter of figuring out whether it's my firewall or my dns server that's broken... :) blech... it's my firewall, or several public dns servers are broken... A How did you go about checking this? I use OpenDNS as dns servers and no other firewall than what comes with Debian by default. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksczc0ACgkQkPq5zKsAFii8pACcCLr4D4x+WitQSKlDogWz8+HM 4PgAniK/QKcewFlpdFOo1VQnTzM6l7nq =IfIE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Slow connections in Debian squeeze
On Mon, Dec 07, 2009 at 10:41:35AM +0100, Nick Douma wrote: On 7-12-2009 1:15, Andrew Sackville-West wrote: On Sun, Dec 06, 2009 at 04:08:11PM -0800, Andrew Sackville-West wrote: On Mon, Dec 07, 2009 at 01:56:06AM +0200, Andrei Popescu wrote: [..] This sounds like an ipv4/ipv6 issue. Maybe this NEWS.Debian entry for libc6 has the solution: glibc (2.9-8) unstable; urgency=low Starting with version 2.9-8, unified IPv4/IPv6 lookup have been enabled in the glibc's resolver. This is faster, fixes numerous of bugs, but is problematic on some broken DNS servers and/or wrongly configured firewalls. If such a DNS server is detected, the resolver switches (permanently for that process) to a mode where the second request is sent only when the first answer has been received. This means the first request will be timeout, but subsequent requests should be fast again. This behaviour can be enabled permanently by adding 'options single-request' to /etc/resolv.conf. Andrei, I owe you a beer! That's done it right there. Now it's just a matter of figuring out whether it's my firewall or my dns server that's broken... :) blech... it's my firewall, or several public dns servers are broken... A How did you go about checking this? I use OpenDNS as dns servers and no other firewall than what comes with Debian by default. I just googled a list of public dns servers and tried several in a row. They all showed the same problem suggesting that the problem is local to me. Or, as I said, I happened to use only servers in the broken subset of available public servers. specifically, it was a series of edits to /etc/resolv.conf to point to different servers and toggling the single-request option. regardless, it's nice to be snappy again. I didn't realise how annoying it was... A signature.asc Description: Digital signature
Re: Slow connections in Debian squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7-12-2009 19:33, Andrew Sackville-West wrote: On Mon, Dec 07, 2009 at 10:41:35AM +0100, Nick Douma wrote: On 7-12-2009 1:15, Andrew Sackville-West wrote: On Sun, Dec 06, 2009 at 04:08:11PM -0800, Andrew Sackville-West wrote: On Mon, Dec 07, 2009 at 01:56:06AM +0200, Andrei Popescu wrote: [..] This sounds like an ipv4/ipv6 issue. Maybe this NEWS.Debian entry for libc6 has the solution: glibc (2.9-8) unstable; urgency=low Starting with version 2.9-8, unified IPv4/IPv6 lookup have been enabled in the glibc's resolver. This is faster, fixes numerous of bugs, but is problematic on some broken DNS servers and/or wrongly configured firewalls. If such a DNS server is detected, the resolver switches (permanently for that process) to a mode where the second request is sent only when the first answer has been received. This means the first request will be timeout, but subsequent requests should be fast again. This behaviour can be enabled permanently by adding 'options single-request' to /etc/resolv.conf. Andrei, I owe you a beer! That's done it right there. Now it's just a matter of figuring out whether it's my firewall or my dns server that's broken... :) blech... it's my firewall, or several public dns servers are broken... A How did you go about checking this? I use OpenDNS as dns servers and no other firewall than what comes with Debian by default. I just googled a list of public dns servers and tried several in a row. They all showed the same problem suggesting that the problem is local to me. Or, as I said, I happened to use only servers in the broken subset of available public servers. specifically, it was a series of edits to /etc/resolv.conf to point to different servers and toggling the single-request option. regardless, it's nice to be snappy again. I didn't realise how annoying it was... A So to summarize, enabling the single-request option in /etc/resolv.conf solves the 5 second delay issue? Or did you find a non-broken public DNS server in the end? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksdTDMACgkQkPq5zKsAFiijpQCgiRDa6+GWHXUqODQBh/z6+D2z UQsAn3rwdCg0Kt+mdY7Og9iBLAX9OI0p =5WZw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Slow connections in Debian squeeze
On Mon, Dec 07, 2009 at 07:40:53PM +0100, Nick Douma wrote: On 7-12-2009 19:33, Andrew Sackville-West wrote: [... snip resolution to dns delays...] How did you go about checking this? I use OpenDNS as dns servers and no other firewall than what comes with Debian by default. I just googled a list of public dns servers and tried several in a row. They all showed the same problem suggesting that the problem is local to me. Or, as I said, I happened to use only servers in the broken subset of available public servers. specifically, it was a series of edits to /etc/resolv.conf to point to different servers and toggling the single-request option. regardless, it's nice to be snappy again. I didn't realise how annoying it was... So to summarize, enabling the single-request option in /etc/resolv.conf solves the 5 second delay issue? Or did you find a non-broken public DNS server in the end? enabling single-request solved the problem for me. I cannot definitively state that the problem is in my network, but I suspect it is. I found no public dns that did not have the problem for me suggesting that the problem is local to my network somewhere. A signature.asc Description: Digital signature
Re: Slow connections in Debian squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Sackville-West wrote: On Mon, Dec 07, 2009 at 07:40:53PM +0100, Nick Douma wrote: On 7-12-2009 19:33, Andrew Sackville-West wrote: [... snip resolution to dns delays...] How did you go about checking this? I use OpenDNS as dns servers and no other firewall than what comes with Debian by default. I just googled a list of public dns servers and tried several in a row. They all showed the same problem suggesting that the problem is local to me. Or, as I said, I happened to use only servers in the broken subset of available public servers. specifically, it was a series of edits to /etc/resolv.conf to point to different servers and toggling the single-request option. regardless, it's nice to be snappy again. I didn't realise how annoying it was... So to summarize, enabling the single-request option in /etc/resolv.conf solves the 5 second delay issue? Or did you find a non-broken public DNS server in the end? enabling single-request solved the problem for me. I cannot definitively state that the problem is in my network, but I suspect it is. I found no public dns that did not have the problem for me suggesting that the problem is local to my network somewhere. A My results after enabling options single-request in /etc/resolv.conf, this is the same as the 3-redirect wget I did earlier: real0m0.454s user0m0.004s sys 0m0.008s Looks like we found the problem. Thanks for your help. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksdWHYACgkQkPq5zKsAFihhHgCfXbytNRxnZIjLaFW7pxkdxiKG tw8AnR3n/uBUUZ0s00BSUMYuLZ3Gnd3z =peho -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Slow connections in Debian squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 07 Dec 2009 11:14:18 -0800 Andrew Sackville-West and...@farwestbilliards.com wrote: On Mon, Dec 07, 2009 at 07:40:53PM +0100, Nick Douma wrote: On 7-12-2009 19:33, Andrew Sackville-West wrote: [... snip resolution to dns delays...] How did you go about checking this? I use OpenDNS as dns servers and no other firewall than what comes with Debian by default. I just googled a list of public dns servers and tried several in a row. They all showed the same problem suggesting that the problem is local to me. Or, as I said, I happened to use only servers in the broken subset of available public servers. specifically, it was a series of edits to /etc/resolv.conf to point to different servers and toggling the single-request option. regardless, it's nice to be snappy again. I didn't realise how annoying it was... So to summarize, enabling the single-request option in /etc/resolv.conf solves the 5 second delay issue? Or did you find a non-broken public DNS server in the end? enabling single-request solved the problem for me. Just where in resolv.conf do you put the line options single-requests ? Thanks - -- Frank -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJLHWH6AAoJEMEDyLTvrVhjltkH/A8iN1KaIrEsG/uTFrSa9lw0 +x7oY5Hl/YDW/MVTL7pHvBM1vy7MzbUORhpkSMZnRjkhAWqo7oeSvTYIQbafeWf0 GgpwC8mec45xYrAXMN0jgCkh+BEtRmjMrWQfb6/b52cxnRAS9V+S8q1osc5ETtEe hdLf2MNu7YatclHUTO6BnmVqty3ea2sjKumiTHEg3R46dKyhF+SpHPh11hUdboeu 2n+GR/yViYhfZ9RLao9U+8Xys8TdCYDvJk7VrcrvJNUjYPz2T4kjfs3wS+iGuXnq bS2Oo8L5xoPmLaQtASQjqXIlbN/24KaFXb1WSDB/S9pE5pxuHITkoNGlGx0z/Bc= =CfHr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Slow connections in Debian squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7-12-2009 21:13, Frank McCormick wrote: On Mon, 07 Dec 2009 11:14:18 -0800 Andrew Sackville-West and...@farwestbilliards.com wrote: On Mon, Dec 07, 2009 at 07:40:53PM +0100, Nick Douma wrote: On 7-12-2009 19:33, Andrew Sackville-West wrote: [... snip resolution to dns delays...] How did you go about checking this? I use OpenDNS as dns servers and no other firewall than what comes with Debian by default. I just googled a list of public dns servers and tried several in a row. They all showed the same problem suggesting that the problem is local to me. Or, as I said, I happened to use only servers in the broken subset of available public servers. specifically, it was a series of edits to /etc/resolv.conf to point to different servers and toggling the single-request option. regardless, it's nice to be snappy again. I didn't realise how annoying it was... So to summarize, enabling the single-request option in /etc/resolv.conf solves the 5 second delay issue? Or did you find a non-broken public DNS server in the end? enabling single-request solved the problem for me. Just where in resolv.conf do you put the line options single-requests ? Thanks I put it at the bottom, after the nameserver entries. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksdYwcACgkQkPq5zKsAFihJnQCeIt2vsYITgfTMxY5gqMeJO8Yk f0kAmgNYftf+XgbeAGZwdJr59S29lN2d =NAew -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Slow connections in Debian squeeze
On Mon, Dec 07, 2009 at 03:13:46PM -0500, Frank McCormick wrote: On Mon, 07 Dec 2009 11:14:18 -0800 Andrew Sackville-West and...@farwestbilliards.com wrote: On Mon, Dec 07, 2009 at 07:40:53PM +0100, Nick Douma wrote: On 7-12-2009 19:33, Andrew Sackville-West wrote: [... snip resolution to dns delays...] How did you go about checking this? I use OpenDNS as dns servers and no other firewall than what comes with Debian by default. I just googled a list of public dns servers and tried several in a row. They all showed the same problem suggesting that the problem is local to me. Or, as I said, I happened to use only servers in the broken subset of available public servers. specifically, it was a series of edits to /etc/resolv.conf to point to different servers and toggling the single-request option. regardless, it's nice to be snappy again. I didn't realise how annoying it was... So to summarize, enabling the single-request option in /etc/resolv.conf solves the 5 second delay issue? Or did you find a non-broken public DNS server in the end? enabling single-request solved the problem for me. Just where in resolv.conf do you put the line options single-requests ? I don't think it matters, but I put it right after the nameserver entry. A signature.asc Description: Digital signature
Re: Slow connections in Debian squeeze
On Sat, 5 Dec 2009 20:38:53 -0800 Andrew Sackville-West and...@farwestbilliards.com wrote: On Sat, Dec 05, 2009 at 07:44:42PM -0500, Celejar wrote: ... II) Try a DNS cacher (dnsmasq) this is a bandaid solution, imo, and may not help anyway... We don't try solutions that may not help? Anyway, dnsmasq is probably something worth doing regardless - it saves time, bandwidth and server load (although perhaps not all that much of any). Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Slow connections in Debian squeeze
On Sun, Dec 06, 2009 at 09:01:51AM -0500, Celejar wrote: On Sat, 5 Dec 2009 20:38:53 -0800 Andrew Sackville-West and...@farwestbilliards.com wrote: On Sat, Dec 05, 2009 at 07:44:42PM -0500, Celejar wrote: ... II) Try a DNS cacher (dnsmasq) this is a bandaid solution, imo, and may not help anyway... We don't try solutions that may not help? yeah, that came out wrong... sorry. But thinking about it, it doesn't seem a solution to me because it merely hides the problem under the cache. But I will look into using it as a temporary solution. meanwhile, some tests using time wget http://www.google.com on a lenny machine typically looks like: --2009-12-06 09:47:44-- http://www.google.com/ Resolving www.google.com... 72.14.213.99, 72.14.213.103, 72.14.213.104, ... Connecting to www.google.com|72.14.213.99|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: `index.html.14' [ = ] 5,628 --.-K/s in 0.06s 2009-12-06 09:47:44 (88.4 KB/s) - `index.html.14' saved [5628] real 0m0.279s user 0m0.000s sys 0m0.004s very consistently. on the problem machine, this is typical: --2009-12-06 09:36:55-- http://www.google.com/ Resolving www.google.com... 72.14.213.103, 72.14.213.104, 72.14.213.105, ... Connecting to www.google.com|72.14.213.103|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: “index.html.5” [ = ] 5,628 --.-K/s in 0.06s 2009-12-06 09:37:00 (88.1 KB/s) - “index.html.5” saved [5628] real0m5.280s user0m0.000s sys 0m0.004s the pause is at the Resolving www.google.com... line for 5 seconds, very consistently. interestingly this doesn't happen with ping... and nsloopup www.google.com works just fine as well with something like 0.05s real time. I also see the delay with w3m, which points to the problem being in some common http library? Anyway, the delay is consistent at around 5 seconds. When I get more time, I'll see if I can learn more. Anyway, dnsmasq is probably something worth doing regardless - it saves time, bandwidth and server load (although perhaps not all that much of any). yeah. I used to run it. I don't know why I stopped. A signature.asc Description: Digital signature
Re: Slow connections in Debian squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I tried the same test with wget'ing Google, these are the results: $ wget google.com - --2009-12-06 19:05:45-- http://google.com/ Resolving google.com... 74.125.67.100, 74.125.45.100, 74.125.53.100 Connecting to google.com|74.125.67.100|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://www.google.com/ [following] - --2009-12-06 19:05:51-- http://www.google.com/ Resolving www.google.com... 74.125.79.147, 74.125.79.99, 74.125.79.104 Connecting to www.google.com|74.125.79.147|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://www.google.nl/ [following] - --2009-12-06 19:05:56-- http://www.google.nl/ Resolving www.google.nl... 74.125.79.147, 74.125.79.99, 74.125.79.104 Reusing existing connection to www.google.com:80. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: “index.html” [ = ] 6,066 - --.-K/s in 0.003s 2009-12-06 19:06:01 (1.76 MB/s) - “index.html” saved [6066] real0m15.394s user0m0.004s sys 0m0.000s - --- 1 wget command which resulted in two redirects, 15 seconds. - --- $ time wget http://www.google.com - --2009-12-06 19:07:44-- http://www.google.com/ Resolving www.google.com... 74.125.79.147, 74.125.79.99, 74.125.79.104 Connecting to www.google.com|74.125.79.147|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://www.google.nl/ [following] - --2009-12-06 19:07:49-- http://www.google.nl/ Resolving www.google.nl... 74.125.79.147, 74.125.79.99, 74.125.79.104 Reusing existing connection to www.google.com:80. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: “index.html.1” [ = ] 6,066 - --.-K/s in 0.004s 2009-12-06 19:07:54 (1.46 MB/s) - “index.html.1” saved [6066] real0m10.100s user0m0.000s sys 0m0.004s - --- 1 wget command which resulted in one redirect, 10 seconds. - --- $ time wget http://www.google.nl - --2009-12-06 19:08:00-- http://www.google.nl/ Resolving www.google.nl... 74.125.79.99, 74.125.79.104, 74.125.79.147 Connecting to www.google.nl|74.125.79.99|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: “index.html.2” [ = ] 6,078 - --.-K/s in 0.01s 2009-12-06 19:08:05 (484 KB/s) - “index.html.2” saved [6078] real0m5.067s user0m0.000s sys 0m0.004s - --- 1 wget command without a redirect, 5 seconds. - --- These results seem just as consistent as those from Andrew. 3 connections = 15 sec 2 connections = 10 sec 1 connection = 5 sec -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksb+eEACgkQkPq5zKsAFigEVgCfTon/v1SQVQ3sc7NDCvz97Rhd cSQAnR/DWpj6xW74Sj+OTbabA1mJMSN8 =M+EY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Slow connections in Debian squeeze
On Sun, 6 Dec 2009 09:58:12 -0800 Andrew Sackville-West and...@farwestbilliards.com wrote: ... meanwhile, some tests using time wget http://www.google.com ... real 0m0.279s user 0m0.000s sys0m0.004s very consistently. on the problem machine, this is typical: ... real0m5.280s user0m0.000s sys 0m0.004s the pause is at the Resolving www.google.com... line for 5 seconds, very consistently. interestingly this doesn't happen with ping... and nsloopup www.google.com works just fine as well with something like 0.05s real time. I also see the delay with w3m, which points to the problem being in some common http library? Anyway, the delay is consistent at around 5 seconds. Try some other protocols? An ever better idea: use netcat or telnet to talk to google.com on port 80 - same server and port, but no client side HTTP stuff, just plain text going out over the wire. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Slow connections in Debian squeeze
On Sun, Dec 06, 2009 at 02:15:55PM -0500, Celejar wrote: On Sun, 6 Dec 2009 09:58:12 -0800 Andrew Sackville-West and...@farwestbilliards.com wrote: ... meanwhile, some tests using time wget http://www.google.com ... real 0m0.279s user 0m0.000s sys 0m0.004s very consistently. on the problem machine, this is typical: ... real0m5.280s user0m0.000s sys 0m0.004s the pause is at the Resolving www.google.com... line for 5 seconds, very consistently. interestingly this doesn't happen with ping... and nsloopup www.google.com works just fine as well with something like 0.05s real time. I also see the delay with w3m, which points to the problem being in some common http library? Anyway, the delay is consistent at around 5 seconds. Try some other protocols? An ever better idea: use netcat or telnet to talk to google.com on port 80 - same server and port, but no client side HTTP stuff, just plain text going out over the wire. yup, same thing. on the squeeze machine telnet on several ports by name has a five second overhead. telnet by ip address is instantaneous. one a lenny machine, instaneous either way. I did a little digging with tcpdump and some rough timing. Here are typical results on my squeeze machine: and...@basement:~$ date +%T.%N; telnet www.google.com 80 /dev/null; date +%T.%N 15:33:19.209029221 Trying 72.14.213.105... Connected to www.l.google.com. Escape character is '^]'. Connection closed by foreign host. 15:33:24.359495441 note the five second lag... relevant tcpdump output (autofill off on purpose to preserve line structure): 15:33:19.211425 IP basement.36071 cache1.cet.com.domain: 19713+ A? www.google.com. (32) 15:33:19.211440 IP basement.36071 cache1.cet.com.domain: 21948+ ? www.google.com. (32) 15:33:19.254337 IP cache1.cet.com.domain basement.36071: 19713 7/4/4 CNAME[|domain] 15:33:24.216053 IP basement.36071 cache1.cet.com.domain: 19713+ A? www.google.com. (32) 15:33:24.258872 IP cache1.cet.com.domain basement.36071: 19713 7/4/4 CNAME[|domain] 15:33:24.258902 IP basement.36071 cache1.cet.com.domain: 21948+ ? www.google.com. (32) 15:33:24.302859 IP cache1.cet.com.domain basement.36071: 21948 1/1/0 CNAME[|domain] 15:33:24.303090 IP basement.57375 pv-in-f105.1e100.net.www: Flags [S], seq 3169135473, win 5840, options [mss 1460,sackOK,TS val 755934554 ecr 0,nop,wscale 7], length 0 now I don't really know much about this stuff, but I see that as a DNS exchange with cache1.cet.com which is the name server at 15:33:19.21+... with a quick response and then nothing from my side until 15:33:24.21+ when the request is repeated and then proceeds. compare to the lenny machine: mu...@swfamily:~$ date +%T.%N; telnet www.google.com 80 /dev/null ; date +%T.%N 15:33:47.058383705 Trying 72.14.213.106... Connected to www.l.google.com. Escape character is '^]'. Connection closed by foreign host. 15:33:47.220861942 15:33:47.061831 IP swfamily.37796 cache1.cet.com.domain: 10212+ ? www.google.com. (32) 15:33:47.061966 IP swfamily.35621 cache1.cet.com.domain: 46999+ PTR? 5.224.63.206.in-addr.arpa. (43) 15:33:47.103229 IP cache1.cet.com.domain swfamily.37796: 10212 1/1/0 CNAME www.l.google.com. (102) 15:33:47.103383 IP swfamily.51262 cache1.cet.com.domain: 65335+ A? www.google.com. (32) 15:33:47.111645 IP cache1.cet.com.domain swfamily.35621: 46999 1/2/2 (139) 15:33:47.148277 IP cache1.cet.com.domain swfamily.51262: 65335 7/4/4 CNAME www.l.google.com.,[|domain] 15:33:47.165497 IP swfamily.37594 pv-in-f106.1e100.net.www: S 81126028:81126028(0) win 5840 mss 1460,sackOK,timestamp 222186757 0,nop,wscale 5 there are clearly some differences. the lenny machine is making a ? request (whatever that means) while the squeeze machine is making both a A? and ? requests. And the responses are different. This behavior is consistent across attempts. I'm stumped, frankly. It's out of my depth. A signature.asc Description: Digital signature
Re: Slow connections in Debian squeeze
On Sun, Dec 06, 2009 at 07:37:23PM +0100, Nick Douma wrote: I tried the same test with wget'ing Google, these are the results: $ wget google.com [...] These results seem just as consistent as those from Andrew. 3 connections = 15 sec 2 connections = 10 sec 1 connection = 5 sec wow. that's amazing. See my tcpdump results on the other thread. A signature.asc Description: Digital signature
Re: Slow connections in Debian squeeze
On Sun,06.Dec.09, 15:39:59, Andrew Sackville-West wrote: there are clearly some differences. the lenny machine is making a ? request (whatever that means) while the squeeze machine is making both a A? and ? requests. And the responses are different. This behavior is consistent across attempts. This sounds like an ipv4/ipv6 issue. Maybe this NEWS.Debian entry for libc6 has the solution: glibc (2.9-8) unstable; urgency=low Starting with version 2.9-8, unified IPv4/IPv6 lookup have been enabled in the glibc's resolver. This is faster, fixes numerous of bugs, but is problematic on some broken DNS servers and/or wrongly configured firewalls. If such a DNS server is detected, the resolver switches (permanently for that process) to a mode where the second request is sent only when the first answer has been received. This means the first request will be timeout, but subsequent requests should be fast again. This behaviour can be enabled permanently by adding 'options single-request' to /etc/resolv.conf. -- Aurelien Jarno aure...@debian.org Thu, 23 Apr 2009 21:14:32 +0200 Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Slow connections in Debian squeeze
On Mon, Dec 07, 2009 at 01:56:06AM +0200, Andrei Popescu wrote: On Sun,06.Dec.09, 15:39:59, Andrew Sackville-West wrote: there are clearly some differences. the lenny machine is making a ? request (whatever that means) while the squeeze machine is making both a A? and ? requests. And the responses are different. This behavior is consistent across attempts. This sounds like an ipv4/ipv6 issue. Maybe this NEWS.Debian entry for libc6 has the solution: glibc (2.9-8) unstable; urgency=low Starting with version 2.9-8, unified IPv4/IPv6 lookup have been enabled in the glibc's resolver. This is faster, fixes numerous of bugs, but is problematic on some broken DNS servers and/or wrongly configured firewalls. If such a DNS server is detected, the resolver switches (permanently for that process) to a mode where the second request is sent only when the first answer has been received. This means the first request will be timeout, but subsequent requests should be fast again. This behaviour can be enabled permanently by adding 'options single-request' to /etc/resolv.conf. Andrei, I owe you a beer! That's done it right there. Now it's just a matter of figuring out whether it's my firewall or my dns server that's broken... :) A signature.asc Description: Digital signature
Re: Slow connections in Debian squeeze
On Sun, Dec 06, 2009 at 04:08:11PM -0800, Andrew Sackville-West wrote: On Mon, Dec 07, 2009 at 01:56:06AM +0200, Andrei Popescu wrote: On Sun,06.Dec.09, 15:39:59, Andrew Sackville-West wrote: there are clearly some differences. the lenny machine is making a ? request (whatever that means) while the squeeze machine is making both a A? and ? requests. And the responses are different. This behavior is consistent across attempts. This sounds like an ipv4/ipv6 issue. Maybe this NEWS.Debian entry for libc6 has the solution: glibc (2.9-8) unstable; urgency=low Starting with version 2.9-8, unified IPv4/IPv6 lookup have been enabled in the glibc's resolver. This is faster, fixes numerous of bugs, but is problematic on some broken DNS servers and/or wrongly configured firewalls. If such a DNS server is detected, the resolver switches (permanently for that process) to a mode where the second request is sent only when the first answer has been received. This means the first request will be timeout, but subsequent requests should be fast again. This behaviour can be enabled permanently by adding 'options single-request' to /etc/resolv.conf. Andrei, I owe you a beer! That's done it right there. Now it's just a matter of figuring out whether it's my firewall or my dns server that's broken... :) blech... it's my firewall, or several public dns servers are broken... A signature.asc Description: Digital signature
Slow connections in Debian squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since I full-upgraded my Debian installation from lenny to squeeze, I have been experiencing slow connections buildup. This is especially evident when I ssh to another server, while on other workstations (debian lenny and windows) the connection is almost instantly established, on my squeeze workstation it takes almost 10 seconds longer. This happens on all connections, for example, I recently enabled the MusicTracker plugin for pidgin, and set it to use my MPD server. Every time the plugin polls the server, pidgin freezes while it establishes the connection. I tried searching on the internet for similar problems, and found that it might be related to DNS lookups. I tried various fixes, but none of them seem to work. Unfortunately, I didn't keep track on what solutions I tried. Is anyone experiencing the same problems with Debian squeeze? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksacPUACgkQkPq5zKsAFiiUnACeLS9Odzd5vXEbA+sn37dxtyI7 u0EAoI0VnlQTZ8OCR5D0aNs3aE+UCC1L =wacr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Slow connections in Debian squeeze
On Sat, Dec 05, 2009 at 03:41:00PM +0100, Nick Douma wrote: Since I full-upgraded my Debian installation from lenny to squeeze, I have been experiencing slow connections buildup. This is especially evident when I ssh to another server, while on other workstations (debian lenny and windows) the connection is almost instantly established, on my squeeze workstation it takes almost 10 seconds longer. This happens on all connections, for example, I recently enabled the MusicTracker plugin for pidgin, and set it to use my MPD server. Every time the plugin polls the server, pidgin freezes while it establishes the connection. I tried searching on the internet for similar problems, and found that it might be related to DNS lookups. I tried various fixes, but none of them seem to work. Unfortunately, I didn't keep track on what solutions I tried. Is anyone experiencing the same problems with Debian squeeze? yeah. I've been seeing it for quite a while actually, and couldn't tell you specifically when it showed up. It appears to be only related to the actual connection (in ssh), as everything else zips right along. I also see it in http... google can take up to 10 seconds to appear. Ive largely been trying to ignore it as I haven't really had time to figure out what it is. Also, I *don't* see this problem on a lenny machine on the same subnet, and really interestingly, I *don't* see this problem on my laptop which is running slightly more sid-ish than the squeeze machine that shows the problem. A signature.asc Description: Digital signature
Re: Slow connections in Debian squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5-12-2009 17:00, Andrew Sackville-West wrote: On Sat, Dec 05, 2009 at 03:41:00PM +0100, Nick Douma wrote: Since I full-upgraded my Debian installation from lenny to squeeze, I have been experiencing slow connections buildup. This is especially evident when I ssh to another server, while on other workstations (debian lenny and windows) the connection is almost instantly established, on my squeeze workstation it takes almost 10 seconds longer. This happens on all connections, for example, I recently enabled the MusicTracker plugin for pidgin, and set it to use my MPD server. Every time the plugin polls the server, pidgin freezes while it establishes the connection. I tried searching on the internet for similar problems, and found that it might be related to DNS lookups. I tried various fixes, but none of them seem to work. Unfortunately, I didn't keep track on what solutions I tried. Is anyone experiencing the same problems with Debian squeeze? yeah. I've been seeing it for quite a while actually, and couldn't tell you specifically when it showed up. It appears to be only related to the actual connection (in ssh), as everything else zips right along. I also see it in http... google can take up to 10 seconds to appear. Ive largely been trying to ignore it as I haven't really had time to figure out what it is. Also, I *don't* see this problem on a lenny machine on the same subnet, and really interestingly, I *don't* see this problem on my laptop which is running slightly more sid-ish than the squeeze machine that shows the problem. A To further elaborate, when I send a message in Thunderbird, I notice that the sending message dialogue spends most of its time in the Looking up server stage. After that, the mail itself is sent in a split second. Did something change in the way Debian handles DNS lookups since Lenny? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksa9ZUACgkQkPq5zKsAFijjCwCfWs1DBjX3JkAGjQAOWWpua+Pv iEcAnR0DuRKmilaOVLLrkGocSDcSBrWJ =cCCj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Slow connections in Debian squeeze
On Sun, 06 Dec 2009 01:06:49 +0100 Nick Douma n.do...@nekoconeko.nl wrote: ... To further elaborate, when I send a message in Thunderbird, I notice that the sending message dialogue spends most of its time in the Looking up server stage. After that, the mail itself is sent in a split second. Did something change in the way Debian handles DNS lookups since Lenny? Without knowing what you tried, it's difficult to know what to suggest, but here are some things to consider: I) Try different DNS servers (perhaps OpenDNS) II) Try a DNS cacher (dnsmasq) III)Do something simple, like 'dig somesite', from the command line, preferably repeatedly, and report the response times (dig itself will report ';; Query time: n msec') Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Slow connections in Debian squeeze
On Sat, Dec 05, 2009 at 07:44:42PM -0500, Celejar wrote: On Sun, 06 Dec 2009 01:06:49 +0100 Nick Douma n.do...@nekoconeko.nl wrote: ... To further elaborate, when I send a message in Thunderbird, I notice that the sending message dialogue spends most of its time in the Looking up server stage. After that, the mail itself is sent in a split second. Did something change in the way Debian handles DNS lookups since Lenny? Without knowing what you tried, it's difficult to know what to suggest, but here are some things to consider: I)Try different DNS servers (perhaps OpenDNS) on my systems this is eliminated as the behavior only happens to one machine on the lan. the other, running lenny, is quite snappy using the same /etc/resolv.conf, so it is not DNS servers (in my case). II) Try a DNS cacher (dnsmasq) this is a bandaid solution, imo, and may not help anyway... III) Do something simple, like 'dig somesite', from the command line, preferably repeatedly, and report the response times (dig itself will report ';; Query time: n msec') good idea A signature.asc Description: Digital signature
