web服务器异常处理及性能分析初步

这是对近期处理web服务器异常和性能的一点总结，异常和性能问题还没完全解决，很多还在探索中。。。

近期服务器经常会周期性当机（当然，访问量很大，应用服务器的负载会周期性的很高，而且降不下去，但数据库的负载不高），后台报：

java.sql.SQLException: Communication link failure: java.io.EOFException, underlying cause: null

** BEGIN NESTED EXCEPTION **

java.io.EOFException

STACKTRACE:

java.io.EOFException

        at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1394)

        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:1570)

        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1929)

        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1906)

        at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:997)

数据库异常，当时怀疑当机跟此异常有关（具体有没有关也没完全确认），经过排查，发现是某个数据库请求特别耗时，导致数据库断掉了该连接。这个跟数据库的wait_timeout的设置有关，我们设置了100s，其实这个值应该设置的小点，超过100s的请求也应该断掉，否则数据库的负载可能会很高（这个值太小会不会对数据库连接池有影响？还没深入研究）。

上面的异常通过调整wait_timeout的值应该可以调整（该值要在my.ini或my.cnf里看，通过show variables命令看到的其实是interactive_timeout值），但我们真正应该找的其实是是什么导致会有超过100s的sql请求？这个应该是应用服务器的负载高引起的。那有是什么导致应用服务器的负载周期性的高呢？目前，我们把这个问题暂时赖在了jvm的垃圾回收（gc）上了，因为gc的时候，tomcat会“stop the world”（其实也有可能是其他原因导致，比如有可能是jrockit与tomcat本身不稳定引起）。而且，从观察来看，jvm却是会占用大量的内存。到了这一步，就要看看到底是那些代码在吃这么多内存了。jrockit的jdk自带了JRockit
Management Console管理工具，很方便、实用，但开发者的license.bea 只能用1个小时的（太小气了，考虑用jprofiler5，但性能开销可能会大些）。要使用JRockit Management Console需要在服务器端设置：

-Xmanagement -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

配置比jprofiler简单很多，但注意：-Dcom.sun.management.jmxremote.port不设置的话，每次tomcat重启，它的端口就会变，这样客户端的设置也要随着变（麻烦）！-Dcom.sun.management.jmxremote.authenticate=false不设置的话，客户端连接的时候可能会报rmi的异常（当然，别忘了用下载下来的开发版的license.bea覆盖掉jre下面空的license.bea）！客户端配置方面没什么好说的，设置好远程主机跟端口就行了。

目前在服务器上也尝试了多种jvm配置（通过使用不同参数来观察gc情况，包括使用-Xgc:gencon垃圾回收机制），再通过代码方面的检测，希望能找到负载高的真正原因！