[心得] Java perf profiling 分享
原本要想講心得,但想一想每個系同異質性太高 又難有 SOP,
因此先以可以用的工具以及分析面相下手
當 SRE 回報了問題:
Case 1. 今天開始 latency 變高,但 QPS 沒比較多,也沒 Deploy 新版
Case 2. CPU 用不到 50% 開始 timeout
Case 3. 壓測沒問題,但系統跑一週後 latency 開始變高
Case 4. 新版本的記憶體使用量開始變高,但這個新版包含了三個月分的 commit
這些問題乍看之下是很難猜出原因,或是隨便說 qps 變高能唬(?)過去的
假設你的系統很肥大,同時有個 10 以上在開發,
且程式早就肥到你無法輕易猜出可能問題
此時也比較難去逐個 commit 比對哪裡開始出問題
因此一些 profiling 的技巧可以幫助你快速找到 root cause
1. 記憶體 - JVM heap GC
啟用方法就是你在執行 java 時帶上參數 -XX:+PrintGCDetails (詳細請見文件)
在執行的時候就會順便寫 gc log,這個通常建議預設開啟,
往後 debug prod issue 可以直接用就方便很多
首先你要知道你的 JVM 用了哪個 GC 演算法,最常見的大概是 CMS or G1,
演算法細節先不討論
gc log 可以用這套軟體幫助圖形化 https://it.gcplot.com/
圖形化後大概可以看 GC 的頻率與耗時、eden/tenured spaces 在 gc 前後的狀況等
在這個階段可以判斷出該往 memory leak 或調整JVM記憶體配置的方向
1-2 記憶體 - Memory profiling
在這個階段需要去 dump memory heap 來做分析看是否有無 memory leak
方法很簡單,直接執行下列指令,這個指令是 JDK 內建的
jmap -dump:format=b,file=/tmp/heapdump.bin [pid]
不過注意這個指令會停住整個 JVM 幾秒 (根據記憶體大小與效能),
如果在 PROD 執行建議先把流量切到 0
然後你就取得一個很大的檔案 (file size ~= JVM heap size)
然後一樣去用軟體分析,這裡我推薦 https://www.eclipse.org/mat/
當用軟體分析完後大概可以看到那些物件佔了最多記憶體與它的 stack trace
但同時你也需要具備該系統知識 這樣才能判斷記憶體占用是否符合預期
如果有 memory leak 此時看 stack trace 也可以輕易知道是哪段扣出問題
2. CPU profiling
這部分可以透過第三方軟體做 profiling,我推薦
https://github.com/jvm-profiling-tools/async-profiler
你可以簡單下載它的 release 檔案,並複製到要 profiling 的 JVM 底下,
範例指令 ./profiler.sh -e itimer -d [SECONDS] -o flat [PID] > cpu.log
這個指令是輕量的,所以是可以在 PROD 執行的,
但避免你被 SRE 暗殺建議還是要溝通好
執行完後會取得類似如下的 log
--- 6790000000 (98.84%) ns, 679 samples
[ 0] Primes.isPrime
[ 1] Primes.primesThread
[ 2] Primes.access$000
[ 3] Primes$1.run
[ 4] java.lang.Thread.run
此時就能判斷最吃 cpu 的 func 是否符合你的預期
所謂的符合預期....當然你還時要夠熟系統才能判斷
2-2 CPU - Thread dump
如果你猜有 deadlock 發生,可以執行下列指令取得 thread dump
jstack -l [PID] > cpu.log
這指令也是 JDK 內建,很方便
那看這個 dump 需要具備 OS, Multi-thread, deadlock 等知識
當然有些軟體會幫你判斷,但避免誤判建議這些知識還是需要的
3. Disk IO
這部分遺憾目前沒有找到適合的 profiling 軟體,尤其是針對 application 的
目前只能有 OS 層級監控 Disk IOPS
如果各位有好用的方法再麻煩推薦
以上大概涵蓋了 CPU, Memory, Disk 等的可用工具/分析面向
但在做這些之前基本的監控要先到位,
如 QPS, latency, Server CPU/Memory, network 等
但 troubleshooting 心法我覺得比較難整理出有系統的邏輯,
畢竟我現在還是常常繞一大圈 囧
--
※ 編輯: alihue (106.73.26.66 日本), 11/10/2021 22:41:40
推 這個上班有用過
這個必推
求網頁好讀版。有沒有考慮轉 FB 相關社團討論?
抱歉我不想要 ptt id 與 fb 連結,但文章歡迎轉貼到其他地方
※ 編輯: alihue (106.73.26.66 日本), 11/11/2021 00:11:19
推 JFR也不錯
感謝補充
遇到十秒就把Heap全吃爆進Full GC的外包PG就只能靠通靈了
外包: 請加更多的記憶體
※ 編輯: alihue (106.73.26.66 日本), 11/11/2021 09:42:23
推 最近也遇到類似問題
※ 編輯: alihue (106.73.26.66 日本), 11/11/2021 13:03:23
推分享
剛好遇到記憶體問題,推
30
[心得] ECC和非ECC記憶體架Server以下要說的純屬個人經驗,並沒有經過比較明確的驗證或測試,也可能單純只是個案 故僅供參考 我自己本身有架Server 主網頁伺服器(IIS+PHP+MySQL) 偶爾跑些程式、Docker或Minecraft Server之類 原本使用E3-1231v3+ECC記憶體(C224晶片組)3
Re: [請益]高流量網站和資料結構高流量應用 你沒定義好需求根本無法討論怎麼設計 1. 資料一致性要求? 持久性要求? 如果一定要用到交易,基本上一致性和持久性就一定要, 就直接用掉 CAP 定理的 Consistency,算是最常見的瓶頸 2. 如果是寫 log 系統,這種 QPS 要破萬比網站容易多了,也很常見