文章轉載自：https://blog.csdn.net/wireless_tech/article/details/6405755
故障描述：
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連接的重傳數據，不是新的請求”，於是丟掉不回包，造成大量丟包。