分析诊断数据库链接池问题

top -H -p pid能够查看cpu的负载，cpu的等待或阻塞状态

jmap -histo 2224 >20150411.txt,最终定位到是哪一个方法致使的内存泄漏

慢慢的cpu负载就会降下来，线程就会断了

 

yum install -y dstat

 

dstat -c:显示cpu状况

dstat -m:显示内存状况

dstat -d:显示负载状况

dstat -l:显示负载状况

dstat -n:显示网络状况

 

xxxxx 网站一直转圈

第一种状况是：负载机自己是否有瓶颈

第二种状况是：网络是否有瓶颈

第三种状况是：到应用服务器，验证应用服务器是否有cpu排队的问题

若是压力过大的话，cpu负载很高的话，就是说load average很高的话，会有大量队列在cpu这块获取不到时间片，也会排队

第四种状况是：怀疑到内存

物理内存没有关系，由于是java项目

怀疑到jvm内存这里有频繁的full gc产生，full gc的时候会暂停整个应用程序的线程，看一下full gc，jvm默认配置以下图：

老年代默认是4M，最大持久代默认是64M

用jstat-gcutil 2633 3000 5命令去看一下，发现有大量的full gc，持久代一直在99%以上

 

因而把tomcat(本虚机是tomcat1)下bin目录下的catalina.sh里的jvm参数里的老年代和最大持久代的参数改大，full gc会发生在老年代和持久代，具体改多大，参考下面的配置，去掉注释#

#JAVA_OPTS="$JAVA_OPTS  -Xms800m -Xmx800m -Xmn400m -Xss1024K-XX:PermSize=128m -XX:MaxPermSize=128"

保存并重启tomcat，而后再用jmap -heap 2633命令去看老年代和持久代的used，都在20%如下，再用jstat -gcutil 2633 3000 5命令查看full gc的次数为2次了，刷网页也不打转了

第五种状况是：看中间件线程池这里是否有排队，若是有排队的话，须要改下线程池的配置，在此进行压测，再进行验证，直至肯定是不是线程池的问题

第六种状况是：到数据库链接池这里，看是否有排队，怎么看？

网页打转，不是超时就是排队，在loadrunner场景的错误日志里看到120s time out，应该不肯定是超时致使的，第二种多是排队，那么排队的地方只有三大块

一是在cpu这里排队：

cpu的时间片是以几万分之一的那种毫秒速度进行切换，能够排除cpu这排队问题，也能够经过命令查看cpu

在Cpu(s)里看到us和sy的值有点高，这两个高只能说明cpu处理的性能不高或者负载大有间隔排队的现象，load average最后15分钟的负载也很正常， wa为0，说明没有排队，也能够经过下面的命令看cpu没有等待现象

二是在中间件线程池这排队：

配置下中间件线程池的监控，观察有没有排队，若是没有，则排除掉这种状况(本项目中证实这里没有问题)

最后一种状况是在数据库链接池这排队：

在数据库客户端输入show processlist，数下本身的IP链接过去的数据库的链接数，发现是30个(在压测的过程当中去掉红框里三个不是本身的IP，剩下的就是本身IP的链接数，33-3=30)

发如今jdbc.properties没有配置数据库属相，在

/usr/local/tomcat1/webapps/xxxx/WEB-INF/applicationContext.xml里配置，找到maxPoolSize

将30改成60，重启tomcat，再从新压一下，看看最大链接数是否是就变成60了，发现数据库最大链接数变为60,说明是程序形成的数据库链接池不释放，以下图：

应用程序连接库正常是：

a.创建数据库链接

b.执行sql语句，返回结果

c.关闭数据库链接

若是应用程序没有关闭数据库链接，最后一步就不执行，这样数据库链接就会累积的愈来愈多，直到达到最大链接数，而后就没法创建新的链接了，页面就卡住了，加载不出来了

从上看出增长链接池后，数据库show processlist，增长了60后再次出现问题，这个时候咱们能够肯定是数据库的连接池使用后没有释放致使的。