← All incidents

[Eval][v3][zh] Order service OOM crashloop following v3.7 deploy

service: order-svccreated: 6/2/2026, 11:55:18 PM

Raw incident context

Time: 09:15 UTC. order-svc pods entering CrashLoopBackOff with OOMKilled exit reason.

Kubernetes:
- Pods: 12 total, 3 currently OOMKilled, 9 running
- Memory limit: 512Mi, requests: 256Mi
- Recent restarts/hour: 18 (up from baseline of 0–1)
- HPA scaling has hit max replicas (12)

Memory trend (last 24h):
- Steady linear growth from 180Mi at 04:00 UTC to 500Mi at 09:00 UTC, then crash
- Pre-deploy baseline: stable at 200Mi indefinitely

Deploy history:
- 04:00 UTC — order-svc v3.7 deployed (rolling, 100% complete by 04:08)
- Changelog: "switched JSON parser to fast-json-stringify; added in-process request cache (Map-based, no eviction)"

Logs:
- No FATAL/ERROR pattern; pods exit silently
- Heap profile from one captured pod shows: ~340Mi held by Map keyed on request ID, never cleared

On-call:
- 09:12 — first OOMKilled pod
- 09:14 — pager
- 09:16 — service still serving most traffic via remaining pods; checkout success rate dipped from 99.7% → 96.8%

Summary

SEV1

order-svc 自 09:12 UTC 起出现 Pod OOMKilled 重启循环，p99 延迟升高，约 3% 请求超时。根因是 v3.7 部署引入的无上限 Map 缓存，内存持续增长直至达到 512Mi 限制。当前 3 个 Pod 已崩溃，9 个运行中，HPA 已达最大副本数。

Severity reasoning: 用户可见的故障：结账成功率从 99.7% 降至 96.8%（>1% 错误率持续超过 5 分钟），且影响收入路径。符合 SEV1 标准。

deepseek-chat·prompt v3·output: zh·10018ms·2418↑ / 1454↓ tok·$0.00225

Root cause hypotheses

  • highv3.7 部署引入的无上限 Map 缓存导致内存泄漏

    Evidence: 堆分析显示约 340Mi 被请求 ID 为键的 Map 占用，且从未清理；内存从 04:00 的 180Mi 线性增长至 09:00 的 500Mi。

  • lowfast-json-stringify 库存在内存泄漏

    Evidence: 无直接证据；日志无错误，且堆分析指向 Map 而非序列化缓冲区。

  • medium请求流量突增导致内存压力

    Evidence: HPA 已达最大副本数，但内存增长模式是线性而非阶梯式，且基线之前稳定。

Investigation checklist

  1. 确认内存泄漏源：检查存活 Pod 的内存使用趋势
    kubectl top pod -n prod -l app=order-svc --sort-by=memory | head -10

    Expected: 内存使用接近 512Mi 的 Pod 列表，确认多个 Pod 内存持续增长。

  2. 验证 Map 缓存未清理：检查代码中缓存实现
    kubectl exec -n prod deploy/order-svc -- cat /app/src/cache.js | grep -E 'Map|clear|evict|max'

    Expected: 显示 Map 定义，无 eviction 或 max 限制。

  3. 确认部署时间与内存增长关联
    kubectl rollout history -n prod deploy/order-svc | grep v3.7

    Expected: 显示 v3.7 于 04:00 部署，与内存开始增长时间吻合。

  4. 检查 HPA 是否达到上限导致无法扩容
    kubectl describe hpa -n prod order-svc-hpa | grep -E 'Min|Max|Replicas'

    Expected: 当前副本数 12，已达最大副本数。

Mitigation plan

  • 回滚 order-svc 至 v3.6（上一个稳定版本）

    Risk: 回滚期间可能有短暂连接中断；v3.6 无缓存优化，性能可能略低。

    Rollback: 再次执行 kubectl rollout undo 可恢复至 v3.7。

  • 临时增加内存限制至 1Gi，并重启所有 Pod

    Risk: 可能掩盖根本问题；增加资源消耗。

    Rollback: 恢复内存限制至 512Mi 并重启。

  • 在代码中为 Map 缓存添加 LRU 淘汰策略或 TTL

    Risk: 需要代码变更和重新部署，耗时较长。

    Rollback: 回滚代码变更。

Customer impact

部分用户在下单时遇到超时或错误，结账成功率从 99.7% 下降至 96.8%。预计影响约 3% 的请求。团队正在回滚以恢复服务。

Postmortem draft

总结

order-svc 因 v3.7 部署引入的无上限 Map 缓存导致内存泄漏，引发 Pod OOMKilled 重启循环，影响结账成功率。

时间线 (UTC)

  • 04:00 - v3.7 部署完成
  • 09:12 - 首个 Pod OOMKilled
  • 09:14 - 触发告警
  • 09:16 - 确认影响，开始调查
  • [FILL IN] - 回滚完成，服务恢复

影响

  • 结账成功率从 99.7% 降至 96.8%
  • p99 延迟升高
  • 3 个 Pod 崩溃，9 个运行中

根因

v3.7 引入的请求 ID Map 缓存无大小限制，导致内存持续增长直至 OOM。

检测

告警延迟：内存增长持续 5 小时才触发 OOM。

响应

  • 09:16 开始调查
  • 回滚至 v3.6 恢复服务

做得好的

  • 快速识别内存泄漏
  • 回滚决策果断

做得不好的

  • 代码审查未发现缓存无上限
  • 缺乏内存增长告警

行动项

  • [ ] 为缓存添加大小限制和淘汰策略
  • [ ] 添加内存增长告警
  • [ ] 代码审查增加内存泄漏检查

Follow-ups

  • P0为 order-svc 缓存添加 LRU 淘汰策略和最大条目限制— order-svc 服务负责人
  • P1添加内存使用率增长告警（例如 80% 限制时告警）— on-call SRE
  • P1审查 v3.7 代码变更，确保无其他内存泄漏— order-svc 服务负责人
  • P2增加 HPA 最大副本数或启用集群自动缩放— 平台团队

Similar past incidents

lexical match (pg_trgm)