close_wait問題的示例分析

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

前言

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

問題描述

現象有

1. 商戶連接不到我們的服務

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

3. 查看系統tcp連接情況，發現 closewait非常多

4. 應用進程存活，日志正常打印。

我準備從外到內分析問題。網絡-》系統-》應用。

1. 網絡

商戶訪問不到我們服務，這牽扯到的網絡測問題非常多。我聯系了網絡部同事，詢問這個時間段是否有商戶訪問我司網絡出現問題，網絡部確定沒有問題。

2. 系統

2.1 資源暫時不可用

出現 bash: fork: retry: 資源暫時不可用。我查詢資料，結果如下：

可能是因為資源限制，要么是系統自己的，要么是系統的用戶下。資源限制可用通過 ulimit -a 查看。ulimit -u 會打印最大用戶進程數。如果超過了最大進程數，fork不能創建新的進程，就會打印上面的錯誤。也有可能是因為交換內存資源問題。

我就使用ulimit -u查看最大用戶進程數是1024。

2.2 tcp closewait很多

tcp closewait 是在關閉連接時，服務端的一個中間狀態。這里先介紹下tcp連接釋放。

2.2.1 tcp 釋放連接過程

tpc_close__.jpg

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

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

A收到來自B的確認后，就進入了FIN-WAIT-2（終止等待2），等待B發出的連接釋放報文段。

若B已經沒有要向A發送的數據，其應用程序就通知TCP釋放連接。這時B發出的連接釋放報文段必須使FIN=1。現假設B的序號是w（在半關閉狀態B有可能發送了一些數據）。B還必須重復上次已發送過的確認號ack=u+1。這時B就進入LAST-ACK（最后確認狀態），等待A的確認。

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

B只要接收到了A發出的確認，就進入CLOSED狀態。同樣，B在撤銷相應的傳輸控制塊TCB后，就結束了這次TCP連接。我們注意到，B結束TCP連接的時間要比A早一些。

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

2.2.2 存在大量 close-wait的原因

CLOSE-WAIT的狀態是B已經知道A不在向B發送數據，因此B在合適的時間段內可以讓其應用程序通知TCP釋放連接。那現在的問題是B的應用程序為什么遲遲不通知TCP釋放連接，是應用程序掛了，還是應用程序的資源達到臨界值，不能夠做出 通知TCP釋放連接這個操作。回想到剛才提到了系統資源不可用，會不會是因為B的應用程序想通知TCP釋放連接，但是由于沒有系統資源，而無法執行這個操作。

我們查看了服務器的應用部署情況，發現該服務器部署很多應用，每個應用響應tcp請求的線程池都是100+，在業務高峰期，很有可能達到最大用戶進程數1024，從而引發這一系列的問題。

應用

應用測設置的響應tcp請求的線程池都是100+，并且當時服務器部署應用很多。

解決方案

• 增大系統用戶進程數限制

• 遷移部分不重要的應用到其他服務器，降低服務器壓力

思考

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

2. 質量監控體系中缺少壓測環節。

后記

隨著5g的普及，網絡的速度得到巨大的提升，掌握網絡知識已經是必不可少的技能之一。

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