tcp_tw_recycle參數引發的故障
By Eric
故障描述：
2010年9月7日，新上線的手機遊戲論壇有部分地區用戶反應登陸游戲時出現不能登陸或登陸超時等情況，觀察用戶同時在線數量開始下降情況。
排錯過程：
一、初步檢查是否有變更導致的故障：
1、聯繫同事檢查網絡是否有問題或有對該機房網絡是否有進行過調整，反回結果是沒有變更操作。
2、檢查在這個時間點是否有進行程序發佈更新，或程序是否有作用戶限制處理，反饋只進行日誌調低的變更，但此類操作不影響用戶的正常登陸和操作。
3、檢查系統，中午11：40左右有進行了降低等待連接數的內核優化參數修改。
二、處理過程：
1、直接聯繫不能登陸的用戶，進行登陸測試，發現同一個賬號在不同地區進行登陸是正常，初步懷疑是網絡問題。
2、從用戶瞭解到，在多款遊戲中，除古墓以後，其它登陸正常.並與多位用戶進行了確認。排除網絡問題。
3、註釋掉系統內核修改的參數，使期生效，並對resin服務進行重啓等操作，繼續觀察人數還是沒有上去，同比下降了一倍。
4、進行服務遷移，將原有的三臺前端APP機器遷移至另外三臺，並進行接口調度切換。觀察人數開始上升，用戶那反饋也可以開始登陸，半小後人數上升到同比水平。故障恢復。
三、分析
當時修改系統內核參數如下：
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狀態的時間。
總結教訓：
1、初步定論在進行註釋
掉系統內核修改的參數時，使用命令sysctl
-p,使註釋的參數沒有生效，出現部分手機移動用戶登陸連接過早的釋放和重連。由於修改過後的參數執行命令：sysctl
-p之後，其新的參數值已經加載至內核，所以重啓服務器並不能改變該值的狀態。
注：重新修改回該值的初始值必須在/etc/sysctl.conf中修改 net.ipv4.tcp_tw_recycle = 0 然後再執行命令：sysctl -p之後才能生效。不能是指註釋原來的那些參數後執行sysctl -p後就能改變的。當時一直急着恢復故障，未能冷靜分析原因及未能正確修改此參數。切換機器後遊戲恢復正常。然後再查資料好好理解上面參數的含義及如何修 改。
2、最先修改該值是因爲機器負載過高，認爲可以通過修改這些參數來達到優化的效果，處理過程中因爲同一用戶在不同地區可以 登陸，認爲是網絡問題引起。另外對 net.ipv4.tcp_fin_timeout 參數值進行了增大，誤以爲可以通過增大這個值來既能使用戶登錄，也可以使機器負載不高。實際是不行的。
3、我們在一些高併發的 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