ToB企服应用市场:ToB评测及商务社交产业平台

标题: 生产事故-记一次特殊的OOM排查 [打印本页]
作者: 杀鸡焉用牛刀    时间: 2023-4-14 01:54
标题: 生产事故-记一次特殊的OOM排查
入职多年，面对生产环境，尽管都是小心翼翼，慎之又慎，还是难免捅出篓子。轻则满头大汗，面红耳赤。重则系统停摆，损失资金。每一个生产事故的背后，都是宝贵的经验和教训，都是项目成员的血泪史。为了更好地防范和遏制今后的各类事故，特开此专题，长期更新和记录大大小小的各类事故。有些是亲身经历，有些是经人耳传口授，但无一例外都是真实案例。
注意：为了避免不必要的麻烦和商密问题，文中提到的特定名称都将是化名、代称。
0x00 大纲


目录

0x01 事故背景

2023年3月10日14时19分，C公司开发人员向A公司开发人员反映某开放接口从2023年3月10日14时许开始无法访问和使用。该系统为某基础数据接口服务，基于 HTTP 协议进行通信。按照惯例，首先排查网络是否异常，经运维人员检查，证明网络连通性没有问题。A公司开发组于2023年3月10日14时30分通知运维人员重启应用服务，期间短暂恢复正常。但是，很快，十分钟后，电话再次响起，告知服务又出现异常，无法访问。为了避免影响进一步扩大，A公司决定将程序紧急回滚至上一稳定版本。回滚后，系统业务功能恢复正常。短暂松一口气后，开始排查问题。
0x02 事故分析

让运维拷贝和固定了更新前后的系统日志和应用包。根据前面的故障现象，初步猜测是内存问题，好在应用启停脚本中增加了参数-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/app/logs/app.dump（对于无法在生产环境上使用jstack、jmap等命令直接查错的——事实上大多数时候都不能，dump文件显得尤为重要），果不其然，日志目录下出现了app.dump文件，在日志中搜索，找到了若干处内存溢出错误java.lang.OutOfMemoryError: Java heap space，但是令人费解的是每次出现OOM错误的位置居然都不一样，事情逐渐变得复杂起来。
用MAT(Memory Analyzer Tool)工具打开转储文件，原以为会发现某个类型对象占用大量的内存，结果出乎意料，Histogram（直方图）中显示活跃对象居然只有100多M！尝试 Calculate Precise Retained Size（计算精确大小），计算结果与前面相差不大。检查 Outgoing References （追踪引用对象）和  Incoming References（追踪被引用对象）也未见明显异常，令人头大。
擦擦汗，日志已经明确提示我们java.lang.OutOfMemoryError: Java heap space，首先肯定这是一个堆内存空间引起的问题，可能的原因有：
如果排除所有合理选项，最不合理那个会不会就是答案呢？遂开始检查机器的内存，根据运维的说法，机器内存为16GB，top命令查看java进程占用内存约为7.8GB，看起来似乎没毛病。
但是随后另一个同事注意到了一个事情，最后一次系统升级的时候，改动过应用启停脚本，对比旧版本的脚本，发现差异部分就是内存参数：
旧版本原为：
  1. -Xms8g -Xmx8g -Xmn3g
复制代码
新版本改为：
  1. -Xms8g -Xmx8g -Xmn8g
复制代码
看到这里，屏幕前的一众同事都无语啊……
0x03 事故原因

为什么-Xmn参数设置成与-Xmx参数一样的大小会导致OOM呢？该项目使用的JDK版本为1.8，看看JDK 8的内存模型：

不难发现，Heap Space Size = Young Space Size + Old Space Size，而-Xmn参数控制的正是 Young 区的大小，当堆区被 Young Gen 完全挤占，又有对象想要升代到 Old Gen 时，发现 Old 区空间不足，于是触发 Full GC，触发 Full GC 以后呢，通常又会面临两种情况：
这个就解释了为什么系统刚刚启动时，会有一个短时间正常工作的现象，随后，当某段程序触发 Old Gen 升代时，就会发生随机的OOM错误。那么什么时候对象会进入老年代呢？这里也很有意思，不妨结合日志里面出现OOM的地方，对号入座：
换言之，正常情况下，-Xmn参数总是应当小于-Xmx参数，否则就会触发OOM错误。我们可以构造一个简单的例子来验证这个场景。首先是一个简单的SpringBoot程序：
  1. package com.example.oom;
  3. import org.springframework.boot.SpringApplication;
  4. import org.springframework.boot.autoconfigure.SpringBootApplication;
  5. import org.springframework.web.bind.annotation.GetMapping;
  6. import org.springframework.web.bind.annotation.RestController;
  7. import java.util.Random;
  9. @SpringBootApplication
  10. public class OomApplication {
  11.     static final byte[] ARRAY = new byte[128 * 1024 * 1024];
  13.     public static void main(String[] args) {
  14.         SpringApplication.run(OomApplication.class, args);
  15.     }
  17.     @RestController
  18.     public static class OomExampleController {
  19.         @GetMapping("/oom")
  20.         public int oom() {
  21.             byte[] temp = new byte[128 * 1024 * 1024];
  22.             temp[0] = (byte) 0xff;
  23.             temp[temp.length - 1] = (byte) 0xef;
  24.             int noise = new Random().nextInt();
  25.             ARRAY[0] = (byte) (temp[0] + temp[temp.length - 1] + noise);
  26.             return ARRAY[0];
  27.         }
  28.     }
  29. }
复制代码
使用mvn clean package命令打包后，我们用下面的命令启动它：
  1. java -Xms512m -Xmx512m -Xmn512m -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar oom-1.0.0-RELEASE.jar
复制代码
然后借助Apache的ab.exe，完成我们的验证测试。先是以1个并发访问100次上面的SpringBoot接口：
  1. ab -c 1 -n 100 http://localhost:8080/oom
复制代码
你会发现，它居然是可以正常运行的，然后我们模拟用户负载上来之后的情况，使用2个并发访问100次：
  1. ab -c 2 -n 100 http://localhost:8080/oom
复制代码
如果前面的步骤都没错，此时应该在SpringBoot应用控制台看到大量的OOM错误，如下图所示：

然后在 GC 日志里面会看到，触发 GC 的前后，Old 区几乎都没有空间，仅有的一点点还是JDK强行分配的（在启动JVM时强制覆写了我们的-Xmn参数）：
  1. {Heap before GC invocations=279 (full 139):
  2. PSYoungGen      total 458752K, used 273877K [0x00000000e0080000, 0x0000000100000000, 0x0000000100000000)
  3.   eden space 393728K, 69% used [0x00000000e0080000,0x00000000f0bf5798,0x00000000f8100000)
  4.   from space 65024K, 0% used [0x00000000fc080000,0x00000000fc080000,0x0000000100000000)
  5.   to   space 65024K, 0% used [0x00000000f8100000,0x00000000f8100000,0x00000000fc080000)
  6. ParOldGen       total 512K, used 506K [0x00000000e0000000, 0x00000000e0080000, 0x00000000e0080000)
  7.   object space 512K, 98% used [0x00000000e0000000,0x00000000e007e910,0x00000000e0080000)
  8. Metaspace       used 35959K, capacity 38240K, committed 38872K, reserved 1083392K
  9.   class space    used 4533K, capacity 4953K, committed 5080K, reserved 1048576K
  10. 2023-04-07T01:44:25.348+0800: 57.446: [GC (Allocation Failure) --[PSYoungGen: 273877K->273877K(458752K)] 274384K->274384K(459264K), 0.0441401 secs] [Times: user=0.06 sys=0.30, real=0.04 secs]
  11. Heap after GC invocations=279 (full 139):
  12. PSYoungGen      total 458752K, used 273877K [0x00000000e0080000, 0x0000000100000000, 0x0000000100000000)
  13.   eden space 393728K, 69% used [0x00000000e0080000,0x00000000f0bf5798,0x00000000f8100000)
  14.   from space 65024K, 0% used [0x00000000fc080000,0x00000000fc080000,0x0000000100000000)
  15.   to   space 65024K, 9% used [0x00000000f8100000,0x00000000f86e2070,0x00000000fc080000)
  16. ParOldGen       total 512K, used 506K [0x00000000e0000000, 0x00000000e0080000, 0x00000000e0080000)
  17.   object space 512K, 98% used [0x00000000e0000000,0x00000000e007e910,0x00000000e0080000)
  18. Metaspace       used 35959K, capacity 38240K, committed 38872K, reserved 1083392K
  19.   class space    used 4533K, capacity 4953K, committed 5080K, reserved 1048576K
  20. }
  21. {Heap before GC invocations=280 (full 140):
  22. PSYoungGen      total 458752K, used 273877K [0x00000000e0080000, 0x0000000100000000, 0x0000000100000000)
  23.   eden space 393728K, 69% used [0x00000000e0080000,0x00000000f0bf5798,0x00000000f8100000)
  24.   from space 65024K, 0% used [0x00000000fc080000,0x00000000fc080000,0x0000000100000000)
  25.   to   space 65024K, 9% used [0x00000000f8100000,0x00000000f86e2070,0x00000000fc080000)
  26. ParOldGen       total 512K, used 506K [0x00000000e0000000, 0x00000000e0080000, 0x00000000e0080000)
  27.   object space 512K, 98% used [0x00000000e0000000,0x00000000e007e910,0x00000000e0080000)
  28. Metaspace       used 35959K, capacity 38240K, committed 38872K, reserved 1083392K
  29.   class space    used 4533K, capacity 4953K, committed 5080K, reserved 1048576K
  30. 2023-04-07T01:44:25.392+0800: 57.490: [Full GC (Ergonomics) [PSYoungGen: 273877K->142631K(458752K)] [ParOldGen: 506K->506K(512K)] 274384K->143137K(459264K), [Metaspace: 35959K->35959K(1083392K)], 0.0248171 secs] [Times: user=0.14 sys=0.00, real=0.03 secs]
复制代码
接着无需改动任何代码，我们调整下启动参数，像这样：
  1. java -Xms512m -Xmx512m -Xmn64m -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar oom-1.0.0-RELEASE.jar
复制代码
你会发现它又可以了。这是一个为了验证而打造的极端例子，实际上生产的应用情况会比这个复杂得多，但这并不妨碍我们理解它的意图。
0x04 事故复盘

这是一场典型的”人祸“，来源于某个同事的”调优“，比起追究责任，更重要的是带给我们的启发：
0x05 事故影响

造成C公司关键业务停摆半小时，生产系统紧急回滚一次。A公司相关负责人连夜编写事故报告一份。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4