Date: Mon, 5 Sep 2011 16:25:12 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: petz@nisshoko.net Cc: freebsd-hackers@freebsd.org Subject: Re: TIME_WAIT Assassination in FreeBSD??? Message-ID: <alpine.BSF.2.00.1109051618170.86306@fledge.watson.org> In-Reply-To: <007301cc6979$a690f9a0$f3b2ece0$@internode.on.net> References: <007301cc6979$a690f9a0$f3b2ece0$@internode.on.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 3 Sep 2011, Jarrod Lee Petz wrote: > 3. Does FreeBSD handle this situation? How? I can't seem to find much info > on TIME_WAIT assassination in FreeBSD is mentioned in RFC 6056 I'm not familiar with the RFC side here, but I can confirm that FreeBSD will recycle TIMEWAIT connections more quickly than specified when load is very high. This is done on the basis of allocated space; the sysctl: net.inet.tcp.maxtcptw Instructs the stack regarding how much state to retain -- this is implemented by adjusting the allocation limit on the tcptw zone. On my system, it seems to auto-tune to about 5000 connections, a value derived from the global limit on the number of sockets on the box I'm looking at -- your mileage may vary. The resource limit case can occur in tcp_twstart(), when uma_zalloc() returns NULL on failing to allocate new TIMEWAIT state for a connection. At that point, it forces an early scan of TIMEWAIT connections (which normally happens on 2msl intervals) with a 'reuse' argument of 1, authorising premature reuse. Without too close an analysis, it appears on face value to implement LRU: we reuse storage held by the connection that has been in TIMEWAIT the longest. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1109051618170.86306>