半夜的 OOM,却没留下证据 有天凌晨一个服务 OOM 自杀重启,等我早上到公司,堆已经被 GC 一遍、镜像重建了,啥都看不到。这种"看过现场却没拍照"的故障最折磨人,只能凭日志猜是哪块吃内存,结果猜了一上午猜错方向。从那以后我定下规矩:任何 Java 服务 OOM 必须自动留证,不能让现场随重启蒸
凌晨告警:服务起不来了,日志只有一行 一个深夜,我们的风控服务在发布后反复重启失败。Pod 日志最后一行永远是这句话: java.lang.OutOfMemoryError: unable to create new native thread at java.base/java.lang.
现象:堆才用了一半,容器就被 OOMKilled 10 月 28 号晚上,网关服务的一个 Pod 被 K8s 杀了。 $ kubectl describe pod api-gateway-5f8b7c9d4-xt2n9 Last State: Terminated Reason:
凌晨三点的告警:Metaspace OOM 3 月 15 号凌晨 3 点 12 分,监控告警把值班同学叫起来了:报表服务的一台实例 Full GC 频繁,接口全部超时。我早上到公司看日志,第一行就是: java.lang.OutOfMemoryError: Metaspace at java
入职第三个月,我把线上服务搞 OOM 了 那是个导出报表的功能。测试环境数据量小,跑得飞快;上线之后运营点了一次"导出全部",三分钟后服务就挂了。监控上堆内存是一条 45 度的斜线,直接顶到天花板然后掉底。 我登机器捞日志,看到了人生中第一个这个: Exception in thread "http