减少JVM暂停时间> 1秒使用UseConcMarkSweepGC [英] Reducing JVM pause time > 1 second using UseConcMarkSweepGC

问题描述

我在一台装有16Gb内存的计算机上运行一个内存密集型应用程序，还有一个8核处理器，以及所有在CentOS 5.2版本上运行的Java 1.6（Final）。精确的JVM详细信息如下：

  Java版本1.6.0_10
 Java™SE运行时环境（版本1.6 
 Java HotSpot™64位服务器虚拟机（构建11.0-b15，混合模式）
  

我使用以下命令行选项启动应用程序：

  java -XX：+ UseConcMarkSweepGC -verbose：gc -server -Xmx10g -Xms10g ... 
  

我的应用程序公开了一个JSON-RPC API ，我的目标是在25毫秒内响应请求。不幸的是，我看到延迟达到并超过1秒，这似乎是垃圾收集造成的。以下是一些较长的例子：

pre $ [GC 4592788K-> 4462162K（10468736K），1.3606660秒]
[GC 5881547K-> 5768559K（10468736K），1.2559860秒]
[GC 6045823K-> 5914115K（10468736K），1.3250050秒]


这些垃圾收集事件中的每一个都伴随着延迟API响应，其持续时间与所示垃圾收集时间非常相似（几毫秒内）。

以下是一些典型的例子（这些都是在几秒钟内产生的）：

  [ GC 3373764K-> 3336654K（10468736K），0.6677560秒] 
 [GC 3472974K-> 3427592K（10468736K），0.5059650秒] 
 [GC 3563912K-> 3517273K（10468736K），0.6844440秒] b $ b [GC 3622292K-> 3589011K（10468736K），0.4528480秒] 
  

我认为UseConcMarkSweepGC会避免这种情况，或者至少使其非常罕见。相反，超过100ms的延迟几乎每分钟发生一次或更多（尽管延迟超过1秒比较少见，可能每10或15分钟一次）。

另一件事是，我认为只有一个完整的GC会导致线程暂停，但这些似乎不是完整的GC。

它可能与笔记有关大部分内存都被一个LRU内存缓存占用，它使用软引用。

任何帮助或建议都将不胜感激。

$ b

解决方案

原来，堆的一部分被交换到磁盘，所以垃圾收集必须将一堆数据从磁盘上拉回到内存中。

我通过将Linux的swappiness参数设置为0来解决这个问题（这样它就不会将数据交换到磁盘）。

I'm running a memory intensive app on a machine with 16Gb of RAM, and an 8-core processor, and Java 1.6 all running on CentOS release 5.2 (Final). Exact JVM details are:

java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b15, mixed mode)

I'm launching the app with the following command line options:

java -XX:+UseConcMarkSweepGC -verbose:gc -server -Xmx10g -Xms10g ...

My application exposes a JSON-RPC API, and my goal is to respond to requests within 25ms. Unfortunately, I'm seeing delays up to and exceeding 1 second and it appears to be caused by garbage collection. Here are some of the longer examples:

[GC 4592788K->4462162K(10468736K), 1.3606660 secs]
[GC 5881547K->5768559K(10468736K), 1.2559860 secs]
[GC 6045823K->5914115K(10468736K), 1.3250050 secs]

Each of these garbage collection events was accompanied by a delayed API response of very similar duration to the length of the garbage collection shown (to within a few ms).

Here are some typical examples (these were all produced within a few seconds):

[GC 3373764K->3336654K(10468736K), 0.6677560 secs]
[GC 3472974K->3427592K(10468736K), 0.5059650 secs]
[GC 3563912K->3517273K(10468736K), 0.6844440 secs]
[GC 3622292K->3589011K(10468736K), 0.4528480 secs]

The thing is that I thought the UseConcMarkSweepGC would avoid this, or at least make it extremely rare. On the contrary, delays exceeding 100ms are occurring almost once a minute or more (although delays of over 1 second are considerably rarer, perhaps once every 10 or 15 minutes).

The other thing is that I thought only a FULL GC would cause threads to be paused, yet these don't appear to be full GCs.

It may be relevant to note that most of the memory is occupied by a LRU memory cache that makes use of soft references.

Any assistance or advice would be greatly appreciated.

解决方案

Turns out that part of the heap was getting swapped out to disk, so that garbage collection had to pull a bunch of data off the disk back into memory.

I resolved this by setting Linux's "swappiness" parameter to 0 (so that it wouldn't swap data out to disk).

这篇关于减少JVM暂停时间> 1秒使用UseConcMarkSweepGC的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！