半夜被内存告警叫醒 Redis 实例内存从 4G 一夜之间冲到 14G，触发了 maxmemory 限制开始淘汰 key，部分缓存击穿打到数据库，数据库 CPU 跟着飙到 90%。我登录上去按几个维度逐一排查，过程比想象的有条理。Redis 内存暴涨不是玄学，按固定顺序查基本能覆盖绝大多数情况。 先
内存曲线像极了漏水的水龙头 订单服务上线两周，Old 区内存从 1.2G 缓慢爬到 3.8G，Full GC 后也只回一点，没真正回落。不是突崩，是慢性失血。这种"缓增长"最容易被忽视，因为单次看都正常，直到某天 Old 区满了频繁 Full GC，接口全抖。我用多次 dump 对比把它揪出来，过程
不想为了监控拖垮生产 之前用 VisualVM 连生产抓采样，JMX 一开 CPU 就飘，GC 行为都变了，抓到的数据还不可信。后来发现 JDK 11 起的 JFR（Java Flight Recorder）开销极低，而且 JDK 14 起的 Event Streaming 能实时订阅事件，不用等
背景：团队新人又慌了 七月一次支付成功率骤降，新来的同学第一反应是「我先重启试试」。结果重启把现场冲了，后面复盘只能靠猜。这种事不是第一次，我干脆把我们的线上排查 SOP 固化成文档，要求所有人遇事先照流程走，别凭直觉乱动。 第一原则：止血优先 出问题第一时间想的不是「为什么」，是「怎么不让它继续坏
RSS 涨到 5.8 GB，但堆才用了 1.2 GB，也没 OOM 4 月底值班，监控告警：订单服务一个实例的容器内存（RSS）从 2 GB 缓慢涨到 5.8 GB，持续了四天还在涨，但没有抛 OutOfMemoryError。K8s 的内存 limit 是 6 GB，再涨就要被 OOMKilled
4.2 G 的 hprof，MAT 自己先 OOM 了 12 月 22 号，营销服务的一个 Pod 因为 java.lang.OutOfMemoryError: Java heap space 挂了。运维在容器被重启前抓到了堆转储，文件大小 4.2 G。我把文件 scp 到本地，双击打开 MAT，进
告警：Pod CPU 987% 10 月 8 号下午，告警： [P1] order-service CPU 使用率 987% (limit 800%) 持续 20 分钟 CPU 是 8 核 limit，987% 意味着快跑满了。接口 P99 从 120 ms 涨到 3.4 秒，部分请求超时。 这类
现象：一个接口慢，但监控上看不出慢在哪 客服反馈"订单详情页打开要转好几秒"，我们查 Grafana，GET /order/{id}/detail 的 P99 从平时的 120 ms 涨到了 900 ms 左右，P50 没变。也就是说不是全量慢，是部分订单慢。 SkyWalking 8.6 上只能看
十月的一个早晨：Full GC 每小时 40 次 十月二十六号一早，监控群里机器人在刷告警。报表服务的 Full GC 频率从平时的每小时 0~1 次，涨到了 40 次。 $ jstat -gcutil 1 2000 10 S0 S1 E O M CC
问题：一个只在生产出现的接口变慢 九月下旬，客服反馈"订单详情页打开很慢"。我在测试环境怎么点都是 80ms，生产上就是 3 秒左右。 按以前的办法，要么加日志重新发版（生产发一次要走流程，至少半小时），要么 jstack 抓线程栈（只能看某一瞬间的状态，看不到耗时分布）。这次我试了下 Arthas
