※ [本文轉錄自 Soft_Job 看板 #1XYzdQ_o ] 作者: alihue (wanda wanda) 看板: Soft_Job 標題: [心得] Java perf profiling 分享 時間: Wed Nov 10 22:40:20 2021 原本要想講心得，但想一想每個系同異質性太高 又難有 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 或是加記憶體的方向 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 心法我覺得比較難整理出有系統的邏輯， 畢竟我現在還是常常繞一大圈 囧 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 106.73.26.66 (日本) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1636555226.A.FF2.html ※ 編輯: alihue (106.73.26.66 日本), 11/10/2021 22:41:40

※ 發信站: 批踢踢實業坊(ptt.cc) ※ 轉錄者: alihue (106.73.26.66 日本), 11/10/2021 23:07:10