第33講后臺服務出現(xiàn)明顯變慢談談你的診斷思路

1、第33講 | 服務出現(xiàn)明顯“變慢”，談談你的 思路？2018-07-212018/7/23極客時間 | Java 技術36講第33講 | 服務出現(xiàn)明顯“變慢”，談談你的 思路？朗讀人： 1018 | 4.72M在日常工作中，應用或者系統(tǒng)出現(xiàn)性能問題往往是不可避免的，除了在有一定規(guī)模的 IT 企業(yè)或者專注于特定性能領域的企業(yè)，可能大多數(shù)工程師并 成為專職的性能工程師，但是掌握基本的性能知識和技能，往往是日常工作的需要，并且也是工程師進階的必要條件之一，能 位和解決性能問題也是對你知識、技能和能力的檢驗。我要問你的問題是， 服務出現(xiàn)明顯“變慢”，談談你的 思路？典型回答首先，需要對這個問題進行更加

2、清晰的定義:服務是突然變慢還是長時間運行后觀察到變慢？類似問題是否重復出現(xiàn)？“慢”的定義是什么，我能夠理解是系統(tǒng)對其他方面的請求的反應延時變長嗎? 第二，理清問題的癥狀，這更便于定位具體的 ，有以下一些思路：問題可能來自于 Java 服務自身，也可能僅僅是受系統(tǒng)里其他服務的影響。初始可以先確認是否出現(xiàn)了意外的程序錯誤，例如檢查應用本身的錯誤日志。 1/72018/7/23極客時間 | Java 技術36講對于分布式系統(tǒng)，很多公司都會實現(xiàn)更 的日志、性能等 系統(tǒng)。一些 Java 工具也可以用于這個 ，例如通過 JFR（Java Flight Recorder）， 應用是否大量出現(xiàn)了某種類型的異常

3、。如果有，那么異?？赡芫褪莻€ 點。如果沒有，可以先檢查系統(tǒng)級別的資源等情況， CPU、內(nèi)存等資源是否被其他進程大量占用，并且這種占用是否不符合系統(tǒng)正常運行狀況。Java 服務自身，例如 GC 日志里面是否觀察到 Full GC 等惡劣情況出現(xiàn)，或者是否Minor GC 在變長等；利用 jstat 等工具，獲取內(nèi)存使用的統(tǒng)計也是個常用 ；利用jstack 等工具檢查是否出現(xiàn)死鎖等。如果還不能確定具體問題，對應用進行 Profiling 也是個辦法，但因為它會對系統(tǒng)產(chǎn)生侵入性，如果不是非常必要，大多數(shù)情況下并不建議在生產(chǎn)系統(tǒng)進行。定位了程序錯誤或者 JVM 配置的問題后，就可以采取相應的補救措施，

4、然后驗證是否解決， 否則還需要重復上面部分過程?？键c分析我選擇的是一個常見的并且比較貼近實際應用的的性能相關問題，我提供的回答 兩部分。在正面回答之前，先探討更加精確的問題定義是什么。有時候面試官并沒有表達清楚，有必 要確認 的理解正確，然后再深入回答。從系統(tǒng)、應用的不同角度、不同層次，逐步將問題域盡量縮 離出真實 。具體步驟未必千篇一律，在處理過較多這種問題之后，經(jīng)驗會令你的直覺分外敏感。大多數(shù)工程師也許并沒有全面的性能問題 機會，如果被問到也不必過于緊張，你可以向面試官展示 問題的思考方式，展現(xiàn) 的知識和綜合運用的能力。接觸到一個陌生的問題，通過，能夠條理清晰地將排查方案逐步確定下來，也是

5、能力的體現(xiàn)。面試官可能會 某個角度的深入詢問，兼顧工作和面試的需求，我會 下面一些方面進行 。目的是讓你對性能分析有個整體的印象，在遇到特定領域問題時，即使不知道具體細節(jié)的工具和 ，至少也可以找到探索、的方向。我將 業(yè)界常見的性能分析 論。從系統(tǒng)分析到 JVM、應用性能分析，把握整體思路和主要工具。對于線程狀態(tài)、JVM 內(nèi)存使用等很多方面，我在專欄前面已經(jīng)陸陸續(xù)續(xù) 了很多， 這一講也可以看作是聚焦性能角度的一個小結。2/72018/7/23極客時間 | Java 技術36講如果你有 進行系統(tǒng)性的學習，我建議參考 Hunt 編撰的Java Performance或者Scott Oaks 的Jav

6、a Performance：The Definitive Guide。另外，如果不希望出現(xiàn)理解偏差，最好是閱讀英文版。知識擴展首先，我們來了解一下業(yè)界最廣泛的性能分析 論。根據(jù)系統(tǒng)架構不同，分布式系統(tǒng)和大型單體應用也 著思路的區(qū)別，例如，分布式系統(tǒng)的性能瓶頸可能更加集中。傳統(tǒng)意義上的性能調(diào)優(yōu)大多是 單體應用的調(diào)優(yōu)，專欄的側重點也是如此， Hunt 曾將其論總結為兩類：自上而下。從應用的頂層，逐步深入到具體的不同模塊，或者更 的技術細節(jié)單元，找到可能的問題和解決辦法。這是最常見的性能分析思路，也是大多數(shù)工程師的選擇。自下而上。從類似 CPU 這種硬件底層，類似Cache-Miss之類的問題和調(diào)優(yōu)

7、機會，出發(fā)點是指令級別優(yōu)化。這往往是專業(yè)的性能工程師才能掌握的技能，并且需要專業(yè)工具配合， 大多數(shù)是移植到新的平臺上，或需要提供極致性能時 進行。例如，將大數(shù)據(jù)應用移植到 SPARC 體系結構的硬件上，需要對比和盡量性能潛力，但又希望盡量不改源代碼。我所給出的回答，首先是試圖排除功能性錯誤，然后就是典型的自上而下分析思路。第二，我們一起來看看自上而下分析中，各個階段的常見工具和思路。需要注意的是，具體的工 具在不同的操作系統(tǒng)上可能區(qū)別非常大。系統(tǒng)性能分析中，CPU、內(nèi)存和 IO 是主要關注項。對于 CPU，如果是常見的 Linux，可以先用 top 命令查看負載狀況，下圖是我截取的一個狀態(tài)。可

8、以看到，其平均負載（load average）的三個值（分別是 1 分鐘、5 分鐘、15 分鐘）非常低，并且暫時看并沒有升高跡象。如果這些數(shù)值非常高（例如，超過 50%、60%），并且短期平均值高于長期平均值，則表明負載很重；如果還有升高的趨勢，那么就要非常警惕了。3/72018/7/23極客時間 | Java 技術36講進一步的排查有很多思路，例如，我在專欄第 18 講曾經(jīng)問過，怎么找到最耗費 CPU 的 Java 線程，簡要 步驟：top H利用 top 命令獲取相應 pid，“-H”代表 th 模式，你可以配合 grep 命令更精準定位。然后轉(zhuǎn)換成為 16 進制。printf "

9、;%x" your_pid最后利用 jstack 獲取的線程棧，對比相應的 ID 即可。vmstat -1 -10當然，還有更加通用的 方向，利用 vmstat 之類，查看上下文切換的數(shù)量，比如下面就是指定時間間隔為 1，收集 10 次。輸出如下：如果每秒上下文（cs，context switch）切換很高，并且比系統(tǒng)中斷高很多（in，system interrupt），就表明很有可能是因為不合理的多線程調(diào)度所導致。當然還需要利用pidstat等手段，進行更加具體的定位，我就不再進一步展開了。除了 CPU，內(nèi)存和 IO 是重要的注意事項，比如：利用 之類查看內(nèi)存使用。或者，進一步 s

10、wap 使用情況，top 命令輸出中 Virt 作為虛擬內(nèi)存使用量，就是物理內(nèi)存（Res）和 swap 求和，所以可以反推 swap 使用。顯然，JVM 是不希望發(fā)生大量的swap 使用的。4/72018/7/23極客時間 | Java 技術36講對于 IO 問題，既可能發(fā)生在磁盤 IO，也可能是網(wǎng)絡 IO。例如，利用 iostat 等命令有助于磁盤的健康狀況。我曾經(jīng)幫助 過 Java 服務部署在國內(nèi)的某云廠商機器上，其 就是 IO 表現(xiàn)較差，拖累了整體性能，解決辦法就是申請?zhí)鎿Q了機器。講到這里，如果你對系統(tǒng)性能非常感 ，我建議參考Brendan Gregg提供的完整圖譜，我所的只能算是九牛一

11、毛。但我還是建議盡量結合實際需求，免得迷失在其中。對于JVM 層面的性能分析，我們已經(jīng) 過非常多了： 利用 JMC、JConsole 等工具進行運行時 。利用各種工具，在運行 堆轉(zhuǎn)儲分析，或者獲取各種角度的統(tǒng)計數(shù)據(jù)（如jstat -gcutil 分析 GC、內(nèi)存分帶等）。，GC 日志等Full GC、Minor GC，或者 堆積等。這里并不 放之四海而皆準的辦法，具體問題可能非常不同，還要看你是否能否充分利用這些工具，從種種跡象之中，逐步 出問題所在。對于應用Profiling，簡單來說就是利用一些侵入性的 ，收集程序運行時的細節(jié)，以定位性能問題瓶頸。所謂的細節(jié)，就是例如內(nèi)存的使用情況、最頻繁

12、調(diào)用的 是什么，或者上下文切換的情況等。5/72018/7/23極客時間 | Java 技術36講我在前面給出的典型回答里提到， 不建議生產(chǎn)系統(tǒng)進行 Profiling，大多數(shù)是在性能測試階段進行。但是，當生產(chǎn)系統(tǒng)確實 這種需求時，也不是沒有選擇。我建議使用 JFR 配合JMC 來做 Profiling，因為它是從 Hotspot JVM 內(nèi)部收集底層 ，并經(jīng)過了大量優(yōu)化，性能開銷非常低，通常是低于 2% 的；并且如此強大的工具，也已經(jīng)被 Oracle 開源出來！所以，JFR/JMC 完全具備了生產(chǎn)系統(tǒng) Profiling 的能力，目前也確實在真正大規(guī)模部署的云上使用過相關技術，快速地定位了問

13、題。Jcmd <pid> JFR.start duration=120s filename=myrecording.jfr它的使用也非常方便，你不需要重新啟動系統(tǒng)或者提前增加配置。例如，你可以在運行時啟動JFR ，并將這段時間的 寫入文件：然后，使用 JMC 打開“.jfr 文件”就可以進行分析了， 、異常、線程、IO 等應有盡有，其功能非常強大。如果你想了解 細節(jié)，可以參考相關指南。我從一個典型性能問題出發(fā)，從癥狀表現(xiàn)到具體的系統(tǒng)分析、JVM 分析，系統(tǒng)性地整理了常見性能分析的思路；并且在知識擴展部分，從 論和實際操作的角度，讓你將理論和實際結合，相信一定可以對你有所幫助。一課一練關于 我們討論的題目你做到心中有數(shù)了嗎？ 的思考題是，Profiling 工具獲取數(shù)據(jù)的主要方式有哪些？各有什么優(yōu)缺點。請你在留言區(qū)寫寫你對這個問題的思考，我會選出經(jīng)過認真思考的留言，送給你一份學習獎勵禮券，歡迎你與我一起討論。你的朋友是不是也在準備面試呢？你可以“請朋友讀”，把 的題目 給好友