GC 时间过长的优化一般思路

2022年9月3日 38次阅读 来源: 撸智深

JVM 的调优首要任务就是缩短GC 时stop working 的时间。下面是GC分析、调优的一般思路。

发现分析的过程：

用户、运维反映、XX页面卡顿->前端人员分析页面代码没问题。->继续分析XX数据接口相应的时间太长

->反映给后台开发->后台开发本地测试-> 相应时间正常-> 测试线上的接口-> 相应时间过长-> 分析一般系统日志->发现SQL查询时间正常、但是相关的业务代码执行时间过长。

此时怀疑GC时间过长导致程序停顿->通过在线工具gceasy.io 分析GC日志 

这个工具会告诉你对象的创建速度，下图中‘Object Stats’里面的 ‘Avg creation rate’ 就是对象的平均创建速度。要让这个值尽可能的小。

 《GC 时间过长的优化一般思路》

 分析Young区大小：

如果Young过小，对象就会过早的晋升到Old区，Old区的垃圾回收一般比Young区会花费更多的时间，因此，可以通过增大Young区来有效的降低长时间GC停顿。可以用下面两个JVM参数来设置Young区的大小：
-Xmn: 设置Young区所占的字节数
-XX:NewRatio: 设置Old区和Young区的比例，比如说，-XX:NewRatio=3也就是说Old区和Young区的比例是3:1，Young区占整个堆的1/4，如果堆是2G，那么Young区就是0.5G。

young 区大小也应该结合具体的业务来分析、比如秒杀业务，会频繁创建订单对象、这时young区过小会频繁导致young区的频繁GC,虽然young区的GC时间短、但是在这种秒杀场景下对于用户而言也是较长的等待。这时考虑是否能将young 区比例设置大一点、来降低GC频率。

合适的垃圾收集器：

若系统的并发量一般、大多数情况下可以设置为G1。因为G1自动调优的特性可以为我们减少很多的工作。我们可以设置

 -XX:MaxGCPauseMillis=200 这个例子设置了最大停顿时间的目标是200ms，JVM会尽最大努力来满足这个目标。

GC线程数过少

GC日志中的每一个GC事件都会打印user、sys、real time，比如：

[Times: user=25.56 sys=0.35, real=20.48 secs]
  • 1

这几个时间的区别可以查看前面文章：GC日志中sys时间比user时间长该如何处理？GC日志中real时间比user+sys时间长该如何处理？如果GC日志中，real time并不是明显比user time小，这就说明GC线程数是不够的，这就需要增加GC线程了。假如说，user time是25秒，GC线程数是5，那么real time大概是5左右才是正常的（25/5=5）。
注意：GC线程过多会占用大量的系统CPU，从而会影响应用能使用的CPU资源，因此增加GC线程之前一定要做好测试才可以。

4.进程被交换（Swap）出内存 

有时候由于系统内存不足，操作系统会把你的应用从内存中交换出去。Swap是非常耗时的，因为需要访问磁盘，相对于访问物理内存来说要慢得多的多。我认为生产环境下的应用是不应该被Swap出内存的。当发生进程Swap的时候，GC停顿时间也会变长。
下面是从stackoverflow上引用的一个脚本，它能够列出被Swap出内存的进程，要确保你的应用没有被Swap出内存。


#!/bin/bash 
# Get current swap usage for all running processes
# Erik Ljungstrom 27/05/2011
# Modified by Mikko Rantalainen 2012-08-09
# Pipe the output to "sort -nk3" to get sorted output
# Modified by Marc Methot 2014-09-18
# removed the need for sudo

SUM=0
OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"`
do
    PID=`echo $DIR | cut -d / -f 3`
    PROGNAME=`ps -p $PID -o comm --no-headers`
    for SWAP in `grep VmSwap $DIR/status 2>/dev/null | awk '{ print $2 }'`
    do
        let SUM=$SUM+$SWAP
    done
    if (( $SUM > 0 )); then
        echo "PID=$PID swapped $SUM KB ($PROGNAME)"
    fi
    let OVERALL=$OVERALL+$SUM
    SUM=0
done
echo "Overall swap used: $OVERALL KB"

如果很不幸你的应用被Swap了，你需要：
a:给机器增加内存
b:减少机器上运行的进程数，以释放更多的内存
c:减少应用分配的内存（不推荐，可能会引起其他问题）

.IO负载重

如果系统的IO负载很重（大量的文件读写）也会导致GC停顿时间过长。这些IO读写不一定是你的应用引起的，可能是机器上其他的进程导致的，但是这仍然会导致你的应用的停顿时间变长。这里有个文章详细的说明了这种情况：https://engineering.linkedin.com/blog/2016/02/eliminating-large-jvm-gc-pauses-caused-by-background-io-traffic。当IO负载很重的时候，real time会明显比user time长，比如：

显式调用了System.gc()

当调用了System.gc()或者是Runtime.getRuntime().gc()以后，就会导致FullGC。FullGC的过程当中，整个JVM是暂停的（所有的应用都被暂停掉）。System.gc()可能是以下几种情况产生的：
a:应用的程序员手动调用了System.gc()
b:应用引用的三方库或者框架甚至是应用服务器可能调用了System.gc()
c:可能是由外部使用了JMX的工具触发，比如：JVisualVM。
d:如果你的应用使用了RMI，RMI会每隔一段时间调用一次System.gc()，这个时间间隔是可以设置的：

– Dsun.rmi.dgc.server.gcInterval=n
– Dsun.rmi.dgc.client.gcInterval=n
  • 1
  • 2

要评估一下，是否真的有必要明确调用System.gc()。如果没有必要，就不要调用。同时，你也可以通过给JVM传递‘-XX:+DisableExplicitGC‘参数来禁用掉System.gc()。关于System.gc()的问题和解决方案可以参考：https://blog.gceasy.io/2016/11/22/system-gc/
tip：如何知道是否手动调用了System.gc()?可以把GC日志上传到gceasy，如果有手动调用System.gc()，在‘GC Causes’中就会展示出来，如图：
《GC 时间过长的优化一般思路》上图说明发生了4次System.gc()调用。

 

[Times: user=0.20 sys=0.01, real=18.45 secs]
  • 1

如果发生了这种情况，可以这么办：
a:如果是你的应用导致的，优化你的代码
b:如果是别的进程导致的，把它杀掉或者迁走
c:把你的应用迁到一个IO负载小的机器上
tip：如何来监控IO负载？在linux上可以用sar命令来监控IO的负载：sar -d -p 1，这个命令每隔一秒会打印一次每秒的读写数量。这里有sar的详细的用法：https://www.linuxtechi.com/generate-cpu-memory-io-report-sar-command/

堆内存过大

堆内存过大也会导致GC停顿时间过长，如果堆内存过大，那么堆中就会累计过多的垃圾，当发生FullGC要回收所有的垃圾的时候，就会花费更多的时间。如果你的JVM的堆内存有18G，可以考虑分成3个6G的JVM实例，堆内存小会降低GC的停顿时间。
注意：在应用以上任何一种策略之前，都需要做好测试，这些策略对你可能都不适用，如果使用不当可能带来负面效果。

GC任务分配不均

就算有多个GC线程，线程之间的任务分配可能也不是均衡的，这个可能有很多种原因：
a:扫描大的线性的数据结构目前是无法并行的。
b:有些GC事件只发生在单个线程上，比如CMS中的‘concurrent mode failure’。如果你碰巧使用的CMS，可以使用-XX:+CMSScavengeBeforeRemark 这个参数，它可以让多个GC线程之间任务分配的更平均

    原文作者：撸智深
    原文地址: https://blog.csdn.net/m0_37163942/article/details/106242156
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞