Linux下CLOSE WAIT過多分析與解決

2021-10-06 15:11:01 字數 3577 閱讀 1565

檢視鏈結狀態

netstat -ant|


awk'/^tcp/  end '
情景描述：系統產生大量「too many open files」

原因分析：在伺服器與客戶端通訊過程中，因伺服器發生了socket未關導致的closed_wait發生，致使監聽port開啟的控制代碼數到了1024個，且均處於close_wait的狀態，最終造成配置的port被佔滿出現「too many open files」，無法再進行通訊。

close_wait狀態出現的原因是被動關閉方未關閉socket造成，如附件圖所示：

解決辦法：有兩種措施可行

一、解決：

原因是因為呼叫serversocket類的accept()方法和socket輸入流的read()方法時會引起執行緒阻塞，所以應該用setsotimeout()方法設定超時（預設的設定是0，即超時永遠不會發生）；超時的判斷是累計式的，一次設定後，每次呼叫引起的阻塞時間都從該值中扣除，直至另一次超時設定或有超時異常丟擲。

比如，某種服務需要三次呼叫read()，超時設定為1分鐘，那麼如果某次服務三次read()呼叫的總時間超過1分鐘就會有異常丟擲，如果要在同乙個socket上反覆進行這種服務，就要在每次服務之前設定一次超時。

二、規避：

調整系統引數，包括控制代碼相關引數和tcp/ip的引數；

注意：/proc/sys/fs/file-max 是整個系統可以開啟的檔案數的限制，由sysctl.conf控制；

ulimit修改的是當前shell和它的子程序可以開啟的檔案數的限制，由limits.conf控制；

lsof是列出系統所占用的資源,但是這些資源不一定會占用開啟檔案號的；比如：共享記憶體,訊號量,訊息佇列,記憶體對映等,雖然占用了這些資源,但不占用開啟檔案號；

因此，需要調整的是當前使用者的子程序開啟的檔案數的限制，即limits.conf檔案的配置；

如果cat /proc/sys/fs/file-max值為65536或甚至更大，不需要修改該值；

若ulimit -a ；其open files引數的值小於4096（預設是1024), 則採用如下方法修改open files引數值為8192；方法如下：

1.使用root登陸，修改檔案/etc/security/limits.conf

vi /etc/security/limits.conf 新增

*** - nofile 8192

*** 是乙個使用者，如果是想所有使用者生效的話換成 * ，設定的數值與硬體配置有關，別設定太大了。

#


*         soft    nofile    8192 


*         hard    nofile    8192
#所有的使用者每個程序可以使用8192個檔案描述符。

2.使這些限制生效

確定檔案/etc/pam.d/login 和/etc/pam.d/sshd包含如下行：

session required pam_limits.so

然後使用者重新登陸一下即可生效。

3. 在bash下可以使用ulimit -a 參看是否已經修改：

一、 修改方法：（暫時生效,重新啟動伺服器後,會還原成預設值）

sysctl -w net.ipv4.tcp_keepalive_time=600   


sysctl -w net.ipv4.tcp_keepalive_probes=2 


sysctl -w net.ipv4.tcp_keepalive_intvl=2
注意：linux的核心引數調整的是否合理要注意觀察，看業務高峰時候效果如何。

二、 若做如上修改後，可起作用；則做如下修改以便永久生效。

vi /etc/sysctl.conf

若配置檔案中不存在如下資訊，則新增：

net.ipv4.tcp_keepalive_time = 1800 


net.ipv4.tcp_keepalive_probes = 3 


net.ipv4.tcp_keepalive_intvl = 15
編輯完 /etc/sysctl.conf,要重啟network 才會生效

/etc/rc.d/init.d/network restart
然後，執行sysctl命令使修改生效，基本上就算完成了。

/sbin/sysctl -p
修改原因：

當客戶端因為某種原因先於服務端發出了fin訊號，就會導致服務端被動關閉，若服務端不主動關閉socket發fin給client，此時服務端socket會處於close_wait狀態（而不是last_ack狀態）。通常來說，乙個close_wait會維持至少2個小時的時間（系統預設超時時間的是7200秒，也就是2小時）。如果服務端程式因某個原因導致系統造成一堆close_wait消耗資源，那麼通常是等不到釋放那一刻，系統就已崩潰。因此，解決這個問題的方法還可以通過修改tcp/ip的引數來縮短這個時間，於是修改tcp_keepalive_*系列引數：

tcp_keepalive_time：

/proc/sys/net/ipv4/tcp_keepalive_time 


integer，預設值是7200(2小時)
當keepalive開啟的情況下，tcp傳送keepalive訊息的頻率。建議修改值為1800秒。

tcp_keepalive_probes：integer 


/proc/sys/net/ipv4/tcp_keepalive_probes 


integer，預設值是9
tcp傳送keepalive探測以確定該連線已經斷開的次數。(注意:保持連線僅在so_keepalive套接字選項被開啟是才傳送.次數預設不需要修改,當然根據情形也可以適當地縮短此值.設定為5比較合適)

tcp_keepalive_intvl：integer 


/proc/sys/net/ipv4/tcp_keepalive_intvl 


integer，預設值為75
當探測沒有確認時，重新傳送探測的頻度。探測訊息傳送的頻率（在認定連線失效之前，傳送多少個tcp的keepalive探測包）。乘以tcp_keepalive_probes就得到對於從開始探測以來沒有響應的連線殺除的時間。預設值為75秒，也就是沒有活動的連線將在大約11分鐘以後將被丟棄。(對於普通應用來說,這個值有一些偏大,可以根據需要改小.特別是web類伺服器需要改小該值,15是個比較合適的值)

【檢測辦法】

系統不再出現「too many open files」報錯現象。

處於time_wait狀態的sockets不會激長。

在 linux 上可用以下語句看了一下伺服器的tcp狀態(連線狀態數量統計)：

netstat -n |


awk'/^tcp/  end '
返回結果範例如下：

established 1423 


fin_wait1 1 


fin_wait2 262 


syn_sent 1 


time_wait 962

CLOSE WAIT生成原因

起初每個socket都是closed狀態，當客戶端初使化乙個連線，他傳送乙個syn包到伺服器，客戶端進入syn sent狀態。伺服器接收到syn包，反饋乙個syn ack包，客戶端接收後返饋乙個ack包客戶端變成established狀態，如果長時間沒收到syn ack包，客戶端超時進入closed...

解決CLOSE WAIT 問題

最近web伺服器在大流量情況下經常出現假死現象，後台log報 too many open files 的錯誤，加大linux系統的檔案開啟數是可以解決部分問題，但是時間長了同樣出問題，通過查詢網路連線發現是tcp連線不關閉造成的。如下 netstat n awk tcp end last ack 1...

close wait生成的原因

close wait狀態的生成原因 首先我們知道，如果我們的client程式處於close wait狀態的話，說明套接字是被動關閉的！因為如果是server端主動斷掉當前連線的話，那麼雙方關閉這個tcp連線共需要四個packet server fin client server ack client...