Latest LQ Deal: Latest LQ Deals
Go Back > Forums > Linux Forums > Linux - Server
User Name
Linux - Server This forum is for the discussion of Linux Software used in a server related context.


  Search this Thread
Old 01-22-2008, 08:19 AM   #1
LQ Newbie
Registered: Oct 2007
Posts: 8

Rep: Reputation: 0
netstat TIME_WAIT

Hi All

I understand that TIME_WAIT in netstat is the ports that are just waiting for a period of time, and that's normal to have some in there.

My question is, at what point do you know that it's too high? Is there a max connections in there somewhere, or can it just keep on going up and they are just waiting and that's fine? If there is a limit, does it matter what speed network card you have?

[root@server ~]# netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c
Thanks for the feedback!
Old 01-23-2008, 09:31 AM   #2
Registered: Aug 2005
Location: New Brunswick
Distribution: Trisquel
Posts: 70
Blog Entries: 8

Rep: Reputation: 15
that is a rather high number of TIME_WAIT sockets (if we are talking a home pc without a server). There are ways to adjust both the maximum number of connections and the length of the time wait but I think the First and most appropriate step would be to determine what was causing all the TIME_WAIT sockets. Usually these are sockets that are finished being used and just a waiting a recommended amount of time to be sure all data clears them.

things that cause high TIME_WAIT sockets can be running a busy http server, P2P software (Gnutella/Bittorrent/etc make and release tons of connection while running), etc there is a chance it could be a DoS attack but the # of sockets doesn't seem high enough for that.. it looks more like you have some app running that is just very busy on the net and one that is using a lot of short lived connections.

I'd only suggest tuning the TCP settings if you are running a server and finding that your TCP stack is bring over run but even then it'd probably be best to adjust the server rather then the TCP stack.. If you are just running a home computer you might want to see what app is responsible for the connections, netstat -tuvnap the "p" will let you see which process is causing the if you just see a - in the PID/Program column then you need to sudo netstat -tuvnap

once you have identified the offending application you can tell it to reduce the # of connection it makes, or stop running it, or whatever.

Hope this helps
Old 09-07-2010, 05:58 AM   #3
LQ Newbie
Registered: Feb 2010
Posts: 14

Rep: Reputation: 0

I read. I agree with solution, but suppose if there are many processes that offending applications then to reduce the # of connection it makes, or stop running it, or whatever. It will take too much time.

Is there any way to avoid this situation?

Last edited by Jalindar; 09-07-2010 at 06:00 AM.
Old 09-07-2010, 06:13 AM   #4
Registered: Oct 2007
Location: Prague, CZ
Distribution: RedHat / CentOS / Ubuntu / SUSE / Debian
Posts: 747

Rep: Reputation: 73
You could setup in /etc/sysctl.conf

# Network tunning
net.ipv4.tcp_fin_timeout = 35
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_intvl = 35
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

This way, you make sure the kernel will remove faster the already dead connection. I would love to give you a better explanation, but I'm not very good at it. Anyway try it out, wont do anything bad, in any case if it doesnt do the job just remove them from sysctl.conf and reboot computer.
Old 09-07-2010, 06:16 AM   #5
Registered: Oct 2007
Location: Prague, CZ
Distribution: RedHat / CentOS / Ubuntu / SUSE / Debian
Posts: 747

Rep: Reputation: 73
A better explanation:

Time to hold socket in state FIN-WAIT-2, if it was closed by our side. Peer can be broken and never close its side, or even died unexpectedly. Default value is 60sec. Usual value used in 2.2 was 180 seconds, you may restore it, but remember that if your machine is even underloaded WEB server, you risk to overflow memory with kilotons of dead sockets, FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1, because they eat maximum 1.5K of memory, but they tend to live longer. Cf. tcp_max_orphans.

How often TCP sends out keepalive messages when keepalive is enabled. Default: 2hours.

How frequent probes are retransmitted, when a probe isn't acknowledged. Default: 75 seconds.

Enable fast recycling TIME-WAIT sockets. Default value is 1. It should not be changed without advice/request of technical experts.

This allows reusing sockets in TIME_WAIT state for new connections when it is safe from protocol viewpoint. Default value is 0 (disabled). It is generally a safer alternative to tcp_tw_recycle


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
TCP Stack and Netstat: Could having lots of TIME_WAIT connection slow down the server helptonewbie Linux - Networking 7 06-20-2012 01:48 PM
decrease TIME_WAIT izghitu Linux - Networking 3 06-14-2007 10:51 PM
TIME_WAIT and CLOSE_WAIT echox Linux - Enterprise 1 09-03-2006 09:26 PM
time_wait problem gecoool Linux - Software 3 08-31-2005 01:02 AM
MSL and TCP time_wait 98steve600 Linux - General 1 03-28-2005 03:45 AM > Forums > Linux Forums > Linux - Server

All times are GMT -5. The time now is 03:39 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration