记一次线上OOM 问题排查过程！

ゞ浴缸里的玫瑰 2024-04-18 15:29 87阅读 0赞

公众号后台回复“**学习**”，获取作者独家秘制精品资料

![640?wx\_fmt=png][640_wx_fmt_png]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

扫描下方海报二维码，试听课程：

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 1]

![640?wx\_fmt=png][640_wx_fmt_png]

上周运维反馈线上程序出现了OOM，程序日志中的输出为

Exception in thread "http-nio-8080-exec-1027" java.lang.OutOfMemoryError: Java heap space
    Exception in thread "http-nio-8080-exec-1031" java.lang.OutOfMemoryError: Java heap space

看线程名称应该是tomcat的nio工作线程，线程在处理程序的时候因为无法在堆中分配更多内存出现了OOM

幸好JVM启动参数配置了-XX:+HeapDumpOnOutOfMemoryError，使用MAT打开拿到的hprof文件进行分析。

第一步就是打开Histogram看看占用内存最大的是什么对象：

![640?wx\_fmt=png][640_wx_fmt_png 1]

可以看到byte数组占用了接近JVM配置的最大堆的大小也就是8GB，显然这是OOM的原因。

第二步看一下究竟是哪些byte数组，数组是啥内容：

![640?wx\_fmt=png][640_wx_fmt_png 2]

可以看到很明显这和HTTP请求相关，一个数组大概是10M的大小。

第三步通过查看GC根查看谁持有了数组的引用：

![640?wx\_fmt=png][640_wx_fmt_png 3]

这符合之前的猜测，是tomcat的线程在处理过程中分配了10M的buffer在堆上。

至此，马上可以想到一定是什么参数设置的不合理导致了这种情况，一般而言tomcat不可能为每一个请求分配如此大的buffer。

第四步就是检查代码里是否有tomcat或服务器相关配置，看到有这么一个配置：

至此，基本已经确定了八九不离十就是这个不合理的最大http请求头参数导致的问题。

到这里还有3个疑问：

1.  即使一个请求分配10M内存，堆有8GB，难道当时有这么多并发吗？800个tomcat线程？
2.  参数只是设置了最大请求头10M，为什么tomcat就会一次性分配这么大的buffer呢？
3.  为什么会有如此多的tomcat线程？感觉程序没这么多并发。

先来看问题1，这个可以通过MAT在dump中继续寻找答案。

可以打开线程视图，搜索一下tomcat的工作线程，发现线程数量的确很多有401个，但是也只是800的一半：

![640?wx\_fmt=png][640_wx_fmt_png 4]

再回到那些大数组的清单，按照堆分配大小排序，往下看：

![640?wx\_fmt=png][640_wx_fmt_png 5]

可以发现除了有10008192字节的数组还有10000000字节的数组，查看引用路径可以看到这个正好是10M的数组是output buffer，区别于之前看到的input buffer：

![640?wx\_fmt=png][640_wx_fmt_png 6]

好吧，这就对了，一个线程分配了输入输出两个buffer，占用20M内存，一共401个线程，占用8GB，所以OOM了。还引申出一个问题：为啥有这么多工作线程！

再来看看问题2，这就需要来找一下源码了，首先max-http-header-size是springboot定义的参数，查看springboot代码，可以看到这个参数对于tomcat设置的是MaxHttpHeaderSize：

![640?wx\_fmt=png][640_wx_fmt_png 7]

然后来看看tomcat源码：

![640?wx\_fmt=png][640_wx_fmt_png 8]

进一步看一下input buffer：

![640?wx\_fmt=png][640_wx_fmt_png 9]

buffer大小是MaxHttpHeaderSize+ReadBuffer大小，后者默认是8192字节：

<attribute name="socket.appReadBufSize" required="false">
            <p>(int)Each connection that is opened up in Tomcat get associated with
            a read ByteBuffer. This attribute controls the size of this buffer. By
            default this read buffer is sized at <code>8192</code> bytes. For lower
            concurrency, you can increase this to buffer more data. For an extreme
            amount of keep alive connections, decrease this number or increase your
            heap size.</p>
          </attribute>

这也就是为什么之前看到大量的buffer是10008192字节的。显然还有一批内容是空的10000000字节的buffer应该是output buffer

来看看源码：

![640?wx\_fmt=png][640_wx_fmt_png 10]

这是一个header buffer，所以正好是10000000字节。

至于问题3，显然我们的应用程序是配置过最大线程的（查看配置后发现的确，我们配置为了2000，好吧有点大），否则也不会有401个工作线程（默认150）

如果当时并发并不大的话就一种可能，请求很慢，虽然并发不大，但是因为请求执行的慢就需要更多线程，比如TPS是100，但是平均RT是4s的话，就是400线程了。

这个问题的答案还是可以通过MAT去找，随便看几个线程可以发现很多线程都在等待一个外部服务的返回，这说明外部服务比较慢

然后去搜索当时的程序日志，可以发现有很多"feign.RetryableException: Read timed out executing的日志"。。。追杀下游去！慢点，我们的feign的timeout也需要再去设置一下，别被外部服务拖死了。

**END**

**如有收获，请划至底部，点击“在看”，谢****谢****！**

![640?wx\_fmt=png][640_wx_fmt_png]

欢迎长按下图关注公众号**石杉的架构笔记**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 2]

**BAT架构经验倾囊相授**

[640_wx_fmt_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/1622cd256b4547d7ad9a0cbf53f4eb60.png
[640_wx_fmt_jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/35e893b639934d928dc66da150899106.png
[640_wx_fmt_jpeg 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/f97d666d3efc435c81c218839640403d.png
[640_wx_fmt_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c304dc66c90744d48407d34ef72dfdad.png
[640_wx_fmt_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/bd83f4e82a5c4852b91d562e93421e97.png
[640_wx_fmt_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/0f5a0162205d47b6bf94d21a11a2f552.png
[640_wx_fmt_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/78c09175077546069ef95434f76935a6.png
[640_wx_fmt_png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/b4861e1ff6c544b28f09162456892892.png
[640_wx_fmt_png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/46e4b1e5d7a643538d94824dd52f146c.png
[640_wx_fmt_png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/6308934214354cc18060c076f61e2ea7.png
[640_wx_fmt_png 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/37115e9bcc704008bf491719a23523fe.png
[640_wx_fmt_png 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/b3c67e7df90e476196c1741036b5ae87.png
[640_wx_fmt_png 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/3264d6c1edb94cdbac53075b4d4d88cc.png
[640_wx_fmt_jpeg 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c12f65a49c07416fa19e5d34fd5fdef6.png