※ [本文转录自 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/cn.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