压测时频繁full-gc问题排查
jmeter压测
arthas排查
Current VM java version: 11 do not match target VM java version: 1.8, attach may fail.
提示错误 启动服务时选择JDK11
列出1000ms内最忙的3个线程栈 发现GC线程一直在运行
dump live对象到指定文件
MAT分析工具
打开提示:The JVM shared library "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/../lib/server/libjvm.dylib" does not contain the JNI_CreateJavaVM symbol.
在应用列表,找到MAT.app,然后右键单击后,选择“显示包内容” 进入Contents目录 ,修改Info.plist
文件
注意:新版本的MAT(1.12版本)必须配置Oracle JDK11。使用zulu jdk也会报错
配置完重新打开MAT 选择 File - OPEN DUMP 文件
可以看到每个请求占用了4M的内存,由于当前服务设置了内存大小512M。 当请求并发数上来后必定发生GC
问题排查
看OOM日志可以发现都是tomcat相关的代码在报错,大概率是相关配置出现问题。查看服务相关配置 发现设置了
该参数用来设置http请求头的大小,默认值为8k,也就是8 * 1024的大小。
那么,什么时候会配置max-http-header-size参数呢?
比如,当我们上传图片时采用multipart形式上传文件时,对应的配置如下
但这个配置针对base64形式上传图片就不适用了,需要如下配置:
但这样的配置就很容易造成OOM。
之所以该参数配置过大,在并发的时候会造成OOM是因为Http请求时内存分配的问题。
比如将max-http-header-size
的大小配置为4M,那么并发量100时,那么内存分配就是4 * 100,将近400M。
翻看源码会发现,该参数会被用于ByteBuffer.allocate
的调用,ByteBuffer.allocate就是生成一个指定长度的字节数组,也就是说这个bufLength有多大,这个字节数组就有多长,而bufLength又是headerBufferSize加上了某个值。如果headerBufferSize=102400,那么这个地方就会生成一个至少102400长度的字节数组,这非常消耗内存。
同时大对象会被直接放入老年代,引发full GC等。
所以当并发量比较大时,会迅速消耗掉内存,甚至造成OOM。
重新压测
修改配置max-http-header-size: 8096
重新压测 使用jvisualvm 报错
下载单独的jvisualvm 软件:
https://visualvm.github.io/download.html
安装GC插件
离线安装
https://visualvm.github.io/pluginscenters.html
进入页面选择对应插件下载
在线安装
查看GC情况 发现现在并发100可以平稳运行
__EOF__

本文链接:https://www.cnblogs.com/mpyidudu/p/15797255.html
关于博主:评论和私信会在第一时间回复。或者直接私信我。
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
声援博主:如果您觉得文章对您有帮助,可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· winform 绘制太阳,地球,月球 运作规律
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了
· 【硬核科普】Trae如何「偷看」你的代码?零基础破解AI编程运行原理
· 超详细:普通电脑也行Windows部署deepseek R1训练数据并当服务器共享给他人
· AI与.NET技术实操系列(五):向量存储与相似性搜索在 .NET 中的实现