玩家被踢下线原因分析

我们游戏在开心网上线之后，最高有一千多的同时在线人数，不过好景不长，有几天晚上8-10点之间，发生了所有玩家被踢下线的情况。

 

一次发生在晚上9点左右，此时人数在持续上升，突然发生玩家全部掉线，当时几个同事都在现场，查看数据库状态show processlist，发现有几百个请求正在进行中，有几张myisam表处于lock状态，试图重启数据库，不过非常缓慢，查看tomcat日志发现，玩家掉线这段时间，基本不刷什么日志了，之前我们将web应用的session过期时间设置成3分钟，这段时间内如果没有玩家访问tomcat的话，session都将过期，因此所有玩家都被踢下线了，当时重启了mysql，恢复正常，此时已经10点多，玩家继续登录的不多，因此问题没有在发生。

 

后来又过了几天，悲剧的事情继续上演，晚上8点左右服务器在线800多人的时候，所有玩家被踢下线，据运维同事反映，mysql状态正常，当时由于不在公司，没法看到当时db的状态，只能去公司分析tomcat日志，发现tomcat有10分钟左右的时间段没有刷日志，之后有大量的乐观锁异常，用jstack查看tomcat进程，发现有将近500个线程在跑，几乎达到了tomcat线程池配置的最大线程数，这种情况很不正常，我们看到其他几个服的tomcat线程在40个左右，为线程池配置的最小值，经过网上查看相关文章了解到，大量线程很容易产生死锁，而且线程间切换的开销也很大，所以初步判断，是线程死锁导致tomcat停止响应，造成了玩家被踢下线。

 

在之前服务器端spring事务配置中，将事务的timeout时间设置成了无限长，此时当db有lock被阻塞的时候，tomcat的线程一直处于占用状态，而此时玩家不断有请求发送到tomcat，使得tomcat线程数不断增长，达到线程池的最大值，之后无法再处理玩家的请求了。之后将spring事务超时时间设置成了5s，经测试没有大的异常，放到外网之后没有再产生过类似问题，也可能跟人数没有达到当时的高峰有关。

 

这种情况的发生，一部分是由于tomcat6采用servlet2的机制导致的，老的servlet采用了block io的方法实现，web 容器的线程与应用的线程一致，因此应用发生异常，会影响到tomcat的稳定性。而最新的servlet3.0，引入了异步处理，Servlet 线程不再需要一直阻塞，直到业务处理完毕才能再输出响应，最后才结束该 Servlet 线程。在接收到请求之后，Servlet 线程可以将耗时的操作委派给另一个线程来完成，自己在不生成响应的情况下返回至容器。针对业务处理较耗时的情况，这将大大减少服务器资源的占用，并且提高并发处理速度。应用部分可以自己创建线程池，灵活地处理业务请求。

 

另外部分原因是mysql瓶颈导致服务器失去响应的，是否需要有一个统一的数据服务器来管理与mysql的连接，这个值得考虑。

 

1.http://blog.csdn.net/aking21alinjuju/article/details/5583820

2.大宝,网游服务器架构设计.pptx