半夜被内存告警叫醒 Redis 实例内存从 4G 一夜之间冲到 14G,触发了 maxmemory 限制开始淘汰 key,部分缓存击穿打到数据库,数据库 CPU 跟着飙到 90%。我登录上去按几个维度逐一排查,过程比想象的有条理。Redis 内存暴涨不是玄学,按固定顺序查基本能覆盖绝大多数情况。 先
内存曲线像极了漏水的水龙头 订单服务上线两周,Old 区内存从 1.2G 缓慢爬到 3.8G,Full GC 后也只回一点,没真正回落。不是突崩,是慢性失血。这种"缓增长"最容易被忽视,因为单次看都正常,直到某天 Old 区满了频繁 Full GC,接口全抖。我用多次 dump 对比把它揪出来,过程
RSS 涨到 5.8 GB,但堆才用了 1.2 GB,也没 OOM 4 月底值班,监控告警:订单服务一个实例的容器内存(RSS)从 2 GB 缓慢涨到 5.8 GB,持续了四天还在涨,但没有抛 OutOfMemoryError。K8s 的内存 limit 是 6 GB,再涨就要被 OOMKilled
告警:Pod CPU 987% 10 月 8 号下午,告警: [P1] order-service CPU 使用率 987% (limit 800%) 持续 20 分钟 CPU 是 8 核 limit,987% 意味着快跑满了。接口 P99 从 120 ms 涨到 3.4 秒,部分请求超时。 这类
十月的一个早晨:Full GC 每小时 40 次 十月二十六号一早,监控群里机器人在刷告警。报表服务的 Full GC 频率从平时的每小时 0~1 次,涨到了 40 次。 $ jstat -gcutil 1 2000 10 S0 S1 E O M CC
批量扣款任务卡死后,单笔扣款接口也全挂了 7 月 5 号早上 9 点 12 分,监控开始告警:/api/deduct 接口响应时间从 60 毫秒飙到 30 秒全部超时。同时 DBA 在群里说,account 表上有锁等待,已经持续 4 分钟。 第一反应是数据库慢查询。但登上机器看,应用这边 CPU
运维在群里 @ 我:你们这个服务内存一直在涨 那天下午运维丢了一张图到群里,是 Zabbix 上我们订单服务的 JVM 内存曲线,从早上 9 点的 1.2 GB 一路爬到下午 4 点的 3.8 GB,容器限制是 4 GB。他问:这是不是内存泄漏? 我当时的第一反应是想 dump 下来看,被带我的师兄