[158625] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: TCP time_wait and port exhaustion for servers

daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Dec 5 14:36:08 2012

From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAP-guGX65qo67tS6ad-i-OAH3drQo9t4X5UT9S4wrZT-FURKWg@mail.gmail.com>
Date: Wed, 5 Dec 2012 11:31:14 -0800
To: William Herrin <bill@herrin.us>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On Dec 5, 2012, at 10:58 AM, William Herrin <bill@herrin.us> wrote:

> On Wed, Dec 5, 2012 at 12:09 PM, Ray Soucy <rps@maine.edu> wrote:
>> Like most web traffic, the majority of these connections open and
>> close in under a second.  When we get to a point that there is enough
>> traffic from users behind the proxy to be generating over 500 new
>> outgoing connections per second, sustained, we start having users
>> experience an error where there are no local ports available to Squid
>> to use since they're all tied up in a TIME_WAIT state.
>>=20
>> Here is an example of netstat totals on a box we're seeing the =
behavior on:
>>=20
>> 481947 TIME_WAIT
>=20
> Stupid question but how does 500 x 60 =3D 481947?  To have that many
> connections in TIME_WAIT on a 60 second timer, you'd need more like
> 8000 connections per second, wouldn't you?

Isn't TIME_WAIT based on disconnections, not connections?

Sure, assuming all connections are for equal durations, then the =
disconnection
rate would be roughly equal to the connection rate, and, of course over =
the long
term they will eventually trend towards equality, but that doesn't mean =
that the
peak of connections in TIME_WAIT will not be greater than the incoming =
connection
rate would suggest.

Owen



home help back first fref pref prev next nref lref last post