性能调优案例

1. 性能分析案例
   1. 程序分析案例

1. 用jconse做监控，发现内存持续的不释放，波谷或者波峰呈现持续上升的趋势，并且监控tomcat日志的时候发现有outofmemory:java  heap space的错误日志，就用jmap区定位这个问题，找到了在JVM内存堆中占用最大的一个类。然后和开发沟通后，对这个方法进行修改后，再次用jconse进行监控，发现内存增长，回收波动变得比较有规律。
2. 用JDK自带的jconse做监控，发现JVM线上机器经常出现卡顿现象，JVM在一个小时内会出现一次FULL GC，怀疑是线上JVM老年代，伊甸园区设置不合理，然后看了下配置文件，并把老年代调小，新生代适当的调大。因为一般对象都是在新生代进行频繁的创建。这样设置后尽量让对象在年轻带进行回收，尽量进行YOUNG gc,减少FULL GC次数，调整后，发现FULL GC时间间隔明显增长。对用户的感知影响也变小。
   1. 中间件分析案例

   用lr做300用户的并发，在control里面看到有大量的502,503错误，这时候去查看负载机的网络情况正常，cpu,内存等各项指标均正常，查看数据库连接数也都正常，并且应用服务和数据库服务中均没有错误日志抛出。初步判断这种情况应该是tomcat没有接收到这些并发产生的请求，直接将请求摒弃，所以怀疑是不是进程，线程数设置不合理。于是开始查看tomcat配置文件中的进程，线程数，并尝试将配置文件中的线程数调大，然后再加压时，发现仍有大量的502,203错误，但是比以前稍微少点。那我想是不是进程数太小了，服务器来不及创建进程，就直接把请求摒弃掉了。于是就试着去调初始的进程数，将进程数调大后，再去加压，发现OK，不再出现502,503错误，问题得到解决。

1. 1. 数据库分析案例

      测试过程中发现数据库服务器的CPU占用经常达到100，于是用show processlist查看mysql的行为。发现大部分的sql都处于睡眠连接状态，严重消耗mysql服务器的资源。并可能导致mysql的崩溃。于是修改了数据库配置文件，将wait_timeout（睡眠连接超时时间，如果连接超时，会被mysql自然终止）值适当的调小（由原来的28800改为600s）。再观察数据库服务器CPU稍微降低到90左右，但是还是会很高。那就再用sho