Linux服務器怎么排查：CPU飆升、接口負載劇增?后端開發必備技能

960次閱讀

沒有評論

共計 2890 個字符，預計需要花費 8 分鐘才能閱讀完成。

線上服務器 CPU 飆升，如何定位到 Java 代碼

解決這個問題的關鍵是要找到 Java 代碼的位置。下面分享一下排查思路，以 CentOS 為例，總結為 4 步。

第 1 步，使用 top 命令找到占用 CPU 高的進程。

第 2 步，使用 ps –mp 命令找到進程下占用 CPU 高的線程 ID。

第 3 步，使用 printf 命令將線程 ID 轉換成十六進制數。

第 4 步，使用 jstack 命令輸出線程運行狀態的日志信息。

下面詳細介紹每一步的操作。

第 1 步，在使用 top命令之后，可以看到一個列表，其中包含 PID（進程 ID）、USER（操作用戶）、CPU 占用率、內存占用率、TIME+（運行時間）、COMMAND（運行命令）等信息。一般默認按 CPU 占用率從上到下降序排列，如下圖所示。

我們找到 COMMAND 列是 java 的這一行，說明這個程序就是用 Java 編寫的。然后，用記事本記下這一行的 PID，也就是進程 ID。

第 2 步，使用 ps -mp 命令，輸出這個 PID 下面的線程運行情況列表，如下圖所示。

在這個列表中包含了幾個關鍵字段，比如 CPU 占用率、TID（線程 ID）、TIME（運行時間）等。在這個列表中找到 CPU 占用最高的線程，記下 TID，也就是線程 ID。

前面記下的 TID 是一個十進制數，不能直接使用，需要轉化為十六進制數。

第 3 步，使用 printf 命令 將 TID 轉換為十六進制數，如下圖所示。

這樣就得到了真正占用 CPU 過高的線程 ID。

?第 4 步，使用 jstack 命令 輸出線程的具體運行日志，如下圖所示。

jstack 有 3 個參數，第 1 個參數是前面記下的 PID，之后加上 grep，緊跟著是轉成十六進制數的 TID，最后加上 –A 和一個數字，這個數字表示輸出日志的行數，至此就可以直接打印出具體的異常信息了。

如果日志信息比較多，異常內容比較復雜，則可以把這些異常信息輸出到一個? ?txt 文件中，慢慢分析。只需要在 jstack 命令的最后追加 txt 文件名就可以了。

jstack PID | grep TID -A60 >> error_log.txt

面試點評：從這個問題來看，面試官主要考查求職者的實操能力，以及解決問題的思路。如果求職者沒有實操過，但是知道導致 CPU 飆升的原因，并說出解決思路，那么通過面試是沒問題的。

02

生產環境服務器變慢，如何診斷處理

生產環境服務器變慢主要涉及 3 個維度：CPU 利用率、磁盤 I / O 效率、內存瓶頸。

1. CPU 利用率

CPU 利用率過高或者 CPU 利用率過低，都會影響程序的處理效率。CPU 利用率過高，說明當前服務器要處理的指令比較多，當 CPU 忙不過來的時候，指令的運行效率自然就會下降，用戶的感受就是程序響應變慢了。

針對這個問題，我們可以使用 top 命令查詢當前系統中占用 CPU 過高的進程，并定位到這個進程中比較活躍的線程。再通過 jstack 命令打印當前虛擬機的線程快照，根據快照日志排查問題代碼。

如果 CPU 利用率過低，則說明程序資源使用不夠，可以增加線程數量提升程序性能。

2. 磁盤 I / O 效率

在程序運行過程中會直接或者間接涉及一些與磁盤 I / O 相關的操作，比如程序直接讀 / 寫磁盤或者程序依賴的第三方組件對磁盤進行持久化存儲，此時磁盤 I / O 效率就會對程序運行效率產生影響。

針對這種情況可以使用 iostat 命令查看，如果磁盤負載較高，可以針對性地進行優化。比如，借助緩存系統，減少磁盤 I / O 次數；用順序寫替代隨機寫入，減少尋址開銷；使用 mmap 替代 read/write，減少內存拷貝次數。另外，磁盤 I / O 效率可以通過 CPU 與負載的非線性關系體現出來。當負載增大時，系統吞吐量不能有效增大，CPU 不能線性增長，則很可能是磁盤 I / O 出現阻塞。

3. 內存瓶頸

內存作為一塊臨時存儲數據的組件，所有 CPU 運行的指令都需要從內存中去讀 / 寫。內存的合理使用可以減少應用和磁盤的 I / O 頻率，減少網絡 I / O 的頻率，極大地提升 I / O 性能。

JVM 對內存的合理分配，能夠避免頻繁的 YGC 和 FULL GC。當內存使用率較高時，可以用 dump 命令查出 JVM 堆內存，用 MAT 工具進行分析，查出大對象或者占用內存最多的對象，以及排查是否存在內存泄漏的問題。如果用 dump 命令查出的堆內存文件正常，則可以考慮是堆外內存被大量使用導致出現問題，此時需要借助操作系統的 pmap 命令查出進程的內存分配情況。如果 CPU 和內存使用率都很正常，那么就需要進一步開啟 GC 日志，分析用戶線程暫停的時間、各部分內存區域 GC 次數和時間等指標，這里可以借助 jstat 命令或可視化工具 GCEasy 等。如果問題出在 GC 上，則考慮是不是內存不足，然后根據垃圾對象的特點進行參數調優，使用更適合的垃圾收集器，用 jstack 命令分析各個線程的狀態。如果問題比較隱蔽，則考慮是否開啟 JMX，使用 visualmv 等可視化工具進行遠程監控與分析。

面試點評：這個問題涉及的知識面比較多，如果只是站在求職者的角度來分析，則可以這樣回答。如果你沒有實際解決過類似問題，則可以說一下自己的思路，只要大體思路和方向是對的，那么在遇到類似問題的時候，可以利用網絡上的資料去逐步嘗試解決。

03

線上接口負載劇增，快扛不住了，你的首選方案是什么

遇到這樣的問題，我們的第一反應應該是增加緩存。因為，增加緩存是解決系統性能問題最快速、最高效的方案，它能夠快速提升系統的線性吞吐量，效果也最為明顯。這就相當于是用空間來換取時間。曾經有人說過，緩存是解決性能問題的萬金油，哪里存在性能瓶頸，就往哪里加緩存。

但是程序都已經上線了，增加緩存還來得及嗎？因為在增加緩存時需要改代碼，所以，臨時解決方案就是增加節點。隨后，將程序緊急部署到新的節點上，在流量入口增加限流和分發。但是增加節點自然會增加成本，所以增加緩存才是最優的解決方案。

緩存的設計思想在架構設計中十分常見。比如我們每天用的操作系統，不管是 Windows、Linux，還是 Mac OS 都有系統緩存、用戶緩存。磁盤有磁盤緩存區、CPU 有 CPU 緩存區。再比如，在我們常用的經典框架中，也經常使用到緩存，Spring 有 IoC 緩存，MyBatis 有一級緩存、二級緩存。在架構設計中，可以說緩存無處不在。

因此，當并發量過高扛不住的時候，可以優先采用緩存來緩解負載壓力。比如將讀取頻繁的數據寫到緩存中，將動態頁面靜態化。在加上緩存之后，如果負載壓力依然過大，則再考慮增加限流策略，比如消息隊列；如果在增加限流后還是壓力過大，則再考慮增加服務器節點。

面試點評：這個問題考查的是求職者的臨場應變能力，有相關經驗的程序員回答這個問題并不困難。在回答這個問題的時候，可以分兩種情況：一種是臨時解決方案，就是加服務器；另一種就是增加緩存，但是涉及修改代碼，會增加程序不穩定的風險。

親愛的程序員求職者們，相信你們一定深有體會，求職面試這條路有多難走。

Java 基礎知識，多線程，并發編程，集合原理，JVM 原理……啊！別跟我提這些！面試官一下子拿著這些知識點就沖你扔過來，還有那魔幻的 Java 框架，你要是不懂 Spring 全家桶、Dubbo、Netty、MyBatis 等，就別想踏進這個行業的大門。沒錯，Java 領域可是卷得一塌糊涂啊。

正文完