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連線進入無影響。

經驗總結：
　　　　通過此次故障，警示我們在進行日常程式，系統等變更，修改，重啟等的操作上，需要我們嚴格按照流程仔細去進行測試，評估修改後的風險及出現問題回退和解決方法；特別是對核心引數的修改一定要理解透徹，不能盲目修改。然後進行逐步釋出，避免故障影響全域性。儘量讓故障率降低。
---------------------
作者：wireless_tech
來源：CSDN
原文：https://blog.csdn.net/wireless_tech/article/details/6405755
版權宣告：本文為博主原創文章，轉載請附上博文連結！