close_wait問題的示例分析

這篇文章給大家介紹close_wait問題的示例分析，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

前言

有一次商戶反映訪問我們服務(wù)出現(xiàn)問題，很多超時現(xiàn)象，我們登陸服務(wù)器查詢問題時，發(fā)現(xiàn)-bash: fork: retry: 資源暫時不可用，并檢查了系統(tǒng)的tcp連接的情況，發(fā)現(xiàn)closewait非常多。

問題描述

現(xiàn)象有

1. 商戶連接不到我們的服務(wù)

2. xshell登陸服務(wù)器報 bash: fork: retry: 資源暫時不可用

3. 查看系統(tǒng)tcp連接情況，發(fā)現(xiàn) closewait非常多

4. 應(yīng)用進(jìn)程存活，日志正常打印。

我準(zhǔn)備從外到內(nèi)分析問題。網(wǎng)絡(luò)-》系統(tǒng)-》應(yīng)用。

1. 網(wǎng)絡(luò)

商戶訪問不到我們服務(wù)，這牽扯到的網(wǎng)絡(luò)測問題非常多。我聯(lián)系了網(wǎng)絡(luò)部同事，詢問這個時間段是否有商戶訪問我司網(wǎng)絡(luò)出現(xiàn)問題，網(wǎng)絡(luò)部確定沒有問題。

2. 系統(tǒng)

2.1 資源暫時不可用

出現(xiàn) bash: fork: retry: 資源暫時不可用。我查詢資料，結(jié)果如下：

可能是因?yàn)橘Y源限制，要么是系統(tǒng)自己的，要么是系統(tǒng)的用戶下。資源限制可用通過 ulimit -a 查看。ulimit -u 會打印最大用戶進(jìn)程數(shù)。如果超過了最大進(jìn)程數(shù)，fork不能創(chuàng)建新的進(jìn)程，就會打印上面的錯誤。也有可能是因?yàn)榻粨Q內(nèi)存資源問題。

我就使用ulimit -u查看最大用戶進(jìn)程數(shù)是1024。

2.2 tcp closewait很多

tcp closewait 是在關(guān)閉連接時，服務(wù)端的一個中間狀態(tài)。這里先介紹下tcp連接釋放。

2.2.1 tcp 釋放連接過程

tpc_close__.jpg

tpc建立連接完成，數(shù)據(jù)傳輸結(jié)束后，通信的雙方都可以釋放連接?，F(xiàn)在A和B都處于建立連接的狀態(tài)。A的應(yīng)用進(jìn)程先向其TCP發(fā)出連接釋放報文段，并停止再發(fā)送數(shù)據(jù)，主動關(guān)閉TCP連接。A把連接釋放報文段首部FIN置1，其序號seq=u，它等于前面已傳送過的數(shù)據(jù)最后一個字節(jié)的序號加1。這時A處于FIN-WAIT-1（終止等待1），等待B確認(rèn)。注意，TPC規(guī)定，fin報文即使不攜帶數(shù)據(jù)，也要消耗一個序號。

B收到連接釋放報文段后即發(fā)出確認(rèn)，而這個報文段自己的序號是v，等于B前面已經(jīng)傳送過的數(shù)據(jù)最后一個字節(jié)的序號加1，然后B就進(jìn)入CLOSE-WAIT狀態(tài)。TCP服務(wù)器進(jìn)程就應(yīng)通知高層應(yīng)用進(jìn)程，因而從A到B這個方向的連接就釋放了，這是TCP處于半關(guān)閉狀態(tài)，即A已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是B若發(fā)送數(shù)據(jù)，A仍要接收。也就是說，從B到A這個方向的連接并未關(guān)閉。這個狀態(tài)可能會持續(xù)一些時間

A收到來自B的確認(rèn)后，就進(jìn)入了FIN-WAIT-2（終止等待2），等待B發(fā)出的連接釋放報文段。

若B已經(jīng)沒有要向A發(fā)送的數(shù)據(jù)，其應(yīng)用程序就通知TCP釋放連接。這時B發(fā)出的連接釋放報文段必須使FIN=1?，F(xiàn)假設(shè)B的序號是w（在半關(guān)閉狀態(tài)B有可能發(fā)送了一些數(shù)據(jù)）。B還必須重復(fù)上次已發(fā)送過的確認(rèn)號ack=u+1。這時B就進(jìn)入LAST-ACK（最后確認(rèn)狀態(tài)），等待A的確認(rèn)。

A在收到B的連接釋放報文后段后，必須對此發(fā)出確認(rèn)。在確認(rèn)報文段中把ACK置1，確認(rèn)號ack=w+1，而自己的序號是seq=u+1（根據(jù)TCP標(biāo)準(zhǔn)，前面發(fā)送過的FIN報文段要消耗一個序號）。然后進(jìn)入TIME-WAIT（時間等待狀態(tài)）。請注意新增的TCP連接還沒有釋放掉。必須經(jīng)過時間等待計數(shù)器設(shè)置的時間2MSL后，A才進(jìn)入CLOSED狀態(tài)。時間MSL叫做最長報文段壽命，RFC793建議設(shè)為2分鐘。但這完全是從工程上考慮，對于現(xiàn)在的網(wǎng)絡(luò)，MSL=2分鐘可能太長了。因此TCP允許不同的實(shí)現(xiàn)可根據(jù)具體情況使用最小的MSL值。因此從A進(jìn)入TIME-WAIT狀態(tài)后，要經(jīng)過4分鐘才能進(jìn)入到CLOSED的狀態(tài)，才能開始建立下一個新的連接。當(dāng)A撤銷相應(yīng)的傳輸控制塊TCB后，就結(jié)束了這次TCP連接。

B只要接收到了A發(fā)出的確認(rèn)，就進(jìn)入CLOSED狀態(tài)。同樣，B在撤銷相應(yīng)的傳輸控制塊TCB后，就結(jié)束了這次TCP連接。我們注意到，B結(jié)束TCP連接的時間要比A早一些。

上述連接釋放是四次握手，但也可以看作是兩個兩次握手。

2.2.2 存在大量 close-wait的原因

CLOSE-WAIT的狀態(tài)是B已經(jīng)知道A不在向B發(fā)送數(shù)據(jù)，因此B在合適的時間段內(nèi)可以讓其應(yīng)用程序通知TCP釋放連接。那現(xiàn)在的問題是B的應(yīng)用程序?yàn)槭裁催t遲不通知TCP釋放連接，是應(yīng)用程序掛了，還是應(yīng)用程序的資源達(dá)到臨界值，不能夠做出 通知TCP釋放連接這個操作。回想到剛才提到了系統(tǒng)資源不可用，會不會是因?yàn)锽的應(yīng)用程序想通知TCP釋放連接，但是由于沒有系統(tǒng)資源，而無法執(zhí)行這個操作。

我們查看了服務(wù)器的應(yīng)用部署情況，發(fā)現(xiàn)該服務(wù)器部署很多應(yīng)用，每個應(yīng)用響應(yīng)tcp請求的線程池都是100+，在業(yè)務(wù)高峰期，很有可能達(dá)到最大用戶進(jìn)程數(shù)1024，從而引發(fā)這一系列的問題。

應(yīng)用

應(yīng)用測設(shè)置的響應(yīng)tcp請求的線程池都是100+，并且當(dāng)時服務(wù)器部署應(yīng)用很多。

解決方案

• 增大系統(tǒng)用戶進(jìn)程數(shù)限制

• 遷移部分不重要的應(yīng)用到其他服務(wù)器，降低服務(wù)器壓力

思考

1. 為什么之前沒有暴漏出來。業(yè)務(wù)高峰期，為什么會將系統(tǒng)資源吃滿。實(shí)際的系統(tǒng)吞吐量和tps是多少。是不是我們業(yè)務(wù)處理能力較之前有降低。

2. 質(zhì)量監(jiān)控體系中缺少壓測環(huán)節(jié)。

后記

隨著5g的普及，網(wǎng)絡(luò)的速度得到巨大的提升，掌握網(wǎng)絡(luò)知識已經(jīng)是必不可少的技能之一。

關(guān)于close_wait問題的示例分析就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。