JVM调优实践：大数据量导出调优

不念不忘少年蓝@ 2022-11-11 05:14 206阅读 0赞

### JVM调优实践：大数据量导出调优 ###

*  出现问题
 *  基本指令
 *  查看运行是内存使用情况
 *  计算使用的堆大小
 *  调整调优目标
 *  计算需要的堆大小
 *   *  假设堆大小定位 512M
     *  假设堆大小定位 1024M
 *  总结

# 出现问题 #

本来刚开始按照初次调优的方式进行调优的，结果发现出问题了，原因是查询与导出功能的数据量相对较大导致的

[JVM调优实践：记录初次JVM调优经历][JVM_JVM]

堆大小设置：\-Xmx256m -Xms256m -Xmn96m

嗯，然后就炸了，只能按照实际情况来调整了  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70]

# 基本指令 #

这里就不多做说明了，这里的堆大小设置目的是足够大，因此设置了 1024M，新生代依然占 3/8，经计算为 384M

*  \-XX:+PrintGCDetails
 *  \-XX:+UseConcMarkSweepGC
 *  \-XX:+CMSParallelInitialMarkEnabled
 *  \-XX:+CMSScavengeBeforeRemark
 *  \-Xmx1024m
 *  \-Xms1024m
 *  \-Xmn384m

# 查看运行是内存使用情况 #

为了养成习惯，这里就不用 jconsole 可视化界面进行查看了，直接走命令

**jps：** 查看进程

**jmap -histo:live <pid>：** 打印存货对象，同时会触发 FGC

**jstat -gc <pid> 1000：** 打印内存使用情况，1000 ms 输出一次

先进行一次 FGC，开始打印后，就直接去执行会产生大量内存的功能

*  **S0U：** survivor 0区的使用量
 *  **S1U：** survivor 1区的使用量
 *  **EU：** Eden 区的使用量
 *  **OU：** Old 区的使用量

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 1]

# 计算使用的堆大小 #

首先根据上面的记录，能看到这么两条记录  
![在这里插入图片描述][20210319145659367.png]  
从这里可以看出，这是第一次调用时产生了大量内存，并且没有发生GC，因此我们可以通过这里计算出这一次请求大致产生了多大的内存

后一次新生代的使用量 - 上一次新生代的使用率

**37288.6 + 106008.1 - 4538.7 = 138,758 KB = 135.5M**

也就是说我这次请求产生了 135.5M 的内存

# 调整调优目标 #

如果**S 区相同年龄（每次GC年龄+1）对象的总大小 > S 区总大小的 50%，这些对象以及年龄大于这些对象的对象全部移动到 O 区**。（只要触发 MinorGC 该条件处理过程必然触发）

上面这个是 CMS 对象晋升老年代的规则

根据 E 区与 S 区 占比 8 ：1，我们很容易算出，哪怕在 1024M 堆的情况下，默认每块 S 区的大小为 38.4M，哪怕通过调整 E 区与 S 区的占比，我们也很难让这么大的内存在 S 区中被容纳，除非给予非常大的内存。但很明显针对一个不常用的导出功能，这么做明显是一种浪费，极其的不合适。

调整目标：  
保证老年代的空间足够容纳大对象，并且保证不会触发 Concurrent Mode Failure

# 计算需要的堆大小 #

## 假设堆大小定位 512M ##

老年代大小：512 x 5/8 = 320M

**此时每个大对象占老年代占比：** 135.5 / 320 = 42%

由此可以判断，512M 时候只够容纳两个这样的大对象，说简单点极容易出现老年代不够的情况，因而触发 Concurrent Mode Failure 导致 FGC，应尽可能避免

## 假设堆大小定位 1024M ##

老年代大小：1024 x 5/8 = 640M

**此时每个大对象占老年代占比：** 135.5 / 640 = 21%

由于可知，当堆为 1024M 时，只要我保证每次老年代只要达到 70% 就进行 GC，就不会导致这个大对象从而触发 FGC

**调整 VM 参数：**

*  **-Xmx1024m**
 *  **-Xms1024m**
 *  **-Xmn384m**
 *  **-XX:CMSInitiatingOccupancyFraction=70：** 设置老年代使用率达到 70% 时候，触发 GC，
 *  **-XX:+UseCMSInitiatingOccupancyOnly：** 仅使用上面设置的阈值进行GC，不动态调整

# 总结 #

由于调优做的不多，如果哪里有不准确或者不对的麻烦指出

中间临时改变了调优目标，由此可见，调优这东西确实看经验

剩下的就配置好后打包上线测试，看看整体运行情况了

[JVM_JVM]: https://linjinp.blog.csdn.net/article/details/114531490/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70]: /images/20221022/99394a6fc3f44f9d8a37473f770570e0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210319143718779.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz,size_16,color_FFFFFF,t_70
[20210319145659367.png]: https://img-blog.csdnimg.cn/20210319145659367.png