压测时频繁full-gc问题排查
作者:互联网
jmeter压测
配置线程组
配置压测接口
执行压测后 可以发现后台一直在报OOM
arthas排查
# 安装 arthas
sudo curl -O https://arthas.aliyun.com/arthas-boot.jar
# 执行
java -jar arthas-boot.jar
选择对应的Java线程
Current VM java version: 11 do not match target VM java version: 1.8, attach may fail.
提示错误 启动服务时选择JDK11
列出1000ms内最忙的3个线程栈 发现GC线程一直在运行
[arthas@38198]$ thread -n 3 -i 1000
"GC Thread#3" [Internal] cpuUsage=47.06% deltaTime=473ms time=5430ms
"GC Thread#6" [Internal] cpuUsage=46.34% deltaTime=465ms time=5383ms
"GC Thread#4" [Internal] cpuUsage=45.71% deltaTime=459ms time=5358ms
dump live对象到指定文件
heapdump --live /tmp/dump.hprof
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相关的代码在报错,大概率是相关配置出现问题。查看服务相关配置 发现设置了
server:
max-http-header-size: 4194304
该参数用来设置http请求头的大小,默认值为8k,也就是8 * 1024的大小。
那么,什么时候会配置max-http-header-size参数呢?
比如,当我们上传图片时采用multipart形式上传文件时,对应的配置如下
spring.http.multipart.max-file-size=20Mb
spring.http.multipart.max-request-size=60Mb
但这个配置针对base64形式上传图片就不适用了,需要如下配置:
server.maxHttpHeaderSize=102400
server.maxHttpPostSize =102400
但这样的配置就很容易造成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。
标签:full,http,max,配置,GC,测时,arthas,gc,size 来源: https://www.cnblogs.com/mpyidudu/p/15797255.html