堆参数对GC /性能的影响？ [英] Impact of heap parameters on GC/performance?

问题描述

网上的大部分地方，我会得到以下有关堆参数的信息：

-Xms< size>设置初始Java堆大小
-Xmx< size>设置最大Java堆大小

这里是我对 -Xms 512M -Xmx 2048M code>参数，



-Xms： - 我的理解是，如果我的java进程实际上只需要200M， XMS 512M，java进程仍然只会分配200M（实际所需内存）而不是500M。但是如果我已经知道我的应用程序将在启动时使用这个512M内存，那么指定少于这个值会影响性能，因为堆块需要调整大小，这是昂贵的操作。



与我的同事进行讨论，默认情况下，GC会触发60％的Xms值。那是对的吗 ？如果是的话，它是小GC还是完整的GC，取决于Xms值？

Xms更新： -
这似乎在阅读 JVM堆参数之后为true，但默认值为60％，并且是次要的或完整的GC那是依赖于Xms值的？

-Xmx： - 我的理解是提到-Xmx 2048M，java进程实际上是要预留2048M内存，因为它可以从操作系统中使用，所以另一个进程无法获得它的份额。如果java进程需要超过2048M的内存，那么会导致内存不足。

另外我相信Full GC触发器对-Xmx的值有一些关系。因为我观察到当内存达到Xmx的70％时，Full GC发生在jconsole中。这是正确的吗？

配置：我正在使用linux box（64位JVM 8）。默认GC即并行GC

解决方案

不基于Xms或Xmx值触发GC。

堆=新+旧代

堆大小（最初设置为Xms）被分成2世代 - 新（又名年轻）和老（又名终身）。新一代默认是堆总大小的1/3，而旧一代是堆大小的2/3。这可以通过使用名为NewRatio的JVM参数进行调整。它的默认值是2.

年轻一代进一步分为伊甸园和2个幸存者空间。这3个空格的默认比例是：3/4，1/8，1/8。

附注：这是关于Parallel GC收集器。对于G1 - 新的GC算法不同地分割堆空间。

次要GC
所有新对象都分配在Eden空间中（除了直接存储在旧代中的大量对象）。 Eden空间变满时触发小GC。在多个次要GC中存活的对象被提升为旧一代（默认值是15个周期，可以使用JVM参数：MaxTenuringThreshold进行更改。）
$ b

主要GC
与并发收集器不同，根据已用空间（默认为70％）触发主GC，并行收集器根据下面提到的3个目标计算阈值。

<并行收集器目标

• 最大GC暂停时间 - 执行GC所花的最长时间


• 吞吐量 - 在GC与应用程序中花费的时间百分比。默认值（1％）
  
• 占用空间 - 最大堆大小（Xmx）
  

，并行收集器尝试在垃圾收集中花费最高1％的应用程序运行时间。

更多详细信息 here

Xms to Xmx

在启动期间，JVM创建大小为Xms的堆，但保留额外的空间（Xmx）以便稍后增长。该保留的空间被称为虚拟空间。请注意，它只是保留空间，并没有提交。

2个参数决定了Xms和Xmx之间堆大小增长（或缩小）的时间。

• MinHeapFreeRatio（默认值：40％）：一旦可用堆空间降至40％以下，被触发，并且堆大小增长20％。因此，堆大小可以保持增长，直到达到Xmx。


• MaxHeapFreeRatio（默认值：70％）：另一方面，堆空闲空间跨越70％，则每次GC期间堆大小递增5％直到达到Xms。

这些参数可以在启动时设定。详细了解它此处和< here 。

PS ：JVM GC非常吸引人，我建议您阅读优秀的文章深入理解。所有JVM调优参数都可以在此处找到。

Most of the place on net , I get below info about heap parameters

-Xms<size> set initial Java heap size -Xmx<size> set maximum Java heap size

Here is mine understanding/question when I mention -Xms 512M -Xmx 2048M parameters ,

-Xms :- My understanding is if my java process is actually needed only 200M , with mention of -Xms 512M , java process will still be assigned only 200M(actual memory required) instead of 500M . But if I already know that my application is going to take this 512M memory on start up then specifying less than will have impact on performance as anyways heap block need to resized which is costly operation.

Per discussion with my colleague, By default GC will trigger on 60% of Xms value. Is that correct ? If yes is it minor GC or full GC that is dependant on Xms value ?

Update on Xms:- This seems to be true after reading JVM heap parameters but again is value 60% by default and is it minor or full GC that is dependent on Xms value?

-Xmx:- My understanding is with mention of -Xmx 2048M , java process is actually going to reserve 2048M memory for its use from OS itso that another process can not be given its share.If java process needed anyhow more than 2048M memory, then out of memory will be thrown.

Also i believe there is some relation of Full GC trigger on value of -Xmx. Because what I observed is when memory reaches near to 70% of Xmx, Full GC happens in jconsole. Is that correct?

Configuration :- I am using linux box(64 bit JVM 8). Default GC i.e Parallel GC

解决方案

GC is not triggered based on just Xms or Xmx value.

Heap = New + Old generations
The heap size (which is initially set to Xms) is split into 2 generations - New (aka Young) and Old (aka Tenured). New generation is by default 1/3rd of the total heap size while Old generation is 2/3rd of the heap size. This can be adjusted by using JVM parameter called NewRatio. Its default value is 2.

Young Generation is further divided in Eden and 2 Survivor spaces. The default ratio of these 3 spaces are: 3/4th, 1/8th, 1/8th.

Side note: This is about Parallel GC collectors. For G1 - new GC algorithm divides the heap space differently.

Minor GC All new objects are allocated in Eden space (except massive ones which are directly stored in Old generation). When Eden space becomes full Minor GC is triggered. Objects which survive multiple minor GCs are promoted to Old Generation (default is 15 cycles which can be changed using JVM parameter: MaxTenuringThreshold).

Major GC Unlike concurrent collector, where Major GC is triggered based on used-space (by default 70%), parallel collectors calculate threshold based on 3 goals mentioned below.

Parallel Collector Goals

• Max GC pause time - Maximum time spent in doing GC
• Throughput - Percentage of time spent in GC vs Application. Default (1%)
• Footprint - Maximum heap size (Xmx)

Thus by default, Parallel Collector tries to spend maximum 1% of total application running time in Garbage Collection.

More details here

Xms to Xmx
During startup JVM creates heap of size Xms but reserves the extra space (Xmx) to be able to grow later. That reserved space is called Virtual Space. Do note that it just reserves the space and does not commit.

2 parameters decide when heap size grows (or shrinks) between Xms and Xmx.

• MinHeapFreeRatio (default: 40%): Once the free heap space dips below 40%, a Full GC is triggered, and the heap size grows by 20%. Thus, heap size can keep growing incrementally until it reaches Xmx.
• MaxHeapFreeRatio (default: 70%): On the flip side, heap free space crosses 70%, then Heap size is reduced by 5% incrementally during each GC until it reaches Xms.

These parameters can be set during startup. Read more about it here and here.

PS: JVM GC is fascinating topic and I would recommend reading this excellent article to understand in-depth. All the JVM tuning parameters can be found here.

这篇关于堆参数对GC /性能的影响？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！