ava垃圾收集调优实战

1 资料

2 GC日志打印

GC调优是个很实验很伽利略的活儿,GC日志是先决的数据参考和最终验证:

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps(GC发生的时间) -XX:+PrintGCApplicationStoppedTime(GC消耗了多少时间) -XX:+PrintGCApplicationConcurrentTime(GC之间运行了多少时间)

3 收集器选择

CMS收集器:暂停时间优先

配置参数:-XX:+UseConcMarkSweepGC
   已默认无需配置的参数:-XX:+UseParNewGC(Parallel收集新生代) -XX:+CMSPermGenSweepingEnabled(CMS收集持久代) -XX:UseCMSCompactAtFullCollection(full gc时压缩年老代)

初始效果:1g堆内存的新生代约60m,minor gc约5-20毫秒,full gc约130毫秒。

Parallel收集器:吞吐量优先

配置参数: -XX:+UseParallelGC -XX:+UseParallelOldGC(Parallel收集年老代,从JDK6.0开始支持)

已默认无需配置的参数: -XX:+UseAdaptiveSizePolicy(动态调整新生代大小)

初始效果:1g堆内存的新生代约90-110m(动态调整),minor gc约5-20毫秒,full gc有无UseParallelOldGC 参数分别为1.3/1.1秒,差别不大。

另外-XX:MaxGCPauseMillis=100 设置minor gc的期望最大时间,JVM会以此来调整新生代的大小,但在此测试环境中对象死的太快,此参数作用不大。

4 调优实战

Parallel收集高达1秒的暂停时间基本不可忍受,所以选择CMS收集器。

在被压测的Mule 2.0应用里,每秒都有大约400M的海量短命对象产生:

  1. 因为默认60M的新生代太小了,频繁发生minor gc,大约0.2秒就进行一次。
  2. 因为CMS收集器中MaxTenuringThreshold(生代对象撑过过多少次minor gc才进入年老代的设置)默认0,存活的临时对象不经过Survivor区直接进入年老代,不久就占满年老代发生full gc。

对这两个参数的调优,既要改善上面两种情况,又要避免新生代过大,复制次数过多造成minor gc的暂停时间过长。

  1. 使用-Xmn调到1/3 总内存。观察后设置-Xmn500M,新生代实际约460m。(用-XX:NewRatio设置无效,只能用 -Xmn)。
  2. 添加-XX:+PrintTenuringDistribution 参数观察各个Age的对象总大小,观察后设置-XX:MaxTenuringThreshold=5。

优化后,大约1.1秒才发生一次minor gc,且速度依然保持在15-20ms之间。同时年老代的增长速度大大减缓,很久才发生一次full gc,

参数定稿:

 -Xms1024m -Xmx1024m -Xmn500m -XX:+UseConcMarkSweepGC   -XX:MaxTenuringThreshold=5  -XX:+ExplicitGCInvokesConcurrent

最后服务处理速度从1180 tps 上升到1380 tps,调整两个参数提升17%的性能还是笔很划算的买卖。

时间: 2024-10-28 15:06:52

ava垃圾收集调优实战的相关文章

Spark&Spark性能调优实战

Spark特别适用于多次操作特定的数据,分mem-only和mem & disk.其中mem-only:效率高,但占用大量的内存,成本很高;mem & disk:内存用完后,会自动向磁盘迁移,解决了内存不足的问题,却带来了数据的置换的消费.Spark常见的调优工具有nman.Jmeter和Jprofile,以下是Spark调优的一个实例分析: 1.场景:精确客户群 对一个容量为300g的客户信息表在spark上进行查询优化,该大宽表有1800多列,有效使用的有20列. 2.优化达到的效果:

JVM 性能调优实战之:一次系统性能瓶颈的寻找过程

玩过性能优化的朋友都清楚,性能优化的关键并不在于怎么进行优化,而在于怎么找到当前系统的性能瓶颈.性能优化分为好几个层次,比如系统层次.算法层次.代码层次...JVM 的性能优化被认为是底层优化,门槛较高,精通这种技能的人比较少.笔者呆过几家技术力量不算弱的公司,每个公司内部真正能够进行 JVM 性能调优的人寥寥无几.甚至没有.如是乎,能够有效通过 JVM 调优提升系统性能的人往往被人们冠以"大牛"."大师"之类的称呼.其实 JVM 本身给我们提供了很多强大而有效的监

JVM 性能调优实战之:使用阿里开源工具 TProfiler 在海量业务代码中精确定位性能代码

本文是<JVM 性能调优实战之:一次系统性能瓶颈的寻找过程> 的后续篇,该篇介绍了如何使用 JDK 自身提供的工具进行 JVM 调优将 TPS 由 2.5 提升到 20 (提升了 7 倍),并准确定位系统瓶颈:我们应用里静态对象不是太多.有大量的业务线程在频繁创建一些生命周期很长的临时对象,代码里有问题.那么问题来了,如何在海量业务代码里边准确定位这些性能代码?本文将介绍如何使用阿里开源工具 TProfiler 来定位这些性能代码,成功解决掉了 GC 过于频繁的性能瓶颈,并最终在上次优化的基础

老男孩教育高端技术沙龙活动分享--JAVA JVM调优实战

本周末举办!,禁止空降,报名截止到5月8日19点报名方式见咨询QQ:  41117397 70271111电话: 01060747396  18911718229 18600338340官方群 246054962 208160987(标明51CTO) 报名条件:1.曾经支持关注老男孩博客及视频的朋友,需提供截图3条以上支持老男孩教育的评论(灌水不算).2.VIP运维班学员月薪低于9000(以提交的OFFER为准)或者没有实际维护JAVA环境(tomcat,resin等)的禁止报名.3.第10期以

Hive调优实战

Hive优化总结 ---by 食人花 优化时,把hive sql当做map reduce程序来读,会有意想不到的惊喜. 理解hadoop的核心能力,是hive优化的根本.这是这一年来,项目组所有成员宝贵的经验总结.   长期观察hadoop处理数据的过程,有几个显著的特征: 1.不怕数据多,就怕数据倾斜. 2.对jobs数比较多的作业运行效率相对比较低,比如即使有几百行的表,如果多次关联多次汇总,产生十几个jobs,没半小时是跑不完的.map reduce作业初始化的时间是比较长的. 3.对su

Tomcat的JVM调优实战

一些调优点在上篇日志中已写到,在此不做说明 直接使用Jmeter进行调优测试吞吐量Code package cn; import java.io.IOException; import java.util.Map; import java.util.WeakHashMap; import javax.servlet.ServletException; import javax.servlet.annotation.WebServlet; import javax.servlet.http.Htt

GC 调优(实战篇) - GC参考手册

本章介绍导致GC性能问题的典型情况.相关示例都来源于生产环境, 为演示需要做了一定长度的精简. 说明: Allocation Rate, 翻译为分配速率, 而不是分配率; 因为不是百分比,而是单位时间内分配的量; 同理, Promotion Rate 翻译为 提升速率; 您应该已经阅读了前面的章节: 垃圾收集简介 - GC参考手册 Java中的垃圾收集 - GC参考手册 GC 算法(基础篇) - GC参考手册 GC 算法(实现篇) - GC参考手册 GC 调优(基础篇) - GC参考手册 GC

UIKit性能调优实战讲解

使用微信扫一扫查看全文干货 作者:bestswifter 在使用UIKit的过程中,性能优化是永恒的话题.很多人都看过分析优化滑动性能的文章,但其中不少文章只介绍了优化方法却对背后的原理避而不谈,或者是晦涩难懂而且读者缺乏实践体验的机会.不妨思考一下下面的问题自己是否有一个清晰的认识: 为什么要把控件尽量设置成不透明的,如果是透明的会有什么影响,如何检测这种影响? 为什么cell中的图片,尽可能要使用正确的大小.格式,如果错误会有什么影响,如何检测这种影响? 为什么设置阴影和圆角有可能影响滑动时

《JVM调优实战-理论篇》

1 理论篇1.1 多功能养鱼塘-JVM内存大鱼塘O(可分配内存): JVM可以调度使用的总的内存数,这个数量受操作系统进程寻址范围.系统虚拟内存总数.系统物理内存总数.其他系统运行所占用的内存资源等因素的制约.小池塘A(堆内存):JVM运行时数据区域,它为类实例和数组分配的内存.堆可以是固定大小的也可以是可变大小的.其中 Heap = {Old + NEW = { Eden , from, to } }.小池塘B(非堆内存):包括所有线程之间共享的一个方法区域和JVM为优化或内部处理所分配的内存