「Arthas 凭什么不用改代码就能看到方法耗时」 2 月初排查一个慢接口，我用 Arthas 的 trace 打出了每一层调用的耗时。旁边一个刚工作两年的同事看完很惊讶：我们没加任何埋点，也没改代码，它怎么知道每个方法花了多久？ 这个问题一两句话讲不清楚，正好我那几天在给公司内部的压测平台做一个无
「线程数加到 800 了，还是上不去」 1 月中旬看压测报告，开放平台那个网关服务的并发一直卡在 4000 左右。压测的同学在群里说：「Tomcat 线程数已经从 200 加到 800 了，加不动了，再加 Full GC 就开始频繁。」 这个症状太典型了——线程成了并发的天花板。我把之前攒的 Loo
4.2 G 的 hprof，MAT 自己先 OOM 了 12 月 22 号，营销服务的一个 Pod 因为 java.lang.OutOfMemoryError: Java heap space 挂了。运维在容器被重启前抓到了堆转储，文件大小 4.2 G。我把文件 scp 到本地，双击打开 MAT，进
现象：堆才用了一半，容器就被 OOMKilled 10 月 28 号晚上，网关服务的一个 Pod 被 K8s 杀了。 $ kubectl describe pod api-gateway-5f8b7c9d4-xt2n9 Last State: Terminated Reason:
告警：Pod CPU 987% 10 月 8 号下午，告警： [P1] order-service CPU 使用率 987% (limit 800%) 持续 20 分钟 CPU 是 8 核 limit，987% 意味着快跑满了。接口 P99 从 120 ms 涨到 3.4 秒，部分请求超时。 这类
起因：压测时前 3 分钟的数据全不能看 9 月初给一个轨迹计算服务做压测，用 JMeter 压 10 分钟，发现吞吐曲线很怪：第 1 分钟 3200 QPS，第 3 分钟 7100 QPS，之后稳定在 8900 QPS 左右。同样的机器、同样的并发，吞吐差了 2.8 倍。 这其实就是 JIT 预热的
现象：一个接口慢，但监控上看不出慢在哪 客服反馈"订单详情页打开要转好几秒"，我们查 Grafana，GET /order/{id}/detail 的 P99 从平时的 120 ms 涨到了 900 ms 左右，P50 没变。也就是说不是全量慢，是部分订单慢。 SkyWalking 8.6 上只能看
实习生问我：这堆 GC 日志到底看什么 4 月底，团队来了个实习生。有次他看到我电脑上的 gc.log，问了一句："这一行行的数字，你是怎么看出问题的？" 2021-04-28T09:14:22.118+0800: 341882.221: [GC (Allocation Failure) [PSY
风控服务被 Full GC 拖出的长尾 2021 年 1 月底，风控服务的 P99 突然变差。这个服务是同步调用链路上的一环，上游给的超时是 800 ms，一旦它慢了，整个下单流程都会受影响。 当时的配置：JDK 8u272，8 G 堆，CMS + ParNew。 $ jstat -gcutil 1
十月的一个早晨：Full GC 每小时 40 次 十月二十六号一早，监控群里机器人在刷告警。报表服务的 Full GC 频率从平时的每小时 0~1 次，涨到了 40 次。 $ jstat -gcutil 1 2000 10 S0 S1 E O M CC
