【Java面試】生產環境服務器變慢，如何診斷處理？

• 2022 年 8 月 4 日
• 筆記

「生產環境服務器變慢？如何診斷處理」

這是最近一些工作5年以上的粉絲反饋給我的問題，他們去一線大廠面試，都被問到了這一類的問題。

今天給大家分享一下，面試過程中遇到這個問題，我們應該怎麼回答。

這個問題高手部分的回答，我整理到了一個10W字的文檔裏面，大家可以在我的主頁加V領取。

來看看高手的回答。

高手：

生產環境服務器處理效率變慢，我認為主要會涉及到三個緯度：

• CPU的利用率
• 磁盤IO效率
• 內存

CPU利用率過高或者CPU利用率過低，都會影響程序的處理效率。

利用率過高，說明當前服務器要處理的指令比較多，當CPU忙不過來的時候，指令的運算效率自然就會下降。

反饋在用戶上的感受就是程序響應變慢了。

針對這個問題，我們可以使用top命令查詢當前系統中佔用CPU過高的進程，以及定位到這個進程中比較活躍的線程。

再通過jstack命令打印當前虛擬機的線程快照，然後根據快照日誌排查問題代碼。

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

程序運算過程中，會直接或者間接涉及到一些磁盤IO相關的操作，比如程序直接讀寫磁盤，

或者程序依賴的第三方組件涉及到磁盤的持久化存儲，所以磁盤的IO效率也會對程序運行效率產生影響。

針對這個情況，可以使用iostat命令查看，如果磁盤負載較高，可以針對性的進行優化，比如

• 藉助緩存系統，減少磁盤IO次數
• 用順序寫替代隨機寫入，減少尋址開銷
• 使用mmap替代read/write，減少內存拷貝次數

另外，系統IO的瓶頸可以通過CPU和負載的非線性關係體現出來。當負載增大時，系統吞吐量不能有效增大，

CPU不能線性增長，其中一種可能是IO出現阻塞。

最後，就是內存的瓶頸，內存作為一塊臨時存儲數據的組件，所有CPU運算的指令都需要從內存中去讀寫。

內存的合理使用，可以減少應用和磁盤的直接IO頻率，以及減少網絡IO的頻率，極大提升IO性能。

其次，作為Java應用程序的運行平台JVM，對於內存的合理分配，能夠避免頻繁的YGC和FULL GC。

內存使用率比較高的時候， 可以 dump 出 JVM 堆內存，然後藉助 MAT 工具進行分析，

查出大對象或者佔用最多的對象，以及排查是否存在內存泄漏的問題。

如果 dump 出的堆內存文件正常，此時可以考慮堆外內存被大量使用導致出現問題，

需要藉助操作系統指令 pmap 查出進程的內存分配情況。

如果 CPU 和 內存使用率都很正常，那就需要進一步開啟 GC 日誌，分析用戶線程暫停的時間、

各部分內存區域 GC 次數和時間等指標，可以藉助 jstat 或可視化工具 GCeasy 等，

如果問題出在 GC 上面的話，考慮是否是內存不夠、根據垃圾對象的特點進行參數調優、使用更適合的垃圾收集器；

分析 jstack 出來的各個線程狀態。如果問題實在比較隱蔽，考慮是否可以開啟 jmx，使用 visualmv 等可視化工具遠程監控與分析。

總結

這個問題涉及到的知識面比較多，站在面試者的角度來說。

如果沒有實際解決過類似問題，可以說一下自己的思路

只要大體思路和方向是對的，那在遇到類似問題的時候，可以利用網絡上的資料

去逐步嘗試解決。

大家記得點贊收藏加關注。

版權聲明：本博客所有文章除特別聲明外，均採用 CC BY-NC-SA 4.0 許可協議。轉載請註明來自 Mic帶你學架構！
如果本篇文章對您有幫助，還請幫忙點個關注和贊，您的堅持是我不斷創作的動力。歡迎關注「跟着Mic學架構」公眾號公眾號獲取更多技術乾貨！