[squid-users] What exactly is "Do not set REUSEADDR on port."
I'm running into more connection stacking and while I solved my 3 second delay thanks to F5, i'm still seeing over 9000,1 connections on my web servers, all in Time Wait and most of them from Squid. As I continue to look thru config options, kernel params, I noticed this; Do not set REUSEADDR on port.. And wondered if I'm not using any persistance at all in my environment, if this is something I should be setting -R Thanks Tory
Re: [squid-users] What exactly is "Do not set REUSEADDR on port."
> I'm running into more connection stacking and while I solved my 3 > second delay thanks to F5, i'm still seeing over 9000,1 > connections on my web servers, all in Time Wait and most of them from > Squid. > > As I continue to look thru config options, kernel params, I noticed this; > > Do not set REUSEADDR on port.. > > And wondered if I'm not using any persistance at all in my > environment, if this is something I should be setting -R First thing to think about: are you using a 2.6s17+ squid? There is a timout parameter somewhere in the kernel config that gets around this TIME_WAIT state for loaded servers. I don't know what it is myself, but digging back in the archives for others optimising heavy-load servers will tell you. Amos
Re: [squid-users] What exactly is "Do not set REUSEADDR on port."
mån 2008-01-14 klockan 10:57 -0800 skrev Tory M Blue: > I'm running into more connection stacking and while I solved my 3 > second delay thanks to F5, i'm still seeing over 9000,1 > connections on my web servers, all in Time Wait and most of them from > Squid. TIME_WAIT is normal to be seen a lot. Those is completed and done with connections witch the TCP stack keeps a record of to deal properly with delayed packets. The TCP standard requires these to be kept for at least 2 minutes in most cases. Should not have much of an impact. But you may need to increase the range of free ports on the proxy as each blocks one outgoing port on the proxy.. (/proc/sys/net/ipv4/ip_local_port_range on Linux) Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] What exactly is "Do not set REUSEADDR on port."
On 19/01/2008, at 11:05 PM, Henrik Nordström wrote: mån 2008-01-14 klockan 10:57 -0800 skrev Tory M Blue: I'm running into more connection stacking and while I solved my 3 second delay thanks to F5, i'm still seeing over 9000,1 connections on my web servers, all in Time Wait and most of them from Squid. What exactly was the three second delay? and what did F5 do to fix this? Thanks Andrew smime.p7s Description: S/MIME cryptographic signature
Re: [squid-users] What exactly is "Do not set REUSEADDR on port."
On Jan 19, 2008 8:22 PM, Andrew Miehs <[EMAIL PROTECTED]> wrote: > What exactly was the three second delay? and what did F5 do to fix this? > > Thanks > > Andrew Sorry Andrew for the delay.. I believe I posted this when I first had the issue, but reposting so that it can be logged .42 = Squid .153 = apache web server "FROM F5" Looking through cache01-new, every instance of a 3 second delay that I find, I see where 10.13.200.42 sends the SYN, which is sent through the BIG-IP to 10.13.200.153. In each instance, I find that 10.13.200.153, rather than replying to the SYN with a SYN-ACK, simply sends an ACK. This, bing incorrect, gets a RST response from 10.13.200.42. After all, 10.13.200.42 was expecting SYN-ACK, not ACK. After a three second delay, 10.13.200.42 initiates the handshake again, and this time 10.13.200.153 sends the SYN-ACK response, which allows the handshake to carry on. I had iniitially thought that this was the fault of 10.13.200.42, but looking over the w04-new tcpdump, and matching up the delay packets, it's very clear that there is no SYN-ACK, resulting in this 3 second delay. As to why 10.13.200.153 would respond to a SYN with just an ACK, I believe that this may be due to a port reuse issue. The server believes that port to still be in use, while the BIG-IP believes it to be closed. To get around this, I would suggest the use of incrementing autoport, where the BIG-IP does not try to use the same ephemeral port that the client uses, but rather makes use of some other ephemeral port. To set this, from the command line issue the command: b internal use_incrementing_autoport 1 Which will enable this immediately, and does not require a reboot at all. ".. Again this fixed the 3 second delay but I still have a ton of connections sitting in Time_wait on the apache servers. I've tried to use a sysctl recycle option, but squid via the lb seems to have some issues with it (again I think it's in the LB) Tory
