记一次中间件宕机以后持续请求导致应用OOM的排查思路(server.max-http-header-size属性配置不当的严重后果)

一、背景

最近有一次在系统并发比较高的时候,数据库突然发生了故障,导致大量请求失败,在数据库宕机不久,通过应用日志可以看到系统发生了OOM。

二、排查

初次看到这个现象的时候,我还是有点懵逼的,数据库宕机以后为什么会导致应用发生OOM呢?

不管怎么样,先按照传统思路,分析一下应用此时的dump文件。

通过MemoryAnalyzer工具进行dump文件分析,通过Leak Suspects页面可以发现,有两个可以点,如下:

system class loader看起来没有什么问题,org.apache.coyote.http11.Http11OutputBuffer对象占用这么多内存倒是真的可疑。

打开MemoryAnalyzer工具Dominator Tree页面,过滤org.apache.coyote.http11.Http11OutputBuffer,截图如下:

可以看到,内存中有大量org.apache.coyote.http11.Http11OutputBuffer对象,同时每个对象都持有一个2048000长度的字节数据。

通过在IDEA中对org.apache.coyote.http11.Http11OutputBuffer对象的引用发现,Http11OutputBuffer是用于tomcat处理请求时,用于每个请求处理时都会生成,代码如下:

powershell 复制代码
org.apache.coyote.http11.Http11Processor#Http11Processor

进入protocol.getMaxHttpRequestHeaderSize()方法:

进入getMaxHttpHeaderSize()方法:

可以看到maxHttpHeaderSize属性值默认是8192字节,怎么变成了上面的2048000长度了呢?

通过debug代码可以发现,在org.springframework.boot.autoconfigure.web.embedded.TomcatWebServerFactoryCustomizer#customizeMaxHttpHeaderSize方法中会进行覆盖设置,如果你在配置文件中配置了server.max-http-header-size属性,那么maxHttpHeaderSize默认的8192就会被覆盖。

同时,根据org.apache.coyote.http11.Http11Processor#Http11Processor源码,发现每次请求时也都会创建org.apache.coyote.http11.Http11InputBuffer对象,于是我又在MemoryAnalyzer工具Dominator Tree页面搜索了Http11InputBuffer类,如下:

此时,我发现为什么Http11InputBuffer对象持有的buffer大小不是2048000而是2056192,整整大了8192呢?

通过debug可以发现,答案可以在org.apache.coyote.http11.Http11InputBuffer#init方法中找到:

在Http11InputBuffer对象中,buffer大小除了设置的size之外,还会加一个wrapper.getSocketBufferHandler().getReadBuffer().capacity(),通过代码调试可以发现,SocketBufferHandler的设置在org.apache.tomcat.util.net.NioEndpoint#setSocketOptions方法中进行的:

进入org.apache.tomcat.util.net.SocketProperties可以发现,buff的默认大小就是8192:

此时,问题排查基本结束了,排查中遇到的疑问也基本解决了。

三、原因

通过上面的分析可以发现,由于有人在配置文件中设置了server.max-http-header-size属性,

yaml 复制代码
server:
  max-http-header-size: 2048000

覆盖了默认的8KB大小,导致每次请求创建的Http11InputBuffer和Http11OutputBuffer对象持有的buffer大小增加到2MB,在数据库宕机以后,tomcat还在继续接受请求,由于请求响应阻塞,同时此时会有大量请求进行堆积,但是每次请求都会创建Http11InputBuffer和Http11OutputBuffer对象,同时会向JVM申请内存,导致JVM内存使用量急剧增加,从而导致OOM。

四、问题解决

找到问题原因以后,有点好奇,为什么要修改server.max-http-header-size属性呢?通过内部排查得知,原来是应用提供的某个接口是GET请求方式,在请求URL中拼接的参数过大的时候会报Request header is too large异常信息。

看到这个异常信息有点奇怪,为什么GET请求会有这个错误呢,为什么修改server.max-http-header-size属性可以解决呢?通过代码debug发现,Http11InputBuffer对象其实处理的是整个请求报文,包括请求头、请求行等信息,所以GET方式请求URL大小和请求头大小都会被Http11InputBuffer对象持有的buffer大小限制,因此修改server.max-http-header-size属性确实可以解决GET请求方式由于URL过长导致的Request header is too large异常问题。

最后,将该GET请求方式接口修改成了POST方式请求,参数传递也通过请求体进行,删除配置文件中

server.max-http-header-size属性配置,恢复默认值8192,在测试环境进行测试,发现OOM问题可以解决。不过,虽然程序层面问题解决了,不过数据库稳定性问管理还需要进一步加强。

相关推荐
颜进强14 分钟前
22 · NestJs InjectionScopes 注入作用域:默认单例不是偷懒,是最优——以及何时才该打破
前端·后端·ai编程
ShineWinsu18 分钟前
对于Redis:缓存的解析
java·redis·缓存·缓存穿透·缓存击穿·缓存雪崩·缓存预热
rannn_11126 分钟前
【Java面试题】高频面试题1|Java 后端、MySQL、Redis 与 RAG 面试整理
java·jvm·数据库·后端·面试
写后端的胖头鱼29 分钟前
一文详解Spring 事务失效场景
java·spring·事务·transactional·事务传播机制
Q264336502334 分钟前
【有源码】基于Spring Boot和Vue的在线考试与交流系统-教育信息化背景下在线考试与交流一体化平台
java·vue.js·spring boot·mysql·spring·毕业设计·课程设计
拖孩39 分钟前
一个全程 AI 写的小程序「厨菜记」,上线 20 天跑通流量主,收入几块钱,开心得不行
前端·后端·微信小程序
颜进强41 分钟前
21 · NestJs AsyncProviders 异步提供者:useFactory 返回 Promise 之后,容器发生了什么
前端·后端·ai编程
Mikko71 小时前
JVM 线上排查实战(七):jps 看不到进程、jstack 报不允许的操作怎么办?attach 失败的六种情况实测
java·运维·jvm·后端
jianjinwssy1 小时前
MyBatis-Plus 从入门到实战:常用功能与核心原理
java·mybatis
会编程的吕洞宾1 小时前
Spring AI 2.0 会话记忆实战,让 AI 助手记住每一次对话
java·人工智能·spring