linux 大量的TIME_WAIT解決辦法

時間 2019-11-10

原文原文鏈接

統計在一臺前端機上高峯時間TCP鏈接的狀況，統計命令：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 前端

結果：mysql

除了ESTABLISHED，能夠看到鏈接數比較多的幾個狀態是：FIN_WAIT1, TIME_WAIT, CLOSE_WAIT, SYN_RECV和LAST_ACK；下面的文章就這幾個狀態的產生條件、對系統的影響以及處理方式進行簡單描述。sql

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

根據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/cookie

修改以後，再用

netstat -ae|grep mysql

tcp        0      0 aaaa:50408               192.168.12.13:mysql           ESTABLISHED nobody     3224651
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進程的佔用率很快就降下來的，各網站訪問正常！！

以上只是暫時的解決方法，最後仔細巡查發現是前天新上線的一個系統，程序代碼中沒有使用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狀態。網絡