檢視網路連線數： netstat -an |wc -l netstat -an |grep xx |wc -l 檢視某個/特定ip的連線數 netstat -an |grep TIME_WAIT|wc -l 檢視連線數等待time_wait狀態連線數 netstat -an |grep ESTABLISHED |wc -l 檢視建立穩定連線數量 檢視不同狀態的連線數數量 [root@cp-nginx ~]# netstat -an | awk '/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}' LISTEN 8 ESTABLISHED 2400 FIN_WAIT1 2 TIME_WAIT 6000 檢視每個ip跟伺服器建立的連線數 [root@cp-nginx ~]# netstat -nat|awk '{print$5}'|awk -F : '{print$1}'|sort|uniq -c|sort -rn 31 45.116.147.178 20 45.116.147.186 12 23.234.45.34 11 103.56.195.17 (PS：正則解析：顯示第5列，-F : 以：分割，顯示列，sort 排序，uniq -c統計排序過程中的重複行，sort -rn 按純數字進行逆序排序) 檢視每個ip建立的ESTABLISHED/TIME_OUT狀態的連線數 [root@cp-nginx ~]# netstat -nat|grep ESTABLISHED|awk '{print$5}'|awk -F : '{print$1}'|sort|uniq -c|sort -rn 24 103.56.195.17 19 45.116.147.186 18 103.56.195.18 17 45.116.147.178 問題1：解決time_wait連線數大量問題 查詢到time_wait連線數過多情況下，調整核心引數：/etc/sysctl.conf vim /etc/sysctl.conf 新增以下配置檔案： net.ipv4.tcp_syncookies = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_tw_recycle = 1net.ipv4.tcp_fin_timeout = 300 /sbin/sysctl -p 讓引數生效，調優完成 引數詳解： 1.net.ipv4.tcp_syncookies = 1 表示開啟 syn cookies 。當出現 syn 等待佇列溢位時，啟用 cookies 來處理，可防範少量 syn ***，預設為 0 ，表示關閉； 2.net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將 time-wait sockets 重新用於新的 tcp 連線，預設為 0 ，表示關閉；3.net.ipv4.tcp_tw_recycle = 1 表示開啟 tcp 連線中 time-wait sockets 的快速回收，預設為 0 ，表示關閉。4.net.ipv4.tcp_fin_timeout 修改系靳預設的 timeout 時間 如果以上配置調優後效能還不理想，可繼續修改一下配置： vi /etc/sysctl.conf net.ipv4.tcp_keepalive_time = 1200 #表示當keepalive起用的時候，TCP傳送keepalive訊息的頻度。預設是2小時，改為20分鐘。 net.ipv4.ip_local_port_range = 1024 65000 #表示用於向外連線的埠範圍。預設情況下很小：32768到61000，改為1024到65000。 net.ipv4.tcp_max_syn_backlog = 8192 #表示SYN佇列的長度，預設為1024，加大佇列長度為8192，可以容納更多等待連線的網路連線數。 net.ipv4.tcp_max_tw_buckets = 5000 #表示系統同時保持TIME_WAIT套接字的最大數量，如果超過這個數字，TIME_WAIT套接字將立刻被清除並列印警告資訊。 預設為180000，改為5000。 對於Apache、Nginx等伺服器，上幾行的引數可以很好地減少TIME_WAIT套接字數量，但是對於 Squid，效果卻不大。此項引數可以控制TIME_WAIT套接字的最大數量，避免Squid伺服器被大量的TIME_WAIT套接字拖死。 問題2：ESTABLISHED連線數過大問題 怎麼解決請求結束後依然存在大量ESTABLISHED沒有被釋放 初步推斷是tomcat伺服器回收session時出了問題，這個一般都跟伺服器的Timeout設定有聯絡。 檢視tomcat的配置檔案server.xml ***** 檢查配置得出20000毫秒的時候acceptCount=”100” ，明顯不合理，最大連線數也太小了吧。 所以進一步最佳化： connectionTimeout="20000" 改為 connectionTimeout="100" acceptCount="100"改為acceptCount="5000" 最佳化完畢，繼續壓測... 系統響應能力節節攀升，之前LoadRunner報錯問題直到壓倒***併發也再也沒有出現。 Action.c(380): 錯誤 -26608: 對於“http://www.cnlogs.com/javame”，HTTP 狀態程式碼=504 (Gateway Time-out) 昨天解決了一個HttpClient呼叫錯誤導致的伺服器異常，具體過程如下： 裡頭的分析過程有提到，透過檢視伺服器網路狀態檢測到伺服器有大量的CLOSE_WAIT的狀態。 在伺服器的日常維護過程中，會經常用到下面的命令： netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 它會顯示例如下面的資訊： TIME_WAIT 814 CLOSE_WAIT 1 FIN_WAIT1 1 ESTABLISHED 634 SYN_RECV 2 LAST_ACK 1 常用的三個狀態是：ESTABLISHED 表示正在通訊，TIME_WAIT 表示主動關閉，CLOSE_WAIT 表示被動關閉。 具體每種狀態什麼意思，其實無需多說，看看下面這種圖就明白了，注意這裡提到的伺服器應該是業務請求接受處理的一方： 這麼多狀態不用都記住，只要瞭解到我上面提到的最常見的三種狀態的意義就可以了。一般不到萬不得已的情況也不會去檢視網路狀態，如果伺服器出了異常，百分之八九十都是下面兩種情況： 1.伺服器保持了大量TIME_WAIT狀態 2.伺服器保持了大量CLOSE_WAIT狀態 因為linux分配給一個使用者的檔案控制代碼是有限的(可以參考：)，而TIME_WAIT和CLOSE_WAIT兩種狀態如果一直被保持，那麼意味著對應數目的通道就一直被佔著，而且是“佔著茅坑不使勁”，一旦達到控制代碼數上限，新的請求就無法被處理了，接著就是大量Too Many Open Files異常，tomcat崩潰。。。 下 面來討論下這兩種情況的處理方法，網上有很多資料把這兩種情況的處理方法混為一談，以為最佳化系統核心引數就可以解決問題，其實是不恰當的，最佳化系統核心參 數解決TIME_WAIT可能很容易，但是應對CLOSE_WAIT的情況還是需要從程式本身出發。現在來分別說說這兩種情況的處理方法： 1.伺服器保持了大量TIME_WAIT狀態 這種情況比較常見，一些爬蟲伺服器或者WEB伺服器(如果網管在安裝的時候沒有做核心引數最佳化的話)上經常會遇到這個問題，這個問題是怎麼產生的呢？ 從 上面的示意圖可以看得出來，TIME_WAIT是主動關閉連線的一方保持的狀態，對於爬蟲伺服器來說他本身就是“客戶端”，在完成一個爬取任務之後，他就 會發起主動關閉連線，從而進入TIME_WAIT的狀態，然後在保持這個狀態2MSL(max segment lifetime)時間之後，徹底關閉回收資源。為什麼要這麼做？明明就已經主動關閉連線了為啥還要保持資源一段時間呢？這個是TCP/IP的設計者規定 的，主要出於以下兩個方面的考慮： 1.防止上一次連線中的包，迷路後重新出現，影響新連線(經過2MSL，上一次連線中所有的重複包都會消失) 2. 可靠的關閉TCP連線。在主動關閉方傳送的最後一個 ack(fin) ，有可能丟失，這時被動方會重新發fin, 如果這時主動方處於 CLOSED 狀態 ，就會響應 rst 而不是 ack。所以主動方要處於 TIME_WAIT 狀態，而不能是 CLOSED 。另外這麼設計TIME_WAIT 會定時的回收資源，並不會佔用很大資源的，除非短時間內接受大量請求或者受到攻擊。 關於MSL引用下面一段話： MSL 為 一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間)，由 於 RFC 793 TCP 傳輸協定是在 1981 年定義的，當時的網路速度不像現在的網際網路那樣發達，你可以想像你從瀏覽器輸入網址等到第一 個 byte 出現要等 4 分鐘嗎？在現在的網路環境下幾乎不可能有這種事情發生，因此我們大可將 TIME_WAIT 狀態的續存時間大幅調低，好 讓 連線埠 (Ports) 能更快空出來給其他連線使用。 再引用網路資源的一段話： 值 得一說的是，對於基於TCP的HTTP協議，關閉TCP連線的是Server端，這樣，Server端會進入TIME_WAIT狀態，可 想而知，對於訪 問量大的Web Server，會存在大量的TIME_WAIT狀態，假如server一秒鐘接收1000個請求，那麼就會積壓 240*1000=240，000個 TIME_WAIT的記錄，維護這些狀態給Server帶來負擔。當然現代作業系統都會用快速的查詢演算法來管理這些 TIME_WAIT，所以對於新的 TCP連線請求，判斷是否hit中一個TIME_WAIT不會太費時間，但是有這麼多狀態要維護總是不好。 HTTP協議1.1版規定default行為是Keep-Alive，也就是會重用TCP連線傳輸多個 request/response，一個主要原因就是發現了這個問題。 也就是說HTTP的互動跟上面畫的那個圖是不一樣的，關閉連線的不是客戶端，而是伺服器，所以web伺服器也是會出現大量的TIME_WAIT的情況的。 現在來說如何來解決這個問題。 解決思路很簡單，就是讓伺服器能夠快速回收和重用那些TIME_WAIT的資源。 下面來看一下我們網管對/etc/sysctl.conf檔案的修改： #對於一個新建連線，核心要傳送多少個 SYN 連線請求才決定放棄,不應該大於255，預設值是5，對應於180秒左右時間 net.ipv4.tcp_syn_retries=2 #net.ipv4.tcp_synack_retries=2 #表示當keepalive起用的時候，TCP傳送keepalive訊息的頻度。預設是2小時，改為300秒 net.ipv4.tcp_keepalive_time=1200 net.ipv4.tcp_orphan_retries=3 #表示如果套接字由本端要求關閉，這個引數決定了它保持在FIN-WAIT-2狀態的時間 net.ipv4.tcp_fin_timeout=30 #表示SYN佇列的長度，預設為1024，加大佇列長度為8192，可以容納更多等待連線的網路連線數。 net.ipv4.tcp_max_syn_backlog = 4096 #表示開啟SYN Cookies。當出現SYN等待佇列溢位時，啟用cookies來處理，可防範少量SYN攻擊，預設為0，表示關閉 net.ipv4.tcp_syncookies = 1 #表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連線，預設為0，表示關閉 net.ipv4.tcp_tw_reuse = 1 #表示開啟TCP連線中TIME-WAIT sockets的快速回收，預設為0，表示關閉 net.ipv4.tcp_tw_recycle = 1 ##減少超時前的探測次數 net.ipv4.tcp_keepalive_probes=5 ##最佳化網路裝置接收佇列 net.core.netdev_max_backlog=3000 修改完之後執行/sbin/sysctl -p讓引數生效。 這裡頭主要注意到的是net.ipv4.tcp_tw_reuse net.ipv4.tcp_tw_recycle net.ipv4.tcp_fin_timeout net.ipv4.tcp_keepalive_* 這幾個引數。 net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的開啟都是為了回收處於TIME_WAIT狀態的資源。 net.ipv4.tcp_fin_timeout這個時間可以減少在異常情況下伺服器從FIN-WAIT-2轉到TIME_WAIT的時間。 net.ipv4.tcp_keepalive_*一系列引數，是用來設定伺服器檢測連線存活的相關配置。 2.伺服器保持了大量CLOSE_WAIT狀態 休息一下，喘口氣，一開始只是打算說說TIME_WAIT和CLOSE_WAIT的區別，沒想到越挖越深，這也是寫部落格總結的好處，總可以有意外的收穫。 TIME_WAIT狀態可以透過最佳化伺服器引數得到解決，因為發生TIME_WAIT的情況是伺服器自己可控的，要麼就是對方連線的異常，要麼就是自己沒有迅速回收資源，總之不是由於自己程式錯誤導致的。 但是CLOSE_WAIT就不一樣了，從上面的圖可以看出來，如果一直保持在CLOSE_WAIT狀態，那麼只有一種情況，就是在對方關閉連線之後伺服器程式自己沒有進一步發出ack訊號。換句話說，就是在對方連線關閉之後，程式裡沒有檢測到，或者程式壓根就忘記了這個時候需要關閉連線，於是這個資源就一直被程式佔著。個人覺得這種情況，透過伺服器核心引數也沒辦法解決，伺服器對於程式搶佔的資源沒有主動回收的權利，除非終止程式執行。 在那邊日誌裡頭我舉了個場景，來說明CLOSE_WAIT和TIME_WAIT的區別，這裡重新描述一下： 服 務器A是一臺爬蟲伺服器，它使用簡單的HttpClient去請求資源伺服器B上面的apache獲取檔案資源，正常情況下，如果請求成功，那麼在抓取完 資源後，伺服器A會主動發出關閉連線的請求，這個時候就是主動關閉連線，伺服器A的連線狀態我們可以看到是TIME_WAIT。如果一旦發生異常呢？假設 請求的資源伺服器B上並不存在，那麼這個時候就會由伺服器B發出關閉連線的請求，伺服器A就是被動的關閉了連線，如果伺服器A被動關閉連線之後程式設計師忘了 讓HttpClient釋放連線，那就會造成CLOSE_WAIT的狀態了。 所以如果將大量CLOSE_WAIT的解決辦法總結為一句話那就是：查程式碼。因為問題出在伺服器程式裡頭啊。 參考資料： 近期伺服器出現大量time_wait的TCP連線造成伺服器連線數過多而最終導致tomcat假死狀態。連線伺服器檢視連線數的時候提示如下。 [root@test apache-tomcat-7.0.53]# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' TIME_WAIT 14434 FIN_WAIT2 6 ESTABLISHED 133 很明顯可以看出是請求太多頻繁，主要由於後端伺服器之間是透過rest請求相互呼叫的，而java伺服器回收tcp執行緒速度比較慢，雖然已經有顯性的關閉連線了，但是實際在調 用的時候連線回收還是較慢。透過java API解決這個問題的路子就堵死了。 後來去伺服器查閱了大量資料，可以考慮透過修改linux核心的方式解決此處問題。解決方法如下： vi /etc/sysctl.conf 新增配置資訊 #表示開啟SYN Cookies。當出現SYN等待佇列溢位時，啟用cookies來處理，可防範少量SYN攻擊。預設為0，表示關閉 net.ipv4.tcp_syncookies = 1 #表示開啟重用tcp連線。允許將TIME-WAIT sockets重新用於新的TCP連線。預設為0，表示關閉 net.ipv4.tcp_tw_reuse = 1 #表示開啟TCP連線中TIME-WAIT sockets的快速回收。預設為0，表示關閉 net.ipv4.tcp_tw_recycle = 1 #表示如果套接字由本端要求關閉，這個引數決定了它保持在FIN-WAIT-2狀態的時間 net.ipv4.tcp_fin_timeout = 30 讓引數配置生效 /sbin/sysctl -p 問題完美解決： [root@test apache-tomcat-7.0.53]# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' TIME_WAIT 96 FIN_WAIT2 3 ESTABLISHED 141