Question

我们正在经历次要GC暂停时间的增加。该应用程序是一个用Java编写的服务器，每秒执行500个事务。 CMS收集后，暂停时间减少，但经过几小时的运行暂停时间再次增加。我已经用 vmstat 检查了交换使用情况，没有任何交换输入/输出。

小gc暂停时间增加的可能原因是什么？

以下是gc日志文件的一部分，而次要gc暂停时间很短：（0.01秒）

{Heap before GC invocations=123 (full 0):
 par new generation   total 306688K, used 275101K [0xfffffffe80010000, 0xfffffffe94cd0000, 0xfffffffe94cd0000)
  eden space 272640K, 100% used [0xfffffffe80010000, 0xfffffffe90a50000, 0xfffffffe90a50000)
  from space 34048K,   7% used [0xfffffffe92b90000, 0xfffffffe92df7718, 0xfffffffe94cd0000)
  to   space 34048K,   0% used [0xfffffffe90a50000, 0xfffffffe90a50000, 0xfffffffe92b90000)
 concurrent mark-sweep generation total 3243264K, used 71097K [0xfffffffe94cd0000, 0xffffffff5ac10000, 0xffffffff5ac10000)
 concurrent-mark-sweep perm gen total 262144K, used 30336K [0xffffffff5ac10000, 0xffffffff6ac10000, 0xffffffff6ac10000)
2012-07-29T20:00:19.790+0300: 472.781: [GC 472.782: [ParNew
Desired survivor size 17432576 bytes, new threshold 4 (max 4)
- age   1:    1068432 bytes,    1068432 total
- age   2:     296272 bytes,    1364704 total
- age   3:      68624 bytes,    1433328 total
- age   4:      53776 bytes,    1487104 total
: 275101K->2187K(306688K), 0.0111305 secs] 346199K->73301K(3549952K), 0.0127033 secs] [Times: user=0.13 sys=0.01, real=0.01 secs]
Heap after GC invocations=124 (full 0):
 par new generation   total 306688K, used 2187K [0xfffffffe80010000, 0xfffffffe94cd0000, 0xfffffffe94cd0000)
  eden space 272640K,   0% used [0xfffffffe80010000, 0xfffffffe80010000, 0xfffffffe90a50000)
  from space 34048K,   6% used [0xfffffffe90a50000, 0xfffffffe90c72dc0, 0xfffffffe92b90000)
  to   space 34048K,   0% used [0xfffffffe92b90000, 0xfffffffe92b90000, 0xfffffffe94cd0000)
 concurrent mark-sweep generation total 3243264K, used 71114K [0xfffffffe94cd0000, 0xffffffff5ac10000, 0xffffffff5ac10000)
 concurrent-mark-sweep perm gen total 262144K, used 30336K [0xffffffff5ac10000, 0xffffffff6ac10000, 0xffffffff6ac10000)
}

以下是gc日志文件的一部分，而次要gc暂停时间很长：（0.9秒）

{Heap before GC invocations=38526 (full 3):
 par new generation   total 306688K, used 280310K [0xfffffffe80010000, 0xfffffffe94cd0000, 0xfffffffe94cd0000)
  eden space 272640K, 100% used [0xfffffffe80010000, 0xfffffffe90a50000, 0xfffffffe90a50000)
  from space 34048K,  22% used [0xfffffffe90a50000, 0xfffffffe911cda60, 0xfffffffe92b90000)
  to   space 34048K,   0% used [0xfffffffe92b90000, 0xfffffffe92b90000, 0xfffffffe94cd0000)
 concurrent mark-sweep generation total 3243264K, used 1023755K [0xfffffffe94cd0000, 0xffffffff5ac10000, 0xffffffff5ac10000)
 concurrent-mark-sweep perm gen total 262144K, used 34997K [0xffffffff5ac10000, 0xffffffff6ac10000, 0xffffffff6ac10000)
2012-07-31T13:21:46.709+0300: 149360.928: [GC 149360.930: [ParNew
Desired survivor size 17432576 bytes, new threshold 4 (max 4)
- age   1:    1794816 bytes,    1794816 total
- age   2:    2864408 bytes,    4659224 total
- age   3:      72672 bytes,    4731896 total
- age   4:      86160 bytes,    4818056 total
: 280310K->7605K(306688K), 0.9073290 secs] 1304066K->1031418K(3549952K), 0.9100161 secs] [Times: user=9.34 sys=0.15, real=0.91 secs]
Heap after GC invocations=38527 (full 3):
 par new generation   total 306688K, used 7605K [0xfffffffe80010000, 0xfffffffe94cd0000, 0xfffffffe94cd0000)
  eden space 272640K,   0% used [0xfffffffe80010000, 0xfffffffe80010000, 0xfffffffe90a50000)
  from space 34048K,  22% used [0xfffffffe92b90000, 0xfffffffe932fd490, 0xfffffffe94cd0000)
  to   space 34048K,   0% used [0xfffffffe90a50000, 0xfffffffe90a50000, 0xfffffffe92b90000)
 concurrent mark-sweep generation total 3243264K, used 1023813K [0xfffffffe94cd0000, 0xffffffff5ac10000, 0xffffffff5ac10000)
 concurrent-mark-sweep perm gen total 262144K, used 34997K [0xffffffff5ac10000, 0xffffffff6ac10000, 0xffffffff6ac10000)
}

JVM args：

-d64  -server  \
-XX:+UseParNewGC \
-XX:+UseConcMarkSweepGC \
-Xloggc:./logs/gc_"$DATE".log -XX:+PrintGCDetails -XX:+PrintGCDateStamps \
-XX:+PrintGC \
-XX:PrintCMSStatistics=2 \
-XX:+PrintTenuringDistribution \
-XX:+PrintHeapAtGC \
-XX:+PrintGCTaskTimeStamps \
-XX:PermSize=256m -XX:MaxPermSize=256m \
-XX:+CMSClassUnloadingEnabled \
-XX:-OmitStackTraceInFastThrow \
-XX:ParallelGCThreads=16 \
-XX:ParallelCMSThreads=12 \
-Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFFE -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFFE \
-Xms3500m -Xmx3500m -Xss192k

Answer 1

拥有庞大的伊甸园空间是非常便宜的，但是复制保留的物体是件昂贵的。

在您保留的较短时间内（第二个尺寸）

346199K->73301K, 0.0127033 secs

在较长的时间内，您保留了更多

1304066K->1031418K(3549952K), 0.9100161 secs

即。在第一种情况下，GC需要更长时间，因为您保留了更多数据。

我在这些情况下尝试的第一件事是增加伊甸园的大小，希望在收集之前会有更多的物体死亡。

Answer 2

新空间只有300M而旧空间有3500M？你应该扩大新的空间大小。
如果可能的话，提供你的jvm arg？

次要GC暂停时间正在增加。可能的原因是什么？

2 个答案: