tcp_tw_recycle參數引起的故障

tcp_tw_recycle參數引起的故障

By Eric 

故障描述：
　　　　2010年9月7日，新上線的手機遊戲論壇有部分地區用戶反應登錄遊戲時出現不能登錄或登錄超時等狀況，觀察用戶同時在線數量開始降低狀況。

排錯過程：

　　　　1、初步檢查是否有變動致使的故障：  
　　　　　　　　一、聯繫同事檢查網絡是否有問題或有對該機房網絡是否有進行過調整，反回結果是沒有變動操做。
　　　　　　　　二、檢查在這個時間點是否有進行程序發佈更新，或程序是否有做用戶限制處理，反饋只進行日誌調低的變動，但此類操做不影響用戶的正常登錄和操做。
　　　　　　　　三、檢查系統，中午11：40左右有進行了下降等待鏈接數的內核優化參數修改。   
　　　　2、處理過程：
　　　　　　　　一、直接聯繫不能登錄的用戶，進行登錄測試，發現同一個帳號在不一樣地區進行登錄是正常，初步懷疑是網絡問題。
　　　　　　　　二、從用戶瞭解到，在多款遊戲中，除古墓之後，其它登錄正常.並與多位用戶進行了確認。排除網絡問題。 
　　　　　　　　三、註釋掉系統內核修改的參數，使期生效，並對resin服務進行重啓等操做，繼續觀察人數仍是沒有上去，同比降低了一倍。
　　　　　　　　四、進行服務遷移，將原有的三臺前端APP機器遷移至另外三臺，並進行接口調度切換。觀察人數開始上升，用戶那反饋也能夠開始登錄，半小後人數上升到同比水平。故障恢復。
　　　　3、分析
　　　　　　　　當時修改系統內核參數以下：
　　　　　　　　net.ipv4.tcp_syncookies = 1  表示開啓SYN Cookies。當出現SYN等待隊列溢出時，啓用cookies來處理，可防範少許SYN***，默認爲0，表示關閉；
　　　　　　　　net.ipv4.tcp_tw_reuse = 1    表示開啓重用。容許將TIME-WAIT sockets從新用於新的TCP鏈接，默認爲0，表示關閉；
　　　　　　　　net.ipv4.tcp_tw_recycle = 1  表示開啓TCP鏈接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉。
　　　　　　　　net.ipv4.tcp_fin_timeout = 720  表示若是套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間。

 

總結教訓：
　　　　一、初步定論在進行註釋 掉系統內核修改的參數時，使用命令sysctl -p,使註釋的參數沒有生效，出現部分手機移動用戶登錄鏈接過早的釋放和重連。因爲修改事後的參數執行命令：sysctl -p以後，其新的參數值已經加載至內核，因此重啓服務器並不能改變該值的狀態。

　　　　注：從新修改回該值的初始值必須在/etc/sysctl.conf中修改 net.ipv4.tcp_tw_recycle = 0 而後再執行命令：sysctl -p以後才能生效。不能是指註釋原來的那些參數後執行sysctl -p後就能改變的。當時一直急着恢復故障，未能冷靜分析緣由及未能正確修改此參數。切換機器後遊戲恢復正常。而後再查資料好好理解上面參數的含義及如何修 改。

　　　　二、最早修改該值是由於機器負載太高，認爲能夠經過修改這些參數來達到優化的效果，處理過程當中由於同一用戶在不一樣地區能夠 登錄，認爲是網絡問題引發。另外對 net.ipv4.tcp_fin_timeout 參數值進行了增大，誤覺得能夠經過增大這個值來既能使用戶登陸，也可使機器負載不高。實際是不行的。

　　　　三、咱們在一些高併發的 WebServer上，爲了端口可以快速回收，打開了 tcp_tw_reccycle ，而在關閉 tcp_tw_reccycle 的時候，kernal 是不會檢查對端機器的包的時間戳的；打開了 tcp_tw_reccycle 了，就會檢查時間戳，很不幸移動的cmwap發來的包的時間戳是亂跳的，因此我方的就把帶了「倒退」的時間戳的包看成是「recycle的tw鏈接的重傳 數據，不是新的請求」，因而丟掉不回包，形成大量丟包。

　　　　注：經過測試PC用opera鏈接進入無影響。

經驗總結：
　　　　經過這次故障，警示咱們在進行平常程序，系統等變動，修改，重啓等的操做 上，須要咱們嚴格按照流程仔細去進行測試，評估修改後的風險及出現問題回退和解決方法；特別是對內核參數的修改必定要理解透徹，不能盲目修改。而後進行逐 步發佈，避免故障影響全局。儘可能讓故障率下降。

轉自http://blog.csdn.net/wireless_tech/article/details/6405755