TCP CLOSE_WAIT過多解決方案
就上邊原因進行分析:
一、都是開發搞的鍋
二、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
然後使用者重新登陸一下即可生效。
- 在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是個比較合適的值)
-
系統不再出現“
Too many open files
”報錯現象。 - 處於TIME_WAIT狀態的sockets不會激長。
在 Linux 上可用以下語句看了一下伺服器的TCP狀態(連線狀態數量統計):
netstat -n| awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'