原本要想讲心得，但想一想每个系同异质性太高 又难有 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