我们的次要GC暂停时间正在增加。
该应用程序是用Java编写的服务器，每秒执行500个事务。
CMS收集后，暂停时间减少，但经过数小时的运行，暂停时间又增加了。
我已经使用vmstat检查了交换使用情况，没有任何交换输入/输出。
增加次要gc暂停时间的可能原因是什么？
这是gc日志文件的一部分，而次要gc暂停时间很短：（0.01秒）
{GC调用之前的堆= 123（全0）：
新一代标准配件，总计306688K，二手275101K [0xfffffffe80010000、0xfffffffe94cd0000、0xfffffffe94cd0000）
伊甸园空间272640K，已使用100％[0xfffffffe80010000、0xfffffffe90a50000、0xfffffffe90a50000）
来自空间34048K，已使用7％[0xfffffffe92b90000、0xfffffffe92df7718、0xfffffffe94cd0000）
到空间34048K，已使用0％[0xfffffffe90a50000、0xfffffffe90a50000、0xfffffffe92b90000）
并发标记清除生成总计3243264K，已使用71097K [0xfffffffe94cd0000、0xffffffff5ac10000、0xffffffff5ac10000）
并发标记扫描perm生成总计262144K，已用30336K [0xffffffff5ac10000、0xffffffff6ac10000、0xffffffff6ac10000）
2012-07-29T20：00：19.790 + 0300：472.781：[GC 472.782：[ParNew
所需的幸存者大小17432576字节，新阈值4（最大4）
-年龄1：1068432字节，总计1068432
-年龄2：296272字节，总计1364704
-年龄3：68624字节，共1433328
-年龄4：53776字节，总计1487104
：275101K-> 2187K（306688K），0.0111305秒] 346199K-> 73301K（3549952K），0.0127033秒] [时间：用户= 0.13 sys = 0.01，真实= 0.01秒]
GC调用后的堆= 124（全0）：
标准新一代总值306688K，二手2187K [0xfffffffe80010000、0xfffffffe94cd0000、0xfffffffe94cd0000）
伊甸园空间272640K，已使用0％[0xfffffffe80010000、0xfffffffe80010000、0xfffffffe90a50000）
来自空间34048K，已使用6％[0xfffffffe90a50000、0xfffffffe90c72dc0、0xfffffffe92b90000）
到空间34048K，已使用0％[0xfffffffe92b90000、0xfffffffe92b90000、0xfffffffe94cd0000）
并发标记清除生成总计3243264K，已使用71114K [0xfffffffe94cd0000、0xffffffff5ac10000、0xffffffff5ac10000）
并发标记扫描perm生成总计262144K，已用30336K [0xffffffff5ac10000、0xffffffff6ac10000、0xffffffff6ac10000）
}
以下是gc日志文件的一部分，而次要gc暂停时间很长：（0.9秒）
{GC调用之前的堆= 38526（完整3）：
标准新世代306688K，二手280310K [0xfffffffe80010000、0xfffffffe94cd0000、0xfffffffe94cd0000）
伊甸园空间272640K，已使用100％[0xfffffffe80010000、0xfffffffe90a50000、0xfffffffe90a50000）
来自空间34048K，已使用22％[0xfffffffe90a50000、0xfffffffe911cda60、0xfffffffe92b90000）
到空间34048K，已使用0％[0xfffffffe92b90000、0xfffffffe92b90000、0xfffffffe94cd0000）
并发标记清除生成总计3243264K，已使用1023755K [0xfffffffe94cd0000、0xffffffff5ac10000、0xffffffff5ac10000）
并发标记扫描perm生成总计262144K，已使用34997K [0xffffffff5ac10000、0xffffffff6ac10000、0xffffffff6ac10000）
2012-07-31T13：21：46.709 + 0300：149360.928：[GC 149360.930：[ParNew
所需的幸存者大小17432576字节，新阈值4（最大4）
-年龄1：1794816字节，共1794816
-年龄2：2864408字节，总计4659224
-年龄3：72672字节，总计4731896
-年龄4：86160字节，总计4818056
：280310K-> 7605K（306688K），0.9073290秒] 1304066K-> 1031418K（3549952K），0.9100161秒] [时间：user = 9.34 sys = 0.15，real = 0.91秒]
GC调用后堆= 38527（完整3个）：
标准新一代总值306688K，二手7605K [0xfffffffe80010000、0xfffffffe94cd0000、0xfffffffe94cd0000）
伊甸园空间272640K，已使用0％[0xfffffffe80010000、0xfffffffe80010000、0xfffffffe90a50000）
来自空间34048K，已使用22％[0xfffffffe92b90000、0xfffffffe932fd490、0xfffffffe94cd0000）
到空间34048K，已使用0％[0xfffffffe90a50000、0xfffffffe90a50000、0xfffffffe92b90000）
并发标记清除生成总数3243264K，已使用1023813K [0xfffffffe94cd0000、0xffffffff5ac10000、0xffffffff5ac10000）
并发标记扫描perm生成总计262144K，已使用34997K [0xffffffff5ac10000、0xffffffff6ac10000、0xffffffff6ac10000）
}
JVM参数：
-d64-服务器\
-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
最佳答案
具有较大的伊甸园空间令人惊讶地便宜，而昂贵的是复制保留的对象。
在较短的时间内保留（第二个尺寸）
346199K->73301K, 0.0127033 secs
在更长的时间内，您保留了更多
1304066K->1031418K(3549952K), 0.9100161 secs
也就是说，在第一种情况下，GC花费的时间更长，因为您保留了更多的数据。
在这些情况下，我尝试做的第一件事是增加伊甸园的大小，希望在收集发生之前更多的对象会死亡。
关于java - 较小的GC暂停时间正在增加。可能是什么原因？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/11790616/