統計在一台前端機上高峰時間TCP連接的情況,統計命令:
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
結果:
除了ESTABLISHED,可以看到連接數比較多的幾個狀態是:FIN_WAIT1, TIME_WAIT, CLOSE_WAIT, SYN_RECV和LAST_ACK;下面的文章就這幾個狀態的產生條件、對系統的影響以及處理方式進行簡單描述。
發現存在大量TIME_WAIT狀態的連接
tcp 0 0 127.0.0.1:3306 127.0.0.1:41378 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:41379 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39352 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39350 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:35763 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39372 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39373 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:41176 TIME_WAIT
通過調整內核參數解決
vi /etc/sysctl.conf
編輯文件,加入以下內容:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后執行/sbin/sysctl -p讓參數生效。
net.ipv4.tcp_syncookies = 1表示開啟SYN Cookies。當出現SYN等待隊列溢出時,啟用cookies來處理,可防范少量SYN攻擊,默認為0,表示關閉;
net.ipv4.tcp_tw_reuse = 1表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接,默認為0,表示關閉;
net.ipv4.tcp_tw_recycle = 1表示開啟TCP連接中TIME-WAIT sockets的快速回收,默認為0,表示關閉。
net.ipv4.tcp_fin_timeout修改系統默認的TIMEOUT時間
修改之后,再用命令查看TIME_WAIT連接數
netstat -ae|grep “TIME_WAIT” |wc –l
發現大量的TIME_WAIT 已不存在,mysql進程的占用率很快就降下來的,網站訪問正常。
不過很多時候,出現大量的TIME_WAIT狀態的連接,往往是因為網站程序代碼中沒有使用mysql.colse(),才導致大量的mysql TIME_WAIT.
根據TCP協議定義的3次握手斷開連接規定,發起socket主動關閉的一方 socket將進入TIME_WAIT狀態,TIME_WAIT狀態將持續2個MSL(Max Segment Lifetime),在Windows下默認為4分鍾,即240秒,TIME_WAIT狀態下的socket不能被回收使用. 具體現象是對於一個處理大量短連接的服務器,如果是由服務器主動關閉客戶端的連接,將導致服務器端存在大量的處於TIME_WAIT狀態的socket, 甚至比處於Established狀態下的socket多的多,嚴重影響服務器的處理能力,甚至耗盡可用的socket,停止服務. TIME_WAIT是TCP協議用以保證被重新分配的socket不會受到之前殘留的延遲重發報文影響的機制,是必要的邏輯保證.
在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters,添加名為TcpTimedWaitDelay的
DWORD鍵,設置為60,以縮短TIME_WAIT的等待時間
http://kerry.blog.51cto.com/172631/105233/
tcp 0 0 aaaa:50417 192.168.12.13:mysql ESTABLISHED nobody 3224673
tcp 0 0 aaaa:50419 192.168.12.13:mysql ESTABLISHED nobody 3224675
發現大量的TIME_WAIT 已不存在,mysql進程的占用率很快就降下來的,各網站訪問正常!!
如果你的服務器是Windows平台,可以修改下面的注冊表鍵值:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpTimedWaitDelay"=dword:0000001e
此值是TIME_WAIT狀態的最長時間。缺省為240秒,最低為30秒,最高為300秒。建議為30秒。
注釋:
(
1,TCP結束的過程如下:
Server Client
-------------- FIN --------------> server: fin_wait_1
<------------- ACK --------------- client: close_wait server:fin_wait_2
<------------- FIN --------------- client發出fin之后就關閉
-------------- ACK -------------> server發出ack后進入time_wait狀態
Time_Wait的默認時間是2倍的MLS,就是240秒鍾。MLS是TCP片在網上的最長存活時間。
TIME_Wait的主要作用是保證關閉的TCP端口不立即被使用。因為當網絡存在延遲時,可能當某個端口被關閉后,網絡中還有一些重傳的TCP片在發向這個端口,如果這個端口立即建立新的TCP連接,則可能會有影響。所以使用2倍的MSL時間來限制這個端口立即被使用。
現在的問題在於,4分鍾的時間有點長。
因此,Time_wait的影響,我想,首先每個TCP連接都各自有個數據結構,叫TCP Control Block.Time_wait的時候這個數據結構沒有被釋放。所以當有太多的TCP連接時,內存可能會被占用很多。
2,To ValorZ:TIME_WAIT狀態也稱為2MSL等待狀態,而不是2MLS,筆誤吧!
每個TCP報文在網絡內的最長時間,就稱為MSL(Maximum Segment Lifetime),它的作用和IP數據包的TTL類似。
RFC793指出,MSL的值是2分鍾,但是在實際的實現中,常用的值有以下三種:30秒,1分鍾,2分鍾。
注意一個問題,進入TIME_WAIT狀態的一般情況下是客戶端,大多數服務器端一般執行被動關閉,不會進入TIME_WAIT狀態,當在服務器端關閉某個服務再重新啟動時,它是會進入TIME_WAIT狀態的。
舉例:
1.客戶端連接服務器的80服務,這時客戶端會啟用一個本地的端口訪問服務器的80,訪問完成后關閉此連接,立刻再次訪問服務器的80,這時客戶端會啟用另一個本地的端口,而不是剛才使用的那個本地端口。原因就是剛才的那個連接還處於TIME_WAIT狀態。
2.客戶端連接服務器的80服務,這時服務器關閉80端口,立即再次重啟80端口的服務,這時可能不會成功啟動,原因也是服務器的連接還處於TIME_WAIT狀態。
windows
描述:確定 TCP/IP 可釋放已關閉連接並重用其資源前,必須經過的時間。
http://blog.csdn.net/gzh0222/article/details/8491178