Linux服務器大量的CLOSE_WAIT、TIME_WAIT解決辦法

時間 2019-11-11

標籤 linux 服務器大量 close wait time 解決辦法欄目 Linux 简体版

原文原文鏈接

http://itindex.net/detail/50213-%E6%9C%8D%E5%8A%A1%E5%99%A8-time_wait-close_waithtml

http://itindex.net/detail/47690-time_wait-tcp-%E6%80%A7%E8%83%BDmysql

http://itindex.net/detail/50143-time_wait-socket-time_waitnginx

http://itindex.net/detail/53528-nginx-time_waitweb

http://itindex.net/detail/53493-tcp-ip-time_waitsql

系統上線以後，經過以下語句查看服務器時，發現有很多TIME_WAIT和CLOSE_WAIT。windows

netstat -an | awk '{print $6}' | sort | uniq -c | sort -rn服務器

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

打印顯示以下：cookie

TIME_WAIT 297
ESTABLISHED 53
CLOSE_WAIT 5

TIME_WAIT：表示主動關閉，經過優化系統內核參數可容易解決。網絡

CLOSE_WAIT：表示被動關閉，須要從程序自己出發。數據結構

ESTABLISHED：表示正在通訊

經過上網瞭解，總結以下：

1、TIME_WAIT（經過優化系統內核參數可容易解決）

TIME_WAIT是主動關閉鏈接的一方保持的狀態，對於服務器來講它自己就是「客戶端」，在完成一個爬取任務以後，它就會發起主動關閉鏈接，從而進入TIME_WAIT的狀態，而後在保持這個狀態2MSL（max segment lifetime）時間以後，完全關閉回收資源。爲何要這麼作？明明就已經主動關閉鏈接了爲啥還要保持資源一段時間呢？這個是TCP/IP的設計者規定的，主要出於如下兩個方面的考慮：

1.防止上一次鏈接中的包，迷路後從新出現，影響新鏈接（通過2MSL，上一次鏈接中全部的重複包都會消失）

2.可靠的關閉TCP鏈接。在主動關閉方發送的最後一個 ack(fin) ，有可能丟失，這時被動方會從新發fin, 若是這時主動方處於 CLOSED 狀態，就會響應 rst 而不是 ack。因此主動方要處於 TIME_WAIT 狀態，而不能是 CLOSED 。另外這麼設計TIME_WAIT 會定時的回收資源，並不會佔用很大資源的，除非短期內接受大量請求或者受到攻擊。

解決方案很簡單，經過修改/etc/sysctl.conf文件，服務器可以快速回收和重用那些TIME_WAIT的資源

#表示開啓SYN Cookies。當出現SYN等待隊列溢出時，啓用cookies來處理，可防範少許SYN攻擊，默認爲0，表示關閉  
net.ipv4.tcp_syncookies = 1  
#表示開啓重用。容許將TIME-WAIT sockets從新用於新的TCP鏈接，默認爲0，表示關閉  
net.ipv4.tcp_tw_reuse = 1  
#表示開啓TCP鏈接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉  
net.ipv4.tcp_tw_recycle = 1
#表示若是套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間  
net.ipv4.tcp_fin_timeout=30

生效，以下命令

/sbin/sysctl -p

2、CLOSE_WAIT（須要從程序自己出發）

TCP狀態轉移要點

TCP協議規定，對於已經創建的鏈接，網絡雙方要進行四次握手才能成功斷開鏈接，若是缺乏了其中某個步驟，將會使鏈接處於假死狀態，鏈接自己佔用的資源不會被釋放。網絡服務器程序要同時管理大量鏈接，因此頗有必要保證無用鏈接徹底斷開，不然大量僵死的鏈接會浪費許多服務器資源.

客戶端TCP狀態遷移：

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

服務器TCP狀態遷移：

CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

當客戶端開始鏈接時，服務器還處於LISTENING，客戶端發一個SYN包後，他就處於SYN_SENT狀態,服務器就處於SYS收到狀態,而後互相確認進入鏈接狀態ESTABLISHED。

TIME_WAIT狀態能夠經過優化服務器參數獲得解決，由於發生TIME_WAIT的狀況是服務器本身可控的，要麼就是對方鏈接的異常，要麼就是本身沒有迅速回收資源，總之不是因爲本身程序錯誤致使的。

可是CLOSE_WAIT就不同了，若是一直保持在CLOSE_WAIT狀態，那麼只有一種狀況，就是在對方關閉鏈接以後服務器程序本身沒有進一步發出ack信號。換句話說，就是在對方鏈接關閉以後，程序裏沒有檢測到，或者程序壓根就忘記了這個時候須要關閉鏈接，因而這個資源就一直被程序佔着。我的以爲這種狀況，經過服務器內核參數也沒辦法解決，服務器對於程序搶佔的資源沒有主動回收的權利，除非終止程序運行。

什麼狀況下，鏈接處於CLOSE_WAIT狀態呢？

答案一：在被動關閉鏈接狀況下，在已經接收到FIN，可是尚未發送本身的FIN的時刻，鏈接處於CLOSE_WAIT狀態。一般來說，CLOSE_WAIT狀態的持續時間應該很短，正如SYN_RCVD狀態。可是在一些特殊狀況下，就會出現鏈接長時間處於CLOSE_WAIT狀態的狀況。

答案二：出現大量close_wait的現象，主要緣由是某種狀況下對方關閉了socket連接，可是我方忙與讀或者寫，沒有關閉鏈接。代碼須要判斷socket，一旦讀到0，斷開鏈接，read返回負，檢查一下errno，若是不是AGAIN，就斷開鏈接。

-----------------------------------------------------------------------------------------------

http://www.cnblogs.com/sunxucool/p/3449068.html

http://my.oschina.net/foxidea/blog/91431?fromerr=KjV5Lqr3

發現存在大量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.

若是你的服務器是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

TcpTimedWaitDelay和MaxUserPort設置
描述：肯定 TCP/IP 可釋放已關閉鏈接並重用其資源前，必須通過的時間。

關閉和釋放之間的此時間間隔通稱 TIME_WAIT 狀態或兩倍最大段生命週期（2MSL）狀態。

此時間期間，從新打開到客戶機和服務器的鏈接的成本少於創建新鏈接。

減小此條目的值容許 TCP/IP 更快地釋放已關閉的鏈接，爲新鏈接提供更多資源。若是運行的應用程序須要快速釋放和建立新鏈接，並且因爲 TIME_WAIT 中存在不少鏈接，致使低吞吐量，則調整此參數。

如何查看或設置：使用 regedit 命令訪問 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters 註冊表子鍵並建立名爲 TcpTimedWaitDelay 的新 REG_DWORD 值。

將此值設置爲十進制 30，其爲十六進制 0x0000001e。

該值將等待時間設置爲 30 秒。

中止並從新啓動系統。缺省值：0xF0，它將等待時間設置爲 240 秒（4 分鐘）。

建議值：最小值爲 0x1E，它將等待時間設置爲 30 秒。

MaxUserPort 描述：肯定在應用程序從系統請求可用用戶端口時，TCP/IP 可指定的最高端口號。

如何查看或設置：使用 regedit 命令訪問 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters 註冊表子鍵並建立名爲 MaxUserPort 的新 REG_DWORD 值。

中止並從新啓動系統。

缺省值：無建議值：至少十進制 32768。

注：當在 Windows NT 或 Windows 2000 操做系統上調整 WebSphere Application Server 時，同時使用這兩個參數。

但願本站的知識能給您的工做、學習和生活帶來方便和樂趣！

--------------------------------------------------------------------------------------------------------------

server端tcp鏈接狀態大量TIME_WAIT解決方法：

在腳步中添加： /*保證迭代結束後關閉全部的連接。相應的函數放於下面兩個函數之間，迭代後都會關閉鏈接。 web_set_sockets_option("SHUTDOWN_MODE","ABRUPT");//至關於迭代重置，初始化 ............ web_set_sockets_option("CLOSE_KEEPALIVE_CONNECTIONS","1"); //關閉鏈接 */ web_set_sockets_option("SHUTDOWN_MODE","ABRUPT"); web_set_sockets_option("SO_REUSE_ADDRESS","1");//端口複用 web_set_sockets_option("OVERLAPPED_SEND","0");//禁用TTFB細分，問題便可解決，可是TTFB細分圖將不能再使用.