1. 程式人生 > >TCP CLOSE_WAIT過多解決方案

TCP CLOSE_WAIT過多解決方案

資源 ssh net proc 使用 基本上 for 進行 響應

就上邊原因進行分析:

一、都是開發搞的鍋

二、linux下 CLOSE_WAIT過多的解決方法

情景描述:系統產生大量“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

vim /etc/security/limits.conf

添加

xxx - nofile 8192

xxx 是一個用戶,如果是想所有用戶生效的話換成 * ,設置的數值與硬件配置有關,別設置太大了。

#<domain>     <type>   <item>       <value>
*         soft    nofile    8192 
*         hard    nofile    8192

#所有的用戶每個進程可以使用8192個文件描述符。

2.使這些限制生效

確定文件/etc/pam.d/login 和/etc/pam.d/sshd包含如下行:

session required pam_limits.so

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

  1. 在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命令使修改生效,基本上就算完成了。


修改原因:

當客戶端因為某種原因先於服務端發出了FIN信號,就會導致服務端被動關閉,若服務端不主動關閉socket發FIN給Client,此時服務端Socket會處於CLOSE_WAIT狀態(而不是LAST_ACK狀態)。通常來說,一個CLOSE_WAIT會維持至少2個小時的時間(系統默認超時時間的是7200秒,也就是2小時)。如果服務端程序因某個原因導致系統造成一堆CLOSE_WAIT消耗資源,那麽通常是等不到釋放那一刻,系統就已崩潰。因此,解決這個問題的方法還可以通過修改TCP/IP的參數來縮短這個時間,於是修改tcpkeepalive*系列參數:

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是個比較合適的值)

  1. 系統不再出現“Too many open files”報錯現象。

  2. 處於TIME_WAIT狀態的sockets不會激長。

在 Linux 上可用以下語句看了一下服務器的TCP狀態(連接狀態數量統計):

netstat -n| awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}‘

TCP CLOSE_WAIT過多解決方案