“生產環境服務器變慢？如何診斷處理”
這是最近一些作業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學架構」公眾號公眾號獲取更多技術干貨！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/500966.html
標籤：其他