压测时频繁full-gc问题排查

2023-09-26 22:10:10

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。

码农公寓

jmeter压测

arthas排查

MAT分析工具

问题排查

相关文章