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後再次出現問題，這個時候我們可以確定是數據庫的鏈接池使用後沒有釋放導致的。