TCP time_wait and port exhaustion for servers
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.
Kev Green, aka Kyrian. E: firstname.lastname@example.org WWW: http://kyrian.ore.org/
ISP/Perl/PHP/Linux/Security Contractor, via http://www.orenet.co.uk/
More information about the NANOG