一. 問題復(fù)現(xiàn)

　　在上一篇文章中，小編分享了以前在工作中遇到的線上業(yè)務(wù)BUG解決思路，今天我會結(jié)合自己的授信中心這個金融項目，繼續(xù)給大家分析如何對自己遇到的故障進(jìn)行定位與解決，希望本文可以對缺乏實際開發(fā)經(jīng)驗的小白有所幫助。

　　其實要想解決開發(fā)故障，通常的解決思路大致如下：

　　1.分析問題，根據(jù)理論知識+經(jīng)驗分析問題所在，并將錯誤鎖定在一定的范圍內(nèi);

　　2.通過錯誤日志，快速定位問題。線上定位問題時，主要是依靠監(jiān)控和日志。

　　比如小編遇到過這樣一個問題：

　　線上的金融項目啟動后，運(yùn)行速度越來越慢，一段時間后直接無法訪問，但此時的內(nèi)存使用率正常，而CPU使用率幾乎滿負(fù)荷。在重啟項目后，又運(yùn)行了一段時間，項目重復(fù)出現(xiàn)該問題。

　　二. 解決思路

　　對于這種線上的故障，我們該怎么解決呢?其解決思路可以按照以下幾個步驟來實現(xiàn)。

　　其實，大多數(shù)情況下，只要出問題，我們都可以利用 df(查看磁盤)、free(查看內(nèi)存)、top(查看CPU) 來個素質(zhì)三連，然后再通過jstack(Java堆棧跟蹤工具)、jmap(Java堆和方法區(qū)的詳細(xì)信息)等工具排查。這些工具的具體使用命令，大家可以自行查閱。

　　1.top命令

　　top命令或者其他監(jiān)控數(shù)據(jù)，用于查看服務(wù)器的內(nèi)存、cpu的使用情況。

　　2.jps命令

　　查看當(dāng)前java程序的進(jìn)程號，假如為：17357，

　　3.jstat命令

　　jstat -gc 17357 2000，可以查看jvm的內(nèi)存分配情況，如圖：

　　接著我們再通過查看EU和OU、YGC、FGC的變化，來調(diào)整jvm的內(nèi)存、young區(qū)(edge，s1,s2)、old區(qū)內(nèi)存大小。

　　可靠建議：

　　修改JAVA_OPTS='-Xms1024m -Xmx1024m' ，將jvm的最大、最小內(nèi)存設(shè)為系統(tǒng)內(nèi)存的3/4。根據(jù)ygc，調(diào)整young區(qū)中s與edge比例，根據(jù)fgc的頻率調(diào)整young區(qū)和old區(qū)的大小(或比例)。

　　然后通過jstack 進(jìn)程id，來查看線程的死鎖，例如： jstack -l 21733 | more，若出現(xiàn)下圖所示，則是出現(xiàn)了線程死鎖。

　　1.tomcat優(yōu)化

　　我們也可以在yml文件中tomcat的配置進(jìn)行優(yōu)化。

　　server:

　　port: 9105

　　tomcat:

　　threads:

　　處理請求的最大線程數(shù)

　　max: 350

　　最小的工作線程數(shù)

　　min-spare: 100

　　等待隊列的最大隊列長度

　　accept-count: 500

　　2.設(shè)置數(shù)據(jù)庫連接池

　　對于數(shù)據(jù)庫服務(wù)(如mysql)，dba在部署的時候，都會設(shè)置db的最大內(nèi)存和最大鏈接數(shù)，開發(fā)人員可以暫時忽略。

　　另外，數(shù)據(jù)庫連接池請盡量別用dbch、c3p0等已經(jīng)過時的連接池技術(shù)，推薦使用阿里巴巴的druid，其相關(guān)的鏈接配置，請參照其github的官網(wǎng)。

　　三. 具體解決過程

　　結(jié)合以上解決思路，接下來百澤給大家說一下我的具體解決過程。

　　1.top定位

　　由于cpu滿負(fù)荷，所以我先通過top定位到出現(xiàn)問題的線程。發(fā)現(xiàn)確實是我們的java項目所在進(jìn)程吃掉了所有的cpu資源，這時可通過jps+jstat來查看java的gc狀態(tài)，進(jìn)一步發(fā)現(xiàn)young gc幾乎是一秒一次，fullgc沒有。所以接著我又查看了jvm的設(shè)置，young內(nèi)存才設(shè)為512m，我先去掉了這個配置，而是采用默認(rèn)配置(young：old =1:2)。

　　在重啟項目之后，young gc基本到了10多秒一次，可項目運(yùn)行一段時間還是會卡死。然后我又看了下tomcat的連接池，發(fā)現(xiàn)全部都是默認(rèn)配置(默認(rèn)最大連接數(shù)為50)，故先將最大鏈接設(shè)為500，等待隊列設(shè)為1000，重啟項目，還是出現(xiàn)cpu滿負(fù)荷，系統(tǒng)卡死。

　　2.排查數(shù)據(jù)庫服務(wù)的內(nèi)存

　　接著我查看了輸出的最新日志文件，發(fā)現(xiàn)日志輸出到一個dao方法之后，在輸出響應(yīng)的sql后就卡住了。接著我通過mysql鏈接工具直接執(zhí)行，sql卻很快輸出，因此排除數(shù)據(jù)庫服務(wù)的內(nèi)存不足等硬件問題。

　　3.調(diào)整日志輸出級別

　　通過查看項目的框架，發(fā)現(xiàn)日志用的log4j(同步日志輸出)，日志輸出級別是:INFO，這會導(dǎo)致項目里面的log輸出非常多，所以我先將log的輸出級別設(shè)為warn，重新啟動項目，項目正常運(yùn)行。

　　4.優(yōu)化數(shù)據(jù)表

　　修改日志輸出級別為warn之后，運(yùn)行了一段時間發(fā)現(xiàn)系統(tǒng)又卡死了。這時還是兩個表的查詢卡死(通訊錄和通話記錄)，這兩個表的存儲量級都是上億級別的，項目原有的邏輯是這樣的，用戶上傳通訊錄，需要刪除原來的通訊錄，再批量插入。這樣一個大表頻繁的進(jìn)行刪除與批量插入，很容易導(dǎo)致IO響應(yīng)慢。第一步，我先通過建立唯一索引，利用insert ignore into來減少該表的IO操作，接著重新啟動項目，系統(tǒng)正常運(yùn)行。

　　5.添加索引

　　加好索引優(yōu)化了sql語句之后，系統(tǒng)還是偶爾會出現(xiàn)卡死狀態(tài)。這時，我通過dba搜索慢查詢，發(fā)現(xiàn)通話記錄和通訊錄表中有一個排序查詢，該sql的末尾使用了order by update_time desc，但update_time沒有添加索引，這就導(dǎo)致該表的查詢至少要2秒以上。所以我將sql改為了order by id，查詢就正常了，重啟項目，系統(tǒng)正常運(yùn)行。

　　6.解決線程死鎖

　　至此，系統(tǒng)還是偶爾出現(xiàn)卡死現(xiàn)象(cpu爆表)，只是頻率小了很多。這時我懷疑是有線程死鎖了，從而導(dǎo)致cpu爆表。我通過運(yùn)維查找linux線程，終于發(fā)現(xiàn)確實有一個線程出現(xiàn)了死鎖，里面的信息顯示是c3p0的連接池線程。我又通過查找資料，發(fā)現(xiàn)使用c3p0作為數(shù)據(jù)庫連接池，經(jīng)常會出現(xiàn)鏈接池卡死的問題，所以我趕緊將項目的連接池切換為durid，然后重啟項目，項目運(yùn)行正常。

　　7.新增服務(wù)器節(jié)點(diǎn)

　　但系統(tǒng)在進(jìn)件量較大時，依然有一定的幾率出現(xiàn)卡死現(xiàn)象，最好考慮是當(dāng)時的項目環(huán)境采用的是單機(jī)部署，所以最后協(xié)調(diào)運(yùn)維新增了兩個服務(wù)器節(jié)點(diǎn)，至此項目運(yùn)行完全正常。

　　四. 總結(jié)

　　針對線上服務(wù)器故障的解決思路和過程，小編給大家提供了以下幾個可靠建議：

　　1.系統(tǒng)框架太過于老舊時，可能會引發(fā)一系列的項目問題，所以適當(dāng)升級項目的技術(shù)是有必要的。

　　2.一些大表一定要進(jìn)行拆分，否則在高并發(fā)的環(huán)境中，數(shù)據(jù)庫的IO會遇到瓶頸。

　　3.減少一些不必要的日志輸出，日志輸出組件盡量是異步輸出的。

　　4.一些高頻率查詢的字段，盡量加上索引、組合索引，一些慢查詢的sql優(yōu)化也很重要。

　　5.服務(wù)盡量單獨(dú)部署。