TCP time_wait and port exhaustion for servers

Kyrian kyrian at ore.org
Thu Dec 6 15:20:09 UTC 2012


Quoting Ray Soucy <rps at maine.edu>:

>> net.ipv4.tcp_keepalive_intvl = 15
>> net.ipv4.tcp_keepalive_probes = 3
>> net.ipv4.tcp_keepalive_time = 90
>> net.ipv4.tcp_fin_timeout = 30
>
> As discussed, those do not affect TCP_TIMEWAIT_LEN.
>
> There is a lot of misinformation out there on this subject so please
> don't just Google for 5 min. and chime in with a "solution" that you
> haven't verified yourself.
>
...
>> Those tunables certainly seem to have actually worked in
>> the real world for me, whether they are right "in theory" or not is possibly
>> another matter.
>>

TLDR? They worked for me, to reduce connections in a TIME_WAIT state,  
in a real situation, after well over 5 minutes of Googling. Exactly as  
I said. Further, they differed from the (netfilter) ones posted  
previously that were stated as not having anything to do with it by  
someone or other. There's no cause at all for your snotty message back.

What you didn't state in your email was whether these connections were  
being left in TIME_WAIT because they had not been closed (eg. mobile  
devices or similar that are somewhat notorious for not closing  
connections properly), or whether the "normal" close process was  
taking too long. I suspect that if you had clarified that point  
initially, things would have made more sense all round.

The tunables listed above, AIUI handle connections that were not  
properly terminated, and idling out, whereas I believe (having had the  
opportunity to consider it in more depth) your situation seems more to  
do with "properly" terminated connections that have hard-coded  
behaviours in the kernel.

Perhaps you can clarify for the benefit of the masses.

Also, if you are going to hack the kernel to make that change, I urge  
you to make it part of the sysctl mechanism as well, and to send a  
patch back to the kernel developers to help out others who might be in  
a similar situation to you. This is both to help the community, and  
give you an easier means to tweak the setting as needed in future  
without a further kernel recompile.

K.

-- 
Kev Green, aka Kyrian. E: kyrian@ore.org WWW: http://kyrian.ore.org/
   ISP/Perl/PHP/Linux/Security Contractor, via http://www.orenet.co.uk/






More information about the NANOG mailing list