java 对于希望在常规 Sun/Oracle Hotspot JVM 上最小化 GC 延迟的实时系统,最佳 GC 和内存配置是什么?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/9881181/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-10-30 22:45:24  来源:igfitidea点击:

What is the best GC and memory configuration for a real-time system that wants to minimize GC latency on a regular Sun/Oracle Hotspot JVM?

javaoptimizationmemorygarbage-collection

提问by JohnPristine

The question pretty much says it all. What supported JVM GC should we use and with what configuration to minimize GC impact in the application?

这个问题几乎说明了一切。我们应该使用什么支持的 JVM GC 以及使用什么配置来最小化应用程序中的 GC 影响?

EDIT:Linux Ubuntu 64-bit:

编辑:Linux Ubuntu 64 位:

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

采纳答案by Java42

Starting in J2SE 5.0, the parallel collectoris selected by default on server-class machines as detailed in the document Garbage Collector Ergonomics. In addition, the parallel collector uses a method of automatic tuningthat allows desired behaviors to be specified instead of generation sizes and other low-level tuning details. The behaviors that can be specified are:

从 J2SE 5.0 开始,服务器级机器上默认选择并行收集器,如文档垃圾收集器人体工程学中所述。此外,并行收集器使用一种自动调整方法,允许指定所需的行为,而不是生成大小和其他低级调整细节。可以指定的行为是:

Maximum garbage collection pause timeThroughput Footprint (i.e., heap size) The maximum pause time goal is specified with the command line option -XX:MaxGCPauseMillis=. This is interpreted as a hint that pause times of milliseconds or less are desired; by default there is no maximum pause time goal. If a pause time goal is specified, the heap size and other garbage collection related parameters are adjusted in an attempt to keep garbage collection pauses shorter than the specified value. Note that these adjustments may cause the garbage collector to reduce the overall throughput of the application and in some cases the desired pause time goal cannot be met.

最大垃圾收集暂停时间吞吐量足迹(即堆大小) 最大暂停时间目标是通过命令行选项 -XX:MaxGCPauseMillis= 指定的。这被解释为暗示需要毫秒或更短的暂停时间;默认情况下没有最大暂停时间目标。如果指定了暂停时间目标,则会调整堆大小和其他垃圾收集相关参数,以尝试使垃圾收集暂停时间短于指定值。请注意,这些调整可能会导致垃圾收集器降低应用程序的整体吞吐量,并且在某些情况下无法满足所需的暂停时间目标。

Excerpted from http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#par_gc.ergonomics

摘自http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#par_gc.ergonomics

回答by Stephen C

You've been asking questions about this problem for a number of days. I think the root of your problems is that you are trying to get realtime performance out of Java platforms that are simply not designed to provide it.

几天来,您一直在询问有关此问题的问题。我认为您的问题的根源在于您试图从并非旨在提供实时性能的 Java 平台中获得实时性能。

If you want real-time performance (in the true sense of the word), you need a Java VM that implement the RTSJ realtime extensions. This pagethat lists some implementations. Note that to get realtime performance at the Java application level, you also need to be running on a real-time capable OS platform.

如果您想要实时性能(真正意义上的),您需要一个实现 RTSJ 实时扩展的 Java VM。 此页面列出了一些实现。请注意,要在 Java 应用程序级别获得实时性能,您还需要在具有实时能力的操作系统平台上运行。



On the other hand, if you just want low-pause garbage collection without any strong realtime performance guarantees, then Oracle's GC tuning documents explain how to do this. See Chuck Fricano's answer.

另一方面,如果您只想要低暂停垃圾收集而没有任何强大的实时性能保证,那么 Oracle 的 GC 调优文档解释了如何做到这一点。见查克弗里卡诺的回答。

But beware that there limits to what can be achieved this way. In particular, if your application stresses the GC too much, it won't be able to meet your goals for pause times. And the optimal settings for the tuning parameters are likely to be platform / hardware specific, as well as application dependent.

但请注意,通过这种方式可以实现的目标是有限的。特别是,如果您的应用程序对 GC 压力太大,它将无法满足您的暂停时间目标。并且优化参数的最佳设置可能是平台/硬件特定的,以及应用程序相关的。

There are no easy answers.

没有简单的答案。

And there is certainly no one-size-fits-all configuration to minimize latency. Not even for a specific JVM version, operating system and hardware platform.

并且肯定没有一刀切的配置来最小化延迟。甚至不是针对特定的 JVM 版本、操作系统和硬件平台。

回答by kevin_c

In order to properly configure the GC you need to understand the object life cycle in your application. As mentioned, there are no easy answers. What has worked for me is sizing the young generation so most objects die there and using the CMS and setting an initiating fraction so it wont run constantly. Here are my parameters:

-server -Xms4000M -Xmx4000M -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=60 -XX:MaxTenuringThreshold=4 -XX:MaxNewSize=384m -XX:NewSize=384m -XX:SurvivorRatio=12 -Xloggc:/opt/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

为了正确配置 GC,您需要了解应用程序中的对象生命周期。如前所述,没有简单的答案。对我有用的是调整年轻代的大小,这样大多数对象都会死在那里,并使用 CMS 并设置一个初始分数,这样它就不会一直运行。这是我的参数:

-server -Xms4000M -Xmx4000M -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=60 -XX:MaxTenuringThreshold=4 -XX:MaxNewSize=384m -XX:NewSize=384m -XX:SurvivorRatio=12 -Xloggc:/opt/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

You can also use third party utilities to parse the GC log files in order to see statistics on the collector.

您还可以使用第三方实用程序来解析 GC 日志文件,以便查看有关收集器的统计信息。