LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices



Reply
 
Search this Thread
Old 01-22-2008, 09:19 AM   #1
xxclixxx
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?

Quote:
[root@server ~]# netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c
6 CLOSING
134 ESTABLISHED
12 FIN_WAIT1
15 FIN_WAIT2
6 LAST_ACK
37 LISTEN
7 SYN_RECV
1915 TIME_WAIT
Thanks for the feedback!
 
Old 01-23-2008, 10:31 AM   #2
Freemor
Member
 
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
Freemor
 
Old 09-07-2010, 06:58 AM   #3
Jalindar
LQ Newbie
 
Registered: Feb 2010
Posts: 14

Rep: Reputation: 0
Greetings!!!

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 07:00 AM.
 
Old 09-07-2010, 07:13 AM   #4
robertjinx
Member
 
Registered: Oct 2007
Location: Prague, CZ
Distribution: RedHat / CentOS / Ubuntu / SUSE / Debian
Posts: 587

Rep: Reputation: 58
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, 07:16 AM   #5
robertjinx
Member
 
Registered: Oct 2007
Location: Prague, CZ
Distribution: RedHat / CentOS / Ubuntu / SUSE / Debian
Posts: 587

Rep: Reputation: 58
A better explanation:

/proc/sys/net/ipv4/tcp_fin_timeout
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.

/proc/sys/net/ipv4/tcp_keepalive_time
How often TCP sends out keepalive messages when keepalive is enabled. Default: 2hours.

/proc/sys/net/ipv4/tcp_keepalive_intvl
How frequent probes are retransmitted, when a probe isn't acknowledged. Default: 75 seconds.

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

/proc/sys/net/ipv4/tcp_tw_reuse
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
 
  


Reply


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 02:48 PM
decrease TIME_WAIT izghitu Linux - Networking 3 06-14-2007 11:51 PM
TIME_WAIT and CLOSE_WAIT echox Linux - Enterprise 1 09-03-2006 10:26 PM
time_wait problem gecoool Linux - Software 3 08-31-2005 02:02 AM
MSL and TCP time_wait 98steve600 Linux - General 1 03-28-2005 04:45 AM


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

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