前言

最近經(jīng)常有小伙伴問我，遇到了線上問題要如何快速排查。

這非?？简?yàn)工作經(jīng)驗(yàn)了。

有些問題你以前遇到，如果再遇到類似的問題，就能很快排查出導(dǎo)致問題的原因。

但如果某個問題你是第一次遇到，心中可能會有點(diǎn)無從下手的感覺。

這篇文章總結(jié)了，我之前遇到過的一些線上問題排查思路，希望對你會有所幫助。

1.OOM問題

OOM問題在生產(chǎn)環(huán)境中，一旦出現(xiàn)，一般會是非常嚴(yán)重的問題，服務(wù)可能會掛掉。

但是OOM問題有多種情況，不同的情況，出現(xiàn)問題的原因不一樣。

（1）堆內(nèi)存OOM

服務(wù)器的日志一般會打印下面的內(nèi)容：

java.lang.OutOfMemoryError: Java heap space

這種是出現(xiàn)最多的OOM問題。

在Java服務(wù)啟動時，可以增加下面的參數(shù)：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heapdump.hprof

在發(fā)生OOM時，程序會自動把當(dāng)時的內(nèi)存使用情況，dump保存到指定的文件。

然后使用MAT（Memory Analyzer Tool），或者使用JDK自帶的 Java visualvm，來分析dump 文件，找出導(dǎo)致OOM 的代碼 。

（2）棧內(nèi)存OOM

出現(xiàn)棧內(nèi)存OOM問題的異常信息如下：

java.lang.OutOfMemoryError: unable to create new native thread

如果實(shí)際工作中，出現(xiàn)這個問題，一般是由于創(chuàng)建的線程太多，或者設(shè)置的單個線程占用內(nèi)存空間太大導(dǎo)致的。

這個時候需要排查服務(wù)的線程數(shù)量。

推薦使用線程池，可以減少線程的創(chuàng)建，有效控制服務(wù)中的線程數(shù)量。

（3）棧內(nèi)存溢出

出現(xiàn)棧內(nèi)存溢出問題的異常信息如下：

java.lang.StackOverflowError

該問題一般是由于業(yè)務(wù)代碼中寫的一些遞歸調(diào)用，遞歸的深度超過了JVM允許的最大深度，可能會出現(xiàn)棧內(nèi)存溢出問題。

如果生產(chǎn)環(huán)境中，出現(xiàn)了這個問題，可以排查一下遞歸調(diào)用是否正常，有可能出現(xiàn)了無限遞歸的情況。

（4）GC OOM

出現(xiàn)GC OOM問題時異常信息如下：

java.lang.OutOfMemoryError: GC overhead limit exceeded

GC OOM一般是由于JVM在GC時，對象過多，導(dǎo)致內(nèi)存溢出，建議調(diào)整GC的策略。

在老代80%時就是開始GC，并且將-XX:SurvivorRatio（-XX:SurvivorRatio=8）和-XX:NewRatio（-XX:NewRatio=4）設(shè)置的更合理。

（5）元空間OOM

出現(xiàn)元空間OOM問題時異常信息如下：

java.lang.OutOfMemoryError: Metaspace

JDK8之后使用Metaspace來代替永久代，Metaspace是方法區(qū)在HotSpot中的實(shí)現(xiàn)。

這個問題一般是由于加載到內(nèi)存中的類太多，或者類的體積太大導(dǎo)致的。

如果生產(chǎn)環(huán)境中出現(xiàn)了這個問題，可以通過下面的命令修改元空間大?。?/p>

-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m

我在這里列舉了OOM問題的最常見的情況。

2.CPU100%問題

線上服務(wù)出現(xiàn)CPU100%問題，也很常見。

出現(xiàn)這個問題，是由于服務(wù)長時間占用CPU資源導(dǎo)致的。

主要原因有下面這幾種：

定位這個問題，可以使用JDK自帶的jstack工具，或者用阿里開源的Arthas探測工具。

3.接口超時問題

不知道你有沒有遇到過這樣的場景：我們提供的某個API接口，響應(yīng)時間原本一直都很快，但在某個不經(jīng)意的時間點(diǎn)，突然出現(xiàn)了接口超時。

導(dǎo)致接口超時的原因有很多，我們需要挨個逐一排查。

下面這張圖中給大家列舉出現(xiàn)了，生產(chǎn)環(huán)境接口突然出現(xiàn)超時問題時的常見原因：

4.索引失效問題

不知道你有沒有遇到過，生成環(huán)境明明創(chuàng)建了索引，但數(shù)據(jù)庫在執(zhí)行SQL的過程中，索引竟然失效了。

由于索引失效，讓之前原本很快的操作，一下子變得很慢，影響了接口的性能。

我們可以通過explain關(guān)鍵字，查看sql的執(zhí)行計(jì)劃，可以確認(rèn)索引是否失效。

如果索引失效了，可能是哪些原因?qū)е碌膯栴}呢？

下面這張圖給大家列舉了常見原因：

5.死鎖問題

如果你使用的是MySQL數(shù)據(jù)庫，在生產(chǎn)環(huán)境肯定遇到死鎖問題。

死鎖是指兩個或多個事務(wù)在執(zhí)行過程中，因爭奪資源而造成的一種互相等待的現(xiàn)象，若無外力作用，這些事務(wù)將無法繼續(xù)向前推進(jìn)。

在Java中，使用MySQL數(shù)據(jù)庫時，如果遇到MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction異常，意味著數(shù)據(jù)庫檢測到了死鎖。

MySQL死鎖通常由以下原因造成：

• 資源競爭：多個事務(wù)同時競爭相同的資源，比如都試圖獲取對方持有的鎖。
• 循環(huán)等待：事務(wù)之間形成了一種互相等待對方釋放資源的循環(huán)關(guān)系。
• 不當(dāng)?shù)氖聞?wù)設(shè)計(jì)：事務(wù)執(zhí)行順序不合理、執(zhí)行時間過長等。
• 并發(fā)操作沖突：在高并發(fā)環(huán)境下，多個事務(wù)對同一組數(shù)據(jù)進(jìn)行操作，容易引發(fā)鎖沖突導(dǎo)致死鎖。
• 索引使用不當(dāng)：如果索引設(shè)計(jì)不合理，可能導(dǎo)致事務(wù)在獲取鎖時出現(xiàn)問題。

如何減少死鎖問題？

• 設(shè)置合理的事務(wù)隔離級別。
• 避免大事務(wù)的業(yè)務(wù)代碼。
• 優(yōu)化sql性能。
• 增加鎖等待超時處理。
• 增加監(jiān)控和分析

6.磁盤問題

服務(wù)器磁盤問題是眾多線上問題中，最好排查的了。

磁盤問題一般有兩種：

• 磁盤壞了
• 磁盤空間不足

如果是磁盤壞了，運(yùn)維一般在短時間內(nèi)，很難及時修復(fù)好。

因此，需要及時更換磁盤。

如果是磁盤空間不足。

一般需要登錄到那臺服務(wù)器， 使用命令：

df -Hl

查看當(dāng)前服務(wù)器的磁盤使用情況。

• 總大小
• 已使用多少
• 可用多少

最快的解決辦法是，將/tmp文件夾中的文件刪除，可以釋放一些磁盤空間。

然后找到日志文件，刪除7天以前的日志。

這兩種方式，一般會釋放不少磁盤空間，暫時解決磁盤空間不足的問題。

從常用來看，我們需要對服務(wù)器的磁盤使用情況做監(jiān)控，如果超過閥值有預(yù)警。

同時需要需要規(guī)范業(yè)務(wù)系統(tǒng)，哪些場景需要打印日志，哪些場景不需要，不應(yīng)該所有的場景，都打印日志。

特別是有些業(yè)務(wù)查詢接口調(diào)用非常頻繁，一次性返回的數(shù)據(jù)很多，這種情況下，會導(dǎo)致服務(wù)器上的日志迅速膨脹，占用過多的磁盤空間。

7.MQ消息積壓問題

如果你使用過MQ消息中間件，在生產(chǎn)環(huán)境肯定遇到過MQ消息積壓問題。

出現(xiàn)這個問題，一般是MQ消費(fèi)者消費(fèi)消息的速度，比MQ生產(chǎn)者生產(chǎn)消息的速度慢。

如果之前一直都是好好的，突然有一天出現(xiàn)了MQ消息積壓問題。

可能是下面的原因?qū)е碌模?/p>

• MQ生產(chǎn)者批量發(fā)送消息。
• 隨著數(shù)據(jù)越來越多，MQ消費(fèi)者的在處理業(yè)務(wù)邏輯時，mysql索引失效或者選錯索引，導(dǎo)致處理消息的速度變慢。

如果生產(chǎn)環(huán)境出現(xiàn)MQ消息積壓問題，先確認(rèn)MQ生產(chǎn)者有沒有批量發(fā)送消息。

如果有，則可以把MQ消費(fèi)者中線程池的核心線程數(shù)和最大線程數(shù)調(diào)大一些，讓更多的線程去處理業(yè)務(wù)邏輯，提升消費(fèi)能力。

這套方案的前提是MQ消費(fèi)者中，已經(jīng)使用了線程池消費(fèi)消息。

如果沒有使用線程池，則只能臨時增加服務(wù)器節(jié)點(diǎn)了。

如果MQ生產(chǎn)者沒有批量發(fā)送消息，則需要排查MQ消費(fèi)者的業(yè)務(wù)邏輯中，哪些地方出現(xiàn)了性能問題，需要做代碼優(yōu)化。

優(yōu)化的方向是：

• 優(yōu)化索引
• 優(yōu)化sql語句
• 異步處理
• 批量處理

等等，還有其他的。

8.調(diào)用接口報錯

我們生產(chǎn)環(huán)境的程序，有時候會出現(xiàn)，之前調(diào)用某個API一直都是正常的，但突然出現(xiàn)報錯的情況，即返回碼不是200。

那么，這種問題，我們該如何排查呢？

（1）返回401

一般生產(chǎn)環(huán)境出現(xiàn)這個問題，是由于沒有通過接口的登錄認(rèn)證。

出現(xiàn)這種情況，一般用戶在嘗試訪問受保護(hù)的資源前，需要通過某種形式的身份驗(yàn)證（如登錄），但如果未能正確提供必要的認(rèn)證信息，如Token、用戶名和密碼等。

就會出現(xiàn)返回碼是401的情況。

（2）返回403

如果生產(chǎn)環(huán)境請求某個接口，返回碼是403，則說明目前沒有訪問資源的權(quán)限。

這種場景跟返回碼是401有區(qū)別。

401著重于認(rèn)證問題，即用戶沒有提供正確的身份驗(yàn)證信息。

而403則是在認(rèn)證成功的基礎(chǔ)上，用戶沒有足夠的權(quán)限去訪問請求的資源。

要解決這個問題，我們需要給接口的調(diào)用方，分配相應(yīng)的訪問權(quán)限。

（3）返回404

不用懷疑，你請求的接口地址，現(xiàn)在已經(jīng)不存在了，才會報404。

比如有些接口名稱改了，或者接口路徑中/v1/user/query改成了/v2/user/query，版本號升級了。

如果沒有通知所有的接口調(diào)用方，都可能會出現(xiàn)請求接口返回碼為404的情況。

還有一種可能也會導(dǎo)致請求接口報404的問題，接口地址之前注冊到了API網(wǎng)關(guān)中，但API網(wǎng)關(guān)的配置出現(xiàn)了問題。

優(yōu)先排查接口url是否修改，然后排查網(wǎng)關(guān)或者Nginx配置是否有問題。

（4）返回405

如果請求的接口，返回碼為405，一般是請求方式錯誤導(dǎo)致的。

最常見的是：接口只支持post方式，但發(fā)送的卻是get請求。

或者接口只支持get方式，但發(fā)送的卻是post請求。

這種問題一般非常好排查和解決。

（5）返回500

如果請求的接口，返回碼為500，一般是出現(xiàn)了服務(wù)的內(nèi)部錯誤。

一般網(wǎng)關(guān)層會對接口的返回值做一次封裝，不會返回真正的異常信息。

我們只能查看接口的錯誤日志，來定位和排查問題。

建議出現(xiàn)異常時，把接口請求參數(shù)打印出來，方便后面復(fù)現(xiàn)問題。

導(dǎo)致這種問題的原因有很多，我們只能根據(jù)服務(wù)器上的錯誤日志，和相關(guān)的業(yè)務(wù)代碼逐一排查。

（6）返回502

如果請求的接口，返回碼為502，一般是出現(xiàn)了服務(wù)不可用的情況。

有兩種情況：

• 服務(wù)器正在重啟中。
• 服務(wù)掛掉了。

這時候可以查看一下服務(wù)的監(jiān)控，也可以登錄到服務(wù)器上查看的運(yùn)行狀態(tài)。

大部分情況下，重啟一下服務(wù)，可以快速解決問題。

然后再根據(jù)服務(wù)器上的日志，可以定位具體的原因，比如：OOM問題導(dǎo)致的。

（7）返回504

如果請求的接口，返回碼為504，一般由于網(wǎng)關(guān)或者接口超時導(dǎo)致的。

接口返回數(shù)據(jù)的耗時，大于網(wǎng)關(guān)設(shè)置的超時時間，就會出現(xiàn)這個問題。

出現(xiàn)這種情況，一般需要優(yōu)化接口相關(guān)的代碼。