分析診斷數據庫鏈接池問題

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後再次出現問題，這個時候咱們能夠肯定是數據庫的連接池使用後沒有釋放致使的。