谈JVM xmx, xms等内存相关参数合理性设置

jvm,xmx,xms,内存,相关,参数,合理性,设置 · 浏览次数 : 140

小编点评

**容器 CPU核数 124816** **推荐值:** -XX:ParallelGCThreads=8 -XX:ConcGCThreads=2 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/export/Logs **注意:** * 以上推荐值仅供参考,具体大小可以根据您的实际需求进行调整。 * 在使用 JRE8 版本之前,请确保将 -XX:ParallelGCThreads 参数设置为 8,因为默认值会比较大。

正文

作者:京东零售 刘乐

说到JVM垃圾回收算法的两个优化标的:吞吐量和停顿时长,并提到这两个优化目标是有冲突的。那么有没有可能提高吞吐量而不影响停顿时长,甚至缩短停顿时长呢?答案是有可能的,提高内存占用(Memory Footprint)就有可能同时优化这两个标的,这篇文章就来聊聊内存相关内容。

内存占用一般指应用运行需要的所有内存,包括堆内内存(On-heap Memory)和堆外内存(Off-heap Memory)

1. 堆内内存

堆内内存是分配给JVM的部分内存,用来存放所有Java Class对象实例和数组,JVM GC操作的就是这部分内容。我们先来回顾一下堆内内存的模型:

图1. 堆内内存

堆内内存包括年轻代(浅绿色),老年代(浅蓝色),在JDK7或者更老的版本,图中右边还有个永久代(永久代在逻辑上位于JVM的堆区,但又被称为非堆内存,在JDK8中被元空间取代)。JVM有动态调整内存策略,通过-Xms,-Xmx 指定堆内内存动态调整的上下限。 在JVM初始化时实际只分配部分内存,可通过-XX:InitialHeapSize指定初始堆内存大小,未被分配的空间为图中virtual部分。年轻代和老年代在每次GC的时候都有可能调整大小,以保证存活对象占用百分比在特定阈值范围内,直到达到Xms指定的下限或Xms指定的上限。(阈值范围通过-XX:MinHeapFreeRatio, XX:MaxHeapFreeRatio指定,默认值分别为40, 70)。

GC调优中还有个的重要参数是老年代和年轻代的比例,通过-XX:NewRatio设定,与此相关的还有-XX:MaxNewSize和-XX:NewSize,分别设定年轻代大小的上下限,-Xmn则直接指定年轻代的大小。

1.1 参数默认值

◦-Xmx: Xmx的默认值比较复杂,官方文档上有时候写的是1GB,但实际值跟JRE版本、JVM 模式(client, server)和系统(平台类型,32位,64位)等都有关。经过查阅源码和实验,确定在生产环境下(server模式,64位Centos,JRE 8),Xmx的默认值可以采用以下规则计算:

▪容器内存小于等于2G:默认值为容器内存的1/2,最小16MB, 最大512MB。

▪容器内存大于2G:默认值为容器内存的1/4, 最大可到达32G。

◦-Xms: 默认值为容器内存的1/64, 最小8MB,如果明确指定了Xmx并且小于容器内存1/64, Xms默认值为Xmx指定的值。

◦-NewRatio: 默认2,即年轻代和年老代的比例为1:2, 年轻代大小为堆内内存的1/3。

NOTE:在JRE版本1.8.0_131之前,JVM无法感知Docker的资源限制,Xmx, Xms未明确指定时,会使用宿主机的内存计算默认值。

1.2 最佳实践

由于每次Eden区满就会触发YGC,而每次YGC的时候,晋升到老年代的对象大小超过老年代剩余空间的时候,就会触发FGC。所以基本来说,GC频率和堆内内存大小是成反比的,也就是说堆内内存越大,吞吐量越大。

如果Xmx设置过小,不仅浪费了容器资源,在大流量下会频繁GC,导致一系列问题,包括吞吐量降低,响应变长,CPU升高,java.lang.OutOfMemoryError异常等。当然Xmx也不建议设置过大,否则会导致进程hang住或者使用容器Swap。所以合理设置Xmx非常重要,特别是对于1.8.0_131之前的版本,一定要明确指定Xmx。推荐设置为容器内存的50%,不能超过容器内存的80%。

JVM的动态内存策略不太适合服务使用,因为每次GC需要计算Heap是否需要伸缩,内存抖动需要向系统申请或释放内存,特别是在服务重启的预热阶段,内存抖动会比较频繁。另外,容器中如果有其他进程还在消费内存,JVM内存抖动时可能申请内存失败,导致OOM。因此建议服务模式下,将Xms设置Xmx一样的值。

NewRatio建议在2~3之间,最优选择取决于对象的生命周期分布。一般先确定老年代的空间(足够放下所有live data,并适当增加10%~20%),其余是年轻代,年轻代大小一定要小于老年代。

另外,以上建议都是基于一个容器部署一个JVM实例的使用情况。有个别需求,需要在一个容器内启用多个JVM,或者包含其他语言的,研发需要按业务需求在推荐值范围内分配JVM的Xmx。

2. 堆外内存

和堆内内存对应的就是堆外内存。堆外内存包括很多部分,比如Code Cache, Memory Pool,Stack Memory,Direct Byte Buffers, Metaspace等等,其中我们需要重点关注的是Direct Byte Buffers和Metaspace。

2.1 Direct Byte Buffers

Direct Byte Buffers是系统原生内存,不位于JVM里,狭义上的堆外内存就是指的Direct Byte Buffers。为什么要使用系统原生内存呢? 为了更高效的进行Socket I/O或文件读写等内核态资源操作,会使用JNI(Java原生接口),此时操作的内存需要是连续和确定的。而Heap中的内存不能保证连续,且GC也可能导致对象随时移动。因此涉及Output操作时,不直接使用Heap上的数据,需要先从Heap上拷贝到原生内存,Input操作则相反。因此为了避免多余的拷贝,提高I/O效率,不少第三方包和框架使用Direct Byte Buffers,比Netty。

Direct Byte Buffers虽然有上述优点,但使用起来也有一定风险。常见的Direct Byte Buffers使用方法是用java.nio.DirectByteBuffer的unsafe.allocateMemory方法来创建,DirectByteBuffer对象只保存了系统分配的原生内存的大小和启始位置,这些原生内存的释放需要等到DirectByteBuffer对象被回收。有些特殊的情况下(比如JVM一直没有FGC,设置-XX:+DisableExplicitGC禁用了System.gc),这部分对象会持续增加,直到堆外内存达到-XX:MaxDirectMemorySize 指定的大小或者耗尽所有的系统内存。

MaxDirectMemorySize不明确指定的时候,默认值为0,在代码中实际为Runtime.getRuntime().maxMemory(),略小于-Xmx指定的值(堆内内存的最大值减去一个Survivor区大小)。此默认值有点过大,MaxDirectMemorySize未设置或设置过大,有可能发生堆外内存泄露,导致进程被系统Kill。

由于存在一定风险,建议在启动参数里明确指定-XX:MaxDirectMemorySize的值,并满足下面规则:

Xmx * 110% + MaxDirectMemorySize + 系统预留内存 <= 容器内存

◦Xmx * 110% 中额外的10%是留给其他堆外内存的,是个保守估计,个别业务运行时线程较多,需自行判断,上式中左侧还需加上Xss * 线程数

◦系统预留内存512M到1G,视容器规格而定

◦I/O较多的业务适当提高MaxDirectMemorySize比例

2.2 Metaspace

Metaspace(元空间)是JDK8关于方法区新的实现,取代之前的永久代,用来保存类、方法、数据结构等运行时信息和元信息的。很多研发在老版本时可能遇到过java.lang.OutOfMemoryError: PermGen Space,这说明永久代的空间不够用了,可以通过-XX:PermSize,-XX:MaxPermSize来指定永久代的初始大小和最大大小。Metaspace取代永久代,位置由JVM内存变成系统原生内存,也取消默认的最大空间限制。与此有关的参数主要有下面两个:

◦-XX:MaxMetaspaceSize 指定元空间的最大空间,默认为容器剩余的所有空间

◦-XX:MetaspaceSize 指定元空间首次扩充的大小,默认为20.8M

由于MaxMetaspaceSize未指定时,默认无上限,所以需要特别关注内存泄露的问题,如果程序动态的创建了很多类,或出现过java.lang.OutOfMemoryError:Metaspace,建议明确指定-XX:MaxMetaspaceSize。另外Metaspace实际分配的大小是随着需要逐步扩大的,每次扩大需要一次FGC,-XX:MetaspaceSize默认的值比较小,需要频繁GC扩充到需要的大小。通过下面的日志可以看到Metaspace引起的FGC:

[Full GC (Metadata GC Threshold) ...]

为减少预热影响,可以将-XX:MetaspaceSize,-XX:MaxMetaspaceSize指定成相同的值。另外不少应用由JDK7升级到了JDK8,但是启动参数中仍有-XX:PermSize,-XX:MaxPermSize,这些参数是不生效的,建议修改成-XX:MetaspaceSize,-XX:MaxMetaspaceSize。

3. 应用健康度检查规则

泰山应用健康度现在已支持扫描JVM相关风险,在应用TAB的JVM配置检测项下。主要包括以下检测:

检测指标 风险等级 巡检规则
JVM版本 中危 版本不低于1.8.0_191
JVM GC方法 中危 所有分组GC方法一致
Xmx 高危 明确指定,并且在容器内存的50%~80%范围内
Xms 中危 明确指定,并且等于Xmx指定的值
堆外内存 中危 明确指定,并且 堆内*1.1+堆外+系统预留<=容器内存
ParallelGCThreads 高危 ParallelGCThreads在容器CPU核数的50%~100%范围内
ConcGCThreads 低危 ConcGCThreads在ParallelGCThreads的20%~50%范围内(限CMS,G1)
CICompilerCount 低危 指定CICompilerCount在推荐值50%~150%内(限1.8<JRE<1.8.0_131)

上一篇文章已经说了ParallelGCThreads,这里再补充一下新支持的两个检测,ConcGCThreads,CICompilerCount。

ConcGCThreads一般称为并发标记线程数,为了减少GC的STW的时间,CMS和G1都有并发标记的过程,此时业务线程仍在工作,只是并发标记是CPU密集型任务,业务的吞吐量会下降,RT会变长。ConcGCThreads的默认值不同GC策略略有不同,CMS下是(ParallelGCThreads + 3) / 4 向下取整,G1下是ParallelGCThreads / 4 四舍五入。一般来说采用默认值就可以了,但是还是由于在JRE版本1.8.0_131之前,JVM无法感知Docker的资源限制的问题,ConcGCThreads的默认值会比较大(20左右),对业务会有影响。

CICompilerCount是JIT进行热点编译的线程数,和并发标记线程数一样,热点编译也是CPU密集型任务,默认值为2。在CICompilerCountPerCPU开启的时候(JDK7默认关闭,JDK8默认开启),手动指定CICompilerCount是不会生效的,JVM会使用系统CPU核数进行计算。所以当使用JRE8并且版本小于1.8.0_131,采用默认参数时,CICompilerCount会在20左右,对业务性能影响较大,特别是启动阶段。建议升级Java版本,特殊情况要使用老版本Java 8,请加上-XX:CICompilerCount=[n], 同时不能指定-XX:+CICompilerCountPerCPU ,下表给出了生产环境下常见规格的推荐值。

容器CPU核数 1 2 4 8 16
CICompilerCount手动指定推荐值 2 2 3 3 8

4. 修改建议

1) 再次建议升级JRE版本到1.8.0_191及以上; 2) 建议在Shell脚本中,Export JAVA_OPTS环境变量, 至少包含以下几项(方括号中的值根据文中推荐选取):

-server -Xms[8192m] -Xmx[8192m] -XX:MaxDirectMemorySize=[4096m]

如果特殊原因要使用1.8.0_131以下版本, 则同时需要加上以下参数(方括号中的值根据文中推荐选取):

-XX:ParallelGCThreads=[8] -XX:ConcGCThreads=[2] -XX:CICompilerCount=[2]

下面的项建议测试后使用,需自行确定具体大小(特别是使用JRE8但仍配置-XX:PermSize,-XX:MaxPermSize的应用):

-XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m

环境变量设置如下例子:

export JAVA_OPTS="-Djava.library.path=/usr/local/lib -server -Xms4096m -Xmx4096m -XX:MaxMetaspaceSize=512m -XX:MetaspaceSize=512m -XX:MaxDirectMemorySize=2048m -XX:ParallelGCThreads=8 -XX:ConcGCThreads=2 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/export/Logs -XX:+UseG1GC [other_options...] -jar jarfile [args...]"

另外,如果应用未接入UMP或PFinder, JAVA_OPTS中尽量不要用Shell函数或者变量,否则健康度有可能会提示解析失败。

NOTE: Java options 的使用应该按照下面的顺序:

◦执行类: java [-options] class [args...]

◦执行包:java [-options] -jar jarfile [args...] 或 java -jar [-options] jarfile [args...]

即options要放到执行对象之前,部分应用使用了以下顺序:

java -jar jarfile [-options] [args...] 或者 java -jar jarfile [args...] [-options]

这些Java options都不会生效。

与谈JVM xmx, xms等内存相关参数合理性设置相似的内容:

谈JVM xmx, xms等内存相关参数合理性设置

吞吐量和停顿时长,这两个优化目标是有冲突的。那么有没有可能提高吞吐量而不影响停顿时长,甚至缩短停顿时长呢?答案是有可能的,提高内存占用(Memory Footprint)就有可能。

谈JVM参数GC线程数ParallelGCThreads合理性设置

作者:京东零售 刘乐 导读:本篇文章聚焦JVM参数GC线程数的合理配置,从ParallelGCThreads参数含义、参数设置,到参数实验以及修改意见进行解析。 1. ParallelGCThreads参数含义 在讲这个参数之前,先谈谈JVM垃圾回收(GC)算法的两个优化标的:吞吐量和停顿时长。JV

[转帖]谈 JVM 参数 GC 线程数 ParallelGCThreads 合理性设置

https://my.oschina.net/u/4090830/blog/7926038 1. ParallelGCThreads 参数含义 在讲这个参数之前,先谈谈 JVM 垃圾回收 (GC) 算法的两个优化标的:吞吐量和停顿时长。JVM 会使用特定的 GC 收集线程,当 GC 开始的时候,GC

谈了千百遍的数据一致性

今天来说一个老生常谈的问题,来看一个实际案例:业务中往往都会通过缓存来提高查询效率,降低数据库的压力,尤其是在分布式高并发场景下,大量的请求直接访问Mysql很容易造成性能问题。

再谈量化策略失效的问题

更多精彩内容,欢迎关注公众号:数量技术宅,也可添加技术宅个人微信号:sljsz01,与我交流。 如何判断量化策略是否失效 我们在交易量化策略的时候,经常会遇到量化策略出现持续性的回撤。此时,必须考虑一种情况,即正在交易的策略可能失效了。于是,我们的首要工作是,判断这个量化策略是否失效。 判断量化交易

再谈23种设计模式(3):行为型模式(学习笔记)

行为型模式的关注点在于对象之间的通信和职责分配(描述结构模型中对象的动态特征)。行为型模式关注的是对象之间的交云和协作,即它们是如何相互作用的,以及如何分配职责和算法来完成任务。

不谈虚的,平台即产品真的有那么好吗?

随着信息技术的高速发展,我们每隔一段时间就能看到一个热门术语在各大平台被分析和讨论。当我们上搜索引擎搜索相关词条,就会找到大量与该技术优势、亮点相关的文章。特别是“平台即产品”(PaaP)策略,其在实际应用中的利用价值和效用性成为近期关注的焦点。 虽然构建数字平台以促进协作和创新的理念听起来颇具前景

再谈http请求调用(Post与Get),项目研发的核心一环

支持.Net Core(2.0及以上)与.Net Framework(4.0及以上) 【目录】 前言 Post请求 Get请求 与其它工具的比较 1【前言】 http请求调用是开发中经常会用到的功能。 在内,调用自有项目的Web Api等形式接口时会用到;在外,调用一些第三方功能接口时,也会用到,因

再谈vue中的differ算法

Differ算法 在 Vue 中,当数据变化时,Vue 会使用 Virtual DOM 和 diff 算法来尽可能地减少 DOM 操作的次数,以提高性能。 diff 算法是 Virtual DOM 实现中的核心算法之一,其主要作用是比较新旧虚拟 DOM 树的差异,并将差异应用到真实的 DOM 树上。

[转帖]陈巍谈芯:一图看懂芯片禁令的目的、范围和影响

https://zhuanlan.zhihu.com/p/572905835 陈巍谈芯:让你一图看懂某国芯片禁令的目的、范围和影响。 感觉这回是“芯片战争”,影响全球半导体产业链。但也是有方法减少影响的。