記一次單個服務將cpu佔滿的問題排查

1、發生故障

今天發現服務查詢一直卡住，就看了一下服務器：

當時就愣住了就這一個服務就把CPU佔滿了，再看了下端口號：

出現了大量的CLOSE_WAIT。看到這裏我就只有一個想法：程序代碼有問題或者是配置的問題

2、排查

爲此我先重啓了服務並加上參數用jconsole查看服務情況：
-Djava.rmi.server.hostname=xxx.xxx.xxx.xxx
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=10000
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

再打印GC日誌：
-verbose:gc
-Xloggc:/usr/app/ydjAgent/gc_log
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps

啓動參數太長了我又把它添加到環境變量裏：
vim /etc/profile

export JAVA_OPTS='-Xms1024m -Xmx4096m -Djava.rmi.server.hostname=120.0.0.1 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=10000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -verbose:gc -Xloggc:/usr/app/ydjAgent/gc_log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps'

根據jconsole概覽和GC日誌能夠看的出，是由於系統頻繁進行GC致使的：

通常狀況下，young gc頻繁是正常的，full gc若是很是頻繁，通常狀況下有問題的就是接口查詢中的集合的數據，存起來了，一直沒刪除，致使gc沒有及時回收。

而後將堆信息dump下來後用Eclipse memory analyze分析了一下，發現char[]數組和byte[]數組佔了大部份內存。

綜上分析後查明，由於業務須要統計一個月內的全部訂單中的商品以及品牌排行，由於原有表的設計的主鍵id是UUID，服務在啓動的時候只給了最大4G內存，即便是隻查詢訂單id，都佔了很大一部分空間，更別說後面查詢出來的訂單信息會佔用更大的內存空間，而由於這樣，數據庫的壓力和應用的壓力也會很大，應用一直處於FULL GC狀態，把cpu佔滿。

3、解決辦法

由於該應用和數據庫是在同一個服務器上，因此就先把應用部署到另外一個服務器上而後用nginx經過內網將請求轉發，把內存設置8G，緩解原來服務器的CPU壓力，即使如此，在數據訪問的時候仍是對數據庫形成了很大的壓力。由於我代碼寫的太爛了哈哈。。事發以後先向老闆作了彙報，老闆表示理解。。給我時間去從新設計原有的架構。。。不說了寫代碼去。。。