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