一、概述

（一）現(xiàn)象

服務(wù)器有兩個現(xiàn)象，第一是tcp連接數(shù)不多，不超過10個，但是time_wait狀態(tài)的2000。第二個按照以往的性質(zhì)，在很少用戶訪問的情況下，服務(wù)器的資源幾乎沒有使用，比如CPU，不超過5%。現(xiàn)在沒有什么用戶的的情況下，CPU損耗堅持在40%左右，夜間也不停歇。里面運行著好幾個web項目，都用docker啟動的容器分開。

（二）相關(guān)知識

tcp連接有3次握手，斷開有四次揮手。

三次握手中第一次，是主動端發(fā)出SYN信號給正在listen的被動端，然后自己變成了SYN-SENT狀態(tài)；第二次是被動端發(fā)送ACK確認收到信號和SYN信號；第三次是主動端發(fā)出ACK信號確認已經(jīng)收到了被動端的SYN。然后雙雙進入了enblished狀態(tài)，便是已經(jīng)連接成功。

四次揮手中的第一次就是主動端斷開，發(fā)送FIN信號，變成FIN-WAIT-1狀態(tài)；第二次是被動方收到FIN信號，就變成CLOSE-WAIT狀態(tài)，然后趕緊發(fā)送ACK信號給主動方確認，這是時候主動方變?yōu)镕IN-WAIT-2狀態(tài)；第三次還是被動方等自己的應(yīng)用斷開連接的時候，發(fā)送FIN信號給主動方，被動方的狀態(tài)變成LAST-ACK；第四次是主動方收到被動方的FIN信號，然后發(fā)送的ACK信號，瞬間自己變成TIME-WAIT狀態(tài)，然后等待回收。

就是說，誰有TIME-WAIT，誰就是主動方。這點可以排除用戶頻繁關(guān)閉網(wǎng)頁的可能。意思就是說這都是服務(wù)器主動請求斷開連接的，而TIME-WAIT狀態(tài)的鏈接也沒有回收。

二、問題推測

（一）網(wǎng)絡(luò)

網(wǎng)絡(luò)上面的就是網(wǎng)絡(luò)不好，或者被攻擊。

（二）應(yīng)用

中間件的參數(shù)不對，導(dǎo)致有中間件斷開的連接，或者應(yīng)用程序錯誤造成的主動斷開連接?；蛘咭彩菓?yīng)用方面導(dǎo)致消耗資源太多。

三、排查

這個服務(wù)器有三個項目，每個項目的架構(gòu)都是lanmp。問題復(fù)雜在于服務(wù)器里面好幾個項目，每個項目用都一個反向代理。好的一點是后端是docker容器，分開的。

（一）TCP連接上的IP

1．下圖是容器的IP

命令：

for i in $(docker ps|awk 'NR!=1 {print $NF}');do echo -e $i "\c";docker inspect --format '{{ .NetworkSettings.IPAddress }}' $i;done

2．下圖是連接中本地的IP

命令：

netstat -tn|grep TIME_WAIT|awk '{print $4}'|sort|uniq -c|sort -nr|head

排名第一這個是我們本地IP，6601是api項目的監(jiān)聽端口，從這里可以看出在所欲的TIME_WAIT狀態(tài)的TCP里面，API項目的后端是被請求最多的那個。估計反向代理服務(wù)器也被請求了很多。

3．下圖是連接本地API項目的主動IP

命令：

netstat -ant|grep 10.25.20.251:6601

途中可以看出，請求連接API后端的全部都是nginx的IP，這也很容易理解，nginx反向代理是入口嘛。下面就看看到底是誰對nginx發(fā)出請求。

4．下圖是連接中外地的IP

命令：netstat -tn|awk '{print $5}'|sort|uniq -c|sort -nr|head

對API的請求是600，對nginx的請求是300，說明所有的TIME-WAIT，一部分是請求nginx的，一部分是nginx請求API的。

5．下圖是展示到底是對請求了API的web前端nginx

命令：netstat -ant|grep 192.168.42.32:443

原來是192.168.42.1這個IP的請求。其實192.168.42.1這個IP是docker的虛擬網(wǎng)卡的IP，作為全部容器的網(wǎng)關(guān)，也就是說反正這就是這些容器發(fā)出的請求，但是不能確定是哪一個。

綜上所述，可以排除網(wǎng)絡(luò)問題，中間件apache的參數(shù)沒有改，但是對web前端nginx的請求那么多，可以說明問題不是出現(xiàn)在apache的請求上面。那就往代碼錯誤方面考慮。

（二）宿主機上的容器

1．應(yīng)用和網(wǎng)絡(luò)的關(guān)系

可能TIME-WAIT的問題就是后端程序亂發(fā)請求，apache是主項目的后端容器，apache-api就是api的后端程序。webserver占用的CPU上升，剛好就說明容器使用的系統(tǒng)資源就是由這種請求引起的。下面用tail看看api的access日志。

實時監(jiān)測，發(fā)現(xiàn)API一秒鐘被請求12次左右，根據(jù)業(yè)務(wù)性質(zhì)和docker的狀態(tài)顯示，可以斷定是主項目的循環(huán)請求造成的系統(tǒng)資源內(nèi)耗。而每次請求API項目就返回了access_token，API返回數(shù)據(jù)之后就發(fā)出斷開信號，邏輯和現(xiàn)象很符合，也可以斷定TIME_WAIT的狀態(tài)也是這請求引起。而TIME_WAIT不是不回收，而是回收了，但不斷的生成。

以上就是服務(wù)器中TIME_WAIT狀態(tài)過多時的排查分析的詳細內(nèi)容，更多關(guān)于服務(wù)器TIME_WAIT狀態(tài)過多排查的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論