JVM-性能调优(2)

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/wgh1015398431/article/details/53034711

在调优之前,我们需要记住下面的原则:

  • 多数的Java应用不需要在服务器上进行GC优化;
  • 多数导致GC问题的Java应用,都不是因为我们参数设置错误,而是代码问题;
  • 在应用上线之前,先考虑将机器的JVM参数设置到最优(最适合);
  • 减少创建对象的数量;
  • 减少使用全局变量和大对象;
  • GC优化是到最后不得已才采用的手段;

在实际使用中,分析GC情况优化代码比优化GC参数要多得多。

GC优化的目的有两个:

  • 将转移到老年代的对象数量降低到最小;
  • 减少full GC的执行时间。

为了达到上面的目的,一般地,你需要做的事情有:

  • 减少使用全局变量和大对象;
  • 调整新生代的大小到最合适;
  • 设置老年代的大小为最合适;
  • 选择合适的GC收集器;

在上面的4条方法中,用了几个“合适”,那究竟什么才算合适,一般的,请参考前面两篇博文中“收集器搭配”和“启动内存分配”两节中的建议。但这些建议不是万能的,需要根据您的机器和应用情况进行发展和变化,实际操作中,可以将两台机器分别设置成不同的GC参数,并且进行对比,选用那些确实提高了性能或减少了GC时间的参数。

真正熟练的使用GC调优,是建立在多次进行GC监控和调优的实战经验上的,进行监控和调优的一般步骤为:

1、监控GC的状态
使用各种JVM工具,查看当前日志,分析当前JVM参数设置,并且分析当前堆内存快照和gc日志,根据实际的各区域内存划分和GC执行时间,觉得是否进行优化;

2、分析结果,判断是否需要优化
如果各项参数设置合理,系统没有超时日志出现,GC频率不高,GC耗时不高,那么没有必要进行GC优化;如果GC时间超过1-3秒,或者频繁GC,则必须优化;
注:如果满足下面的指标,则一般不需要进行GC:

   Minor GC执行时间不到50ms;
   Minor GC执行不频繁,约10秒一次;
   Full GC执行时间不到1s;
   Full GC执行频率不算频繁,不低于10分钟1次;

3,调整GC类型和内存分配
如果内存分配过大或过小,或者采用的GC收集器比较慢,则应该优先调整这些参数,并且先找1台或几台机器进行beta,然后比较优化过的机器和没有优化的机器的性能对比,并有针对性的做出最后选择。

4,不断的分析和调整
通过不断的试验和试错,分析并找到最合适的参数。

5,全面应用参数
如果找到了最合适的参数,则将这些参数应用到所有服务器,并进行后续跟踪。

调优实例

上面的内容都是纸上谈兵,下面我们以一些真实例子来进行说明:
实例1:
笔者昨日发现部分开发测试机器出现异常:java.lang.OutOfMemoryError: GC overhead limit exceeded,这个异常代表:GC为了释放很小的空间却耗费了太多的时间,其原因一般有两个:

  • 堆太小
  • 有死循环或大对象;

笔者首先排除了第2个原因,因为这个应用同时是在线上运行的,如果有问题,早就挂了。所以怀疑是这台机器中堆设置太小;使用ps -ef |grep “java”查看,发现:

-Xms=768m -Xmx=768m -XX:NewSize=320m -XX:MaxNewSize=320m

该应用的堆区设置只有768m,而机器内存有2g,机器上只跑这一个java应用,没有其他需要占用内存的地方。另外,这个应用比较大,需要占用的内存也比较多。

-Xms=1280m -Xmx=1280m -XX:NewSize=500m -XX:MaxNewSize=500m

笔者通过上面的情况判断,只需要改变堆中各区域的大小设置即可,于是改成下面的情况:

跟踪运行情况发现,相关异常没有再出现;

实例2:
一个服务系统,经常出现卡顿,分析原因,发现Full GC时间太长:
jstat -gcutil:
S0 S1 E O P YGC YGCT FGC FGCT GCT
12.16 0.00 5.18 63.78 20.32 54 2.047 5 6.946 8.993

分析上面的数据,发现Young GC执行了54次,耗时2.047秒,每次Young GC耗时37ms,在正常范围,而Full GC执行了5次,耗时6.946秒,每次平均1.389s,数据显示出来的问题是:Full GC耗时较长,分析该系统的是指发现,NewRatio=9,也就是说,新生代和老生代大小之比为1:9,这就是问题的原因:

  • 新生代太小,导致对象提前进入老年代,触发老年代发生Full GC;
  • 老年代较大,进行Full GC时耗时较大.

优化的方法是调整NewRatio的值,调整到4,发现Full GC没有再发生,只有Young GC在执行。这就是把对象控制在新生代就清理掉,没有进入老年代(这种做法对一些应用是很有用的,但并不是对所有应用都要这么做)

实例3:
一应用在性能测试过程中,发现内存占用率很高,Full GC频繁,使用“sudo -u admin -H jmap -dump:format=b,file=文件名.hprof pid “来dump内存,生成dump文件,并使用Eclipse下的mat差距进行分析,发现:

这里写图片描述
从图中可以看出,这个线程存在问题,队列LinkedBlockingQueue所引用的大量对象并未释放,导致整个线程占用内存高达378m,此时通知开发人员进行代码优化,将相关对象释放掉即可。

展开阅读全文

没有更多推荐了,返回首页