前言

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

這非常考驗工作經驗了。

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

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

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

1.OOM問題

OOM問題在生產環境中，一旦出現，一般會是非常嚴重的問題，服務可能會掛掉。

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

1.1 堆內存OOM

服務器的日志一般會打印下面的內容：

java.lang.OutOfMemoryError: Java heap space

這種是出現最多的OOM問題。

在Java服務啟動時，可以增加下面的參數：

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

在發生OOM時，程序會自動把當時的內存使用情況，dump保存到指定的文件。

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

1.2 棧內存OOM

出現棧內存OOM問題的異常信息如下：

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

如果實際工作中，出現這個問題，一般是由于創建的線程太多，或者設置的單個線程占用內存空間太大導致的。

這個時候需要排查服務的線程數量。

推薦使用線程池，可以減少線程的創建，有效控制服務中的線程數量。

1.3 棧內存溢出

出現棧內存溢出問題的異常信息如下：

java.lang.StackOverflowError

該問題一般是由于業務代碼中寫的一些遞歸調用，遞歸的深度超過了JVM允許的最大深度，可能會出現棧內存溢出問題。

如果生產環境中，出現了這個問題，可以排查一下遞歸調用是否正常，有可能出現了無限遞歸的情況。

1.4 GC OOM

出現GC OOM問題時異常信息如下：

java.lang.OutOfMemoryError: GC overhead limit exceeded

GC OOM一般是由于JVM在GC時，對象過多，導致內存溢出，建議調整GC的策略。

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

1.5 元空間OOM

出現元空間OOM問題時異常信息如下：

java.lang.OutOfMemoryError: Metaspace

JDK8之后使用Metaspace來代替永久代，Metaspace是方法區在HotSpot中的實現。

這個問題一般是由于加載到內存中的類太多，或者類的體積太大導致的。

如果生產環境中出現了這個問題，可以通過下面的命令修改元空間大小：

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

2.CPU100%問題

線上服務出現CPU100%問題，也很常見。

出現這個問題，是由于服務長時間占用CPU資源導致的。

主要原因有下面這幾種：

圖片

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

如果對CPU100%問題比較感興趣，可以看看我的另一篇文章《糟糕，CPU100%了！！！》，里面有更詳細的介紹。

3.接口超時問題

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

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

下面這張圖中給大家列舉出現了，生產環境接口突然出現超時問題時的常見原因：

圖片

如果大家想進一步了解接口超時問題，可以看看我的另一篇文章《接口突然超時10宗罪。。。》

4.索引失效問題

不知道你有沒有遇到過，生成環境明明創建了索引，但數據庫在執行SQL的過程中，索引竟然失效了。

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

我們可以通過explain關鍵字，查看sql的執行計劃，可以確認索引是否失效。

如果索引失效了，可能是哪些原因導致的問題呢？

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

圖片

想進一步了解索引失效問題的小伙伴，可以看一下我的另一篇文章《聊聊索引失效的10種場景，太坑了》，里面有非常詳細的介紹。

5.死鎖問題

如果你使用的是MySQL數據庫，在生產環境肯定遇到死鎖問題。

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

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

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

• 資源競爭：多個事務同時競爭相同的資源，比如都試圖獲取對方持有的鎖。
• 循環等待：事務之間形成了一種互相等待對方釋放資源的循環關系。
• 不當的事務設計：事務執行順序不合理、執行時間過長等。
• 并發操作沖突：在高并發環境下，多個事務對同一組數據進行操作，容易引發鎖沖突導致死鎖。
• 索引使用不當：如果索引設計不合理，可能導致事務在獲取鎖時出現問題。

如何減少死鎖問題？

• 設置合理的事務隔離級別。
• 避免大事務的業務代碼。
• 優化sql性能。
• 增加鎖等待超時處理。
• 增加監控和分析

6.磁盤問題

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

磁盤問題一般有兩種：

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

如果是磁盤壞了，運維一般在短時間內，很難及時修復好。

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

如果是磁盤空間不足。

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

df -Hl

查看當前服務器的磁盤使用情況。

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

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

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

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

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

同時需要需要規范業務系統，哪些場景需要打印日志，哪些場景不需要，不應該所有的場景，都打印日志。

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

7.MQ消息積壓問題

如果你使用過MQ消息中間件，在生產環境肯定遇到過MQ消息積壓問題。

出現這個問題，一般是MQ消費者消費消息的速度，比MQ生產者生產消息的速度慢。

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

可能是下面的原因導致的：

• MQ生產者批量發送消息。
• 隨著數據越來越多，MQ消費者的在處理業務邏輯時，mysql索引失效或者選錯索引，導致處理消息的速度變慢。

如果生產環境出現MQ消息積壓問題，先確認MQ生產者有沒有批量發送消息。

如果有，則可以把MQ消費者中線程池的核心線程數和最大線程數調大一些，讓更多的線程去處理業務邏輯，提升消費能力。

這套方案的前提是MQ消費者中，已經使用了線程池消費消息。

如果沒有使用線程池，則只能臨時增加服務器節點了。

如果MQ生產者沒有批量發送消息，則需要排查MQ消費者的業務邏輯中，哪些地方出現了性能問題，需要做代碼優化。

優化的方向是：

• 優化索引
• 優化sql語句
• 異步處理
• 批量處理

等等，還有其他的。

8.調用接口報錯

我們生產環境的程序，有時候會出現，之前調用某個API一直都是正常的，但突然出現報錯的情況，即返回碼不是200。

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

8.1 返回401

一般生產環境出現這個問題，是由于沒有通過接口的登錄認證。

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

就會出現返回碼是401的情況。

8.2 返回403

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

這種場景跟返回碼是401有區別。

401著重于認證問題，即用戶沒有提供正確的身份驗證信息。

而403則是在認證成功的基礎上，用戶沒有足夠的權限去訪問請求的資源。

要解決這個問題，我們需要給接口的調用方，分配相應的訪問權限。

8.3 返回404

不用懷疑，你請求的接口地址，現在已經不存在了，才會報404。

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

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

還有一種可能也會導致請求接口報404的問題，接口地址之前注冊到了API網關中，但API網關的配置出現了問題。

優先排查接口url是否修改，然后排查網關或者Nginx配置是否有問題。

8.4 返回405

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

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

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

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

8.5 返回500

如果請求的接口，返回碼為500，一般是出現了服務的內部錯誤。

一般網關層會對接口的返回值做一次封裝，不會返回真正的異常信息。

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

建議出現異常時，把接口請求參數打印出來，方便后面復現問題。

導致這種問題的原因有很多，我們只能根據服務器上的錯誤日志，和相關的業務代碼逐一排查。

8.6 返回502

如果請求的接口，返回碼為502，一般是出現了服務不可用的情況。

有兩種情況：

1. 服務器正在重啟中。
2. 服務掛掉了。

這時候可以查看一下服務的監控，也可以登錄到服務器上查看的運行狀態。

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

然后再根據服務器上的日志，可以定位具體的原因，比如：OOM問題導致的。

8.7 返回504

如果請求的接口，返回碼為504，一般由于網關或者接口超時導致的。

接口返回數據的耗時，大于網關設置的超時時間，就會出現這個問題。

出現這種情況，一般需要優化接口相關的代碼。