【经验总结】tcp_tw_recycle参数引发的故障

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连接进入无影响。

经验总结：
　　　　通过此次故障，警示我们在进行日常程序，系统等变更，修改，重启等的操作上，需要我们严格按照流程仔细去进行测试，评估修改后的风险及出现问题回退和解决方法；特别是对内核参数的修改一定要理解透彻，不能盲目修改。然后进行逐步发布，避免故障影响全局。尽量让故障率降低。