JVM堆配置小于8G的参数一套

测试环境部署应用时, 收到邮件提示: 推荐我配置如下:

JVM堆配置小于8G,推荐开启CMS垃圾收集器,开启方法:在env中的APP_OPTS中增加JVM参数

-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80

-XX:+UseParNewGC
#缺省#

设置年轻代为并行收集。可与CMS收集同时使用。
JDK5.0以上,JVM会根据系统配置自行设置,所以无需再设置此值。

-XX:+UseConcMarkSweepGC
#年老代使用并发标记清除GC#

设置年老代为CMS并发收集。

CMS流程:

– 初始标记(CMS-initial-mark)

– 并发标记(CMS-concurrent-mark)

– 重新标记(CMS-remark)

– 并发清除(CMS-concurrent-sweep)

并发重设状态等待下次CMS的触发(CMS-concurrent-reset)。

老年代使用CMS垃圾收集器:

  1. 特点:以最短回收停顿时间为目标, B/S, 互联网java应用, 重视服务响应速度场景
  2. 收集算法: MS=Mark Sweep
  3. 四步骤:
  • 初始标记(STW) – initMark
  • 并发标记 – concurrentMark
  • 重新标记(STW) – remark
  • 并发清除 – concurrentSweep
-XX:+CMSParallelRemarkEnabled

降低标记停顿

CMS开启并行remark

在使用UseParNewGC的情况下,尽量减少mark的时间

-XX:+UseCMSCompactAtFullCollection
#在Full收集时使用CMS压缩#

[kəmˈpækt]v. 把……压实;使简洁;使紧密,压缩;

标记-清除的算法, 在收集结束时, 会有大量碎片空间, 碎片过多, 将会给大内存分配造成麻烦, 不得不提前出发一次 FullGC;

CMS收集器提供了个参数: UseCMSCompactAtFullCollection开关参数(默认即开启), 用于在CMS收集器顶不住要进行FullGC时,开启内存碎片的合并整理过程(无法并发).

这样, 空间碎片虽然没有了, 但是STW停顿不得不变长(但是减少了一次FullGC呀!)

打开对年老代的压缩。可能会影响性能,但是可以消除碎片

-XX:+UseCMSInitiatingOccupancyOnly
#仅使用CMS启动占用#

[ˈɑːkjəpənsi]n. 居住/占有/占用

[ɪˈnɪʃieɪt]vt. 开始/创始/发起

表示 CMS GC 只基于 CMSInitiatingOccupancyFraction 触发,

如果未设置该参数则: JVM只会根据 CMSInitiatingOccupancyFraction
触发第一次CMS GC,后续还是会自动触发。

建议同时设置这两个参数。

-XX:CMSInitiatingOccupancyFraction=80
#CMS启动占用分数#

默认老年代使用了68%内存空间以后就会激活, 比较保守, (若应用中老年代增长不是太快), 可以适当调高参数, 以降低内存回收次数从而获得好的性能;

也可根据实际情况,使用G1作为垃圾收集器:-XX:+UseG1GC;

其他相关:

-XX:+CMSScavengeBeforeRemark

强制remark之前开始一次minor gc,减少remark的暂停时间。

原文 

https://segmentfault.com/a/1190000022492236

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » JVM堆配置小于8G的参数一套

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址