标签：分析诊断数据库连接池
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后再次出现问题，这个时候我们可以确定是数据库的链接池使用后没有释放导致的。
本文出自 “sar的监控命令” 博客，请务必保留此出处http://rainbow9912.blog.51cto.com/9070528/1641679
标签：分析诊断数据库连接池
原文地址：http://rainbow9912.blog.51cto.com/9070528/1641679
