#
###问题描述:
每天上午九点多，服务器会都出现异常，停止访问的问题，服务器端直接的报错是:session is closed
###问题分析与测试:
因为我的tomcat session是存储在redis中的，所以初步分析可能是redis出问题了，于是我检查了redis运行状况，一切正常，会不会是redis内存不够呢，我查看内存情况，我没有给redis限制内存大小，所以应该也不会是这个原因，我初步排除了redis出错的可能(我还应该查询redis的并发量等状况的)；
其次，怀疑可能是因为tomcat和mysql内存冲突，我143服务器上同时部署了tomcat从和mysql主，有可能是服务器内存不够，而我之前看到过，mysql很霸道，它如果内存不够的话会杀死其他进程，夺取内存，于是，我尝试关闭了143的tomcat，只留下一个mysql，第二天，服务器还是出现了相同的问题，所以，排除内存不够的情况；
于是，推测可能是因为mysql的原因，性能没有进行调优，检查每次服务器故障的时候的内存cpu使用情况，发现内存使用率不高，但是进程cpu使用率达到了5000%以上，服务器cpu使用率达到了80%以上，于是查询相关mysql性能优化的配置方案，进行了相关配置，重启了mysql，第二天还是出现了宕机的情况。
检查mysql.log日志，发现相应的宕机时间段，出现了很多page cleaner超时的ERROR，经检查，可能还是服务器性能的原因，cpu使用量过大，有可能是服务器性能不够用了，但是配置完后还是不行，后来检查相关时间段的mysql的show full processlist，发现出现了大量的相同的复杂查询，经检查，每执行一次这种查询需要耗时0.88s左右，在processlist中出现了100多个类似查询，推测mysql受慢查询的影响而无法响应，出现了大量脏页数据，mysql服务器处理不过来了。又经检查nginx日志，发现相关时间段出现了很多访问某个动态页面的请求，动态页面中有一个排行榜榜单，用到了该动态查询，正常我们项目中这种榜单都被静态化了，所以尝试去除该动态页面中的排行榜，第二天，果然没有出现宕机的现象，所以，最终解决了这个问题。