線(xiàn)上問(wèn)題處理流程

直接放PPT截圖吧，現在看來(lái)依然不過(guò)時(shí)

問(wèn)題排查

可從三個(gè)方面入手

• 知識：有些問(wèn)題，思考一下就有答案，就像傳說(shuō)中多隆那樣，回憶下就知道第83行代碼有問(wèn)題~
• 工具：當然不是每個(gè)人都能做到過(guò)目不忘，也有可能這代碼完全不是你寫(xiě)的，這時(shí)就需要靠工具來(lái)定位問(wèn)題
• 數據：程序運行時(shí)產(chǎn)生的數據，也能提供很多線(xiàn)索

知識

知識有很多方面，這里簡(jiǎn)單列舉一下：

• 語(yǔ)言（本文特指 Java）：如 JVM 知識、多線(xiàn)程知識等
• 框架：如 Dubbo、Spring 等
• 組件：如 Mysql、RocketMq 等
• 其他：如網(wǎng)絡(luò )、操作系統等

舉個(gè)例子，我們需要理解 Java 對象從申請到被回收整個(gè)過(guò)程，這個(gè)圖非常清晰，建議爛熟于心：

然后也要了解常見(jiàn)的垃圾收集器：

吞吐量=單位時(shí)間內處理的請求數量=運行代碼時(shí)間 / (運行代碼時(shí)間 + 垃圾回收時(shí)間)

以 ParNew + CMS 為例 ，嘗試回答如下幾個(gè)問(wèn)題：

• 為什么要分代收集？— 關(guān)鍵字：效率
• 對象什么時(shí)候進(jìn)入老年代？— 關(guān)鍵字：年齡、大小
• Young GC 與 Full GC 什么時(shí)候發(fā)生？— 關(guān)鍵字：Eden 不足、Old 不足、Meta 不足、map/System.gc

如果我們了解上述的這些知識后，舉個(gè)實(shí)際例子，當我們發(fā)現 Young GC 頻繁觸發(fā)，耗時(shí)高，該如何優(yōu)化？

首先思考，Young GC 什么時(shí)候觸發(fā)？答案是 Eden 區不足。

接著(zhù)，Young GC 耗時(shí)主要是哪里耗時(shí)？答案是掃描 + 復制，掃描通常很快，復制比較慢。

那我們對癥下藥，增加新生代大小試試，結果真的解決問(wèn)題了，為什么？我們也分析一下

新生代大小為 M 時(shí)，假設對象存活  750ms，young GC間隔 500ms，掃描時(shí)間為 T1，復制時(shí)間為 T2

• 新生代大小為 M 時(shí)：頻率 2次/s，每次耗時(shí) T1 + T2
• 新生代擴大為 2M 時(shí)：頻率 1次/s，每次耗時(shí) 2T1

由于T2遠遠大于T1，所以2T1 < T1 + T2

這就是知識的力量~

工具

Java 棧中的工具，也分為這幾類(lèi)：

• JDK 自帶：如 jstat、jstack、jmap、jconsole、jvisualvm
• 第三方：MAT（eclipse插件）、GCHisto、GCeasy（在線(xiàn)GC日志分析工具，https://gceasy.io/）
• 開(kāi)源：大名鼎鼎的Arthas、bistoury（去哪網(wǎng)開(kāi)源）、Async-profiler

這些工具的原理，我們也需要稍微了解下，比如 Cpu profiler大概有兩類(lèi)：

• 基于采樣：優(yōu)點(diǎn)是性能開(kāi)銷(xiāo)低，缺點(diǎn)是采樣有頻率限制，存在SafePoint Bias問(wèn)題
• 插樁：所有方法添加  AOP 邏輯，優(yōu)點(diǎn)是精準采集，缺點(diǎn)是性能開(kāi)銷(xiāo)高

比如 uber 開(kāi)源的 uber-common/jvm-profiler，它就是基于采樣的 Cpu profiler，缺點(diǎn)就是存在 SafePoint Bias 問(wèn)題，比如有一次排查一個(gè) Cpu 占用問(wèn)題，就采集到了這樣的火焰圖，可以看到幾乎沒(méi)啥用

SafePoint（安全點(diǎn)） 可以簡(jiǎn)單理解為 JVM 可以停頓下來(lái)的特定位置的點(diǎn)，如果采樣的位置是特定的點(diǎn)，那么采樣就不具有代表性，因為可能在非 SafePoint 時(shí)可能消耗了更多的 Cpu，這種現象就被稱(chēng)為 SafePoint Bias 問(wèn)題。

但我用另一個(gè) jvm-profiling-tools/async-profiler 來(lái)采集，就能看到性能瓶頸：

雖然 Async-profiler 也是基于采樣做，但它能避免 SafePoint Bias 問(wèn)題，原因是它采用了 AsyncGetCallTrace 的黑科技。于是依據 Async-profiler 給出的火焰圖進(jìn)行優(yōu)化，Qps 從 58k 漲到 81k，Cpu 反而從72%下降到了41%

數據

數據包括：

• 監控數據，如APM、metric、JVM監控、分布式鏈路追蹤等等數據
• 程序運行數據：如業(yè)務(wù)數據、AccessLog、GC log、系統日志等

這部分就按實(shí)際來(lái)分析，沒(méi)有統一模板可言。

經(jīng)驗

說(shuō)了這么多，從經(jīng)驗角度總結了如下常見(jiàn)問(wèn)題該從哪些方面入手：

• 執行異常：查看日志、debug、請求重放
• 應用僵死：jstack
• 耗時(shí)高：trace跟蹤、Benchmark
• Cpu利用率高：Cpu profile分析
• GC頻繁、耗時(shí)高：GC log分析
• OOM、內存占用高、泄漏：dump內存分析

案例分享

Cobar僵死，進(jìn)程端口在，但不能處理請求

先踢掉故障機器，保留現場(chǎng)再排查問(wèn)題，根據日志，定位為內存泄漏

小思考：能通過(guò)日志直接確定是哪里內存泄露嗎？— 答案：不能

具體定位可dump內存下載到本地分析，文件如果太大，可以先壓縮下

jmap -dump:format=b,file=/cobar.bin ${pid}

使用 eclipse 的插件 MAT 分析，過(guò)程就不放了，結果是發(fā)現了一個(gè)我們對 Cobar 自定義修改導致的 Bug，如果對內存分析感興趣，可以直接看我這幾篇實(shí)戰文章：

網(wǎng)關(guān)耗時(shí)高

使用 Arthas trace 跟蹤調用

trace com.beibei.airborne.embed.extension.PojoUtils generalize

接入 Sentinel 導致應用僵死

接入限流降級利器 Sentinel 后，配置一條規則，觸發(fā)后導致應用僵死，可使用 jstack 進(jìn)行排查，一眼就看出問(wèn)題所在

jstack ${pid} > jstack.txt