On Wed, Oct 21, 2009 at 3:51 AM, John Lauro <[email protected]> wrote: > You mention loopback interface. You could be running out of port numbers to > for the connections. > What's your /proc/sys/net/ipv4/ip_local_port_range? cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000
> > > What's netstat -s | grep -i list show on the server? nothing at all, no list to match on that output > > also, i've disabled tcp_sack with no effect > >> -----Original Message----- >> From: David Birdsong [mailto:[email protected]] >> Sent: Wednesday, October 21, 2009 6:36 AM >> To: haproxy >> Subject: slow tcp handshake >> >> This isn't haproxy related, but this list is so knowledgable on >> network problems. >> >> I'm troubleshooting our slow webserver and I've drilled down to a TCP >> handshake taking up to 10 seconds. This handshake doesn't actually >> really start until the client sends it's 3rd syn. The first 2 syn's >> are completely ignored, the 3rd is ACKed a full 10 seconds after the >> first syn is sent. After this, read times are fast. >> >> This happens over the loopback interface. >> >> Can an app get backed up in it's listen queue and affect some sort of >> syn queue, or will the kernel handle the handshake irrespective of the >> server's listen queue? >> >> I've searched all over the internets, and I'm plumb out of ideas. >> >> syn_cookies are disabled >> ip_tables unloaded >> /proc/sys/net/ipv4/tcp_max_syn_backlog was set to 1024 and active >> connections to the server never rose above 960, so thought this may be >> it...but i doubled it and it had no affect >> >> >> Fedora 8 2.6.26.8-57.fc8 >> Web server is lighttpd >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.422 / Virus Database: 270.14.11/2430 - Release Date: >> 10/20/09 18:42:00 > > >
