最近爆發了一個問題 , 以前一直在正常執行的應用突然無法訪問 .

不用問,這個肯定是伺服器的問題,但是這個要怎麼看呢?

1.登入伺服器,如果伺服器壓力過大,已經無法登入伺服器了,那麼只能請求DBA強制重啟了.

　　1.1. 假設能登陸伺服器,馬上檢視伺服器CPU以及記憶體或者回收等資訊,可以那麼使用以下方法收集日誌和檢視CPU,手速一定要快,比較使用者都在催,電話,微信,qq都在響..收集完了就重啟伺服器,現正常了再查原因.

　　附圖:為了大家能夠熟練敲打,照著多打吧.

2.登入之後查看回收效率以及速度:

　　1.通過 ps -ef|grep java 得到pid:如圖:

2.通過 ps -p 101040 -o etime;jstat -gcutil 101040 1000 30  

　　上面的命令意思:

　　ps -p 101040 -o etime 檢視的是應用執行時長

　　jstat -gcutil 為檢視jvm gc回收情況的命令

　　101040 為上圖的PID

　　1000為時間間隔,單位毫秒

　　30為列印的條數,不設定則一直列印

至於列印什麼東西??請看下面:

 結果中每個專案的含義可以參考官方對jstat的文件，簡單翻譯如下：(參考別人的翻譯)

- S0C: Young Generation第一個survivor space的記憶體大小 (kB).- S1C: Young Generation第二個survivor space的記憶體大小 (kB).- S0U: Young Generation第一個Survivor space當前已使用的記憶體大小 (kB).- S1U: Young Generation第二個Survivor space當前已經使用的記憶體大小 (kB).- EC: Young Generation中eden space的記憶體大小 (kB).- EU: Young Generation中Eden space當前已使用的記憶體大小 (kB).- OC: Old Generation的記憶體大小 (kB).- OU: Old Generation當前已使用的記憶體大小 (kB).- PC: Permanent Generation的記憶體大小 (kB)- PU: Permanent Generation當前已使用的記憶體大小 (kB).- YGC: 從啟動到取樣時Young Generation GC的次數- YGCT: 從啟動到取樣時Young Generation GC所用的時間 (s).- FGC: 從啟動到取樣時Old Generation GC的次數.- FGCT: 從啟動到取樣時Old Generation GC所用的時間 (s).- GCT: 從啟動到取樣時GC所用的總時間 (s).

3.上面都是檢視JVM的記憶體情況,具體表現為jvm記憶體洩露,解決方案現在有2個:

　　1.具體問題具體分析,找到記憶體洩露的瓶頸,上面所蒐集的日誌可以幫助你找到問題的根源;

　　2.短期內需要保證專案執行,那麼請將JVM的記憶體加大,1G的加到2G,2G的加到4G等...

　　　　調整方式(Tomcat為例,其他容器自行參考)

　　　　1.開啟檔案:自己的tomcat目錄/bin/catalina.sh

　　　　2.找到如下引數,並將其修改為如下:

JAVA_OPTS="-server -Xms4096m -Xmx4096m"JavaOpts裡面的server引數足夠用了,其餘多餘的引數其實沒什麼用(專案自行配置),將上面的記憶體大小調整即可,如上面為4096M=4G.

　　調整記憶體只是權宜之計,根本問題還是要找到瓶頸,對症下藥!!!

　　祝大家永無bug.