我们正在经历小GC暂停时间的增加。应用程序是一个用Java编写的服务器,每秒执行500个事务。在CMS收集之后,暂停时间会减少,但在运行数小时之后,暂停时间又会增加。我用vmstat检查了交换用法,没有任何交换输入/输出。
{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) }
{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参数:
-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
拥有一个大的伊甸园空间是惊人的便宜,什么是昂贵的复制对象,保留。
在你较短的时间内,你保留了(第二个尺寸)
346199K->73301K, 0.0127033 secs
在你更长的时间里,你保留了更多
1304066K->1031418K(3549952K), 0.9100161 secs
即,在第一种情况下,GC需要更长的时间,因为您保留了更多的数据。
我在这些情况下尝试的第一件事是增加伊甸园大小,希望在一个集合发生之前有更多的对象死亡。
当使用G1收集器时,我们一直在与似乎是长期停止的世界停顿作斗争。我已经通读了Oracle文档,但仍然难以确定如何解释导致长时间停顿的原因以及如何处理。(下面是GC日志) 我们的实例正在被监视,下面的图中包含了信息: 我们有另一个监视工具ping JVM,我让它报告JVM在同一时间内有12秒没有响应。 更新:元空间图
问题内容: 我怀疑异常可能会使TimerTask停止运行,在这种情况下,我很可能需要第二个timetask来监视第一个仍在运行? 更新资料 感谢您的回答。我继承了此代码,因此有点无知… 我刚刚看到,如果我在工作中抛出未捕获的异常,TimerThread将永远停止运行。 的运行方法表明,如果引发异常,则计划的线程将永远不会再次运行。 stacktrace的结尾将是: 因此,临时解决方案是抓住一切…长
问题内容: 我在雄猫服务器(+ liferay)上收到此异常 我的课是这样的: 我在行上收到此异常, 当队列已满但大小为2 ^ 31时,可能会发生此错误,并且我确定没有那么多命令在等待。 一开始一切都稳定,但在我重新部署战争后,一切开始发生。此类不是战争的一部分,而是放在tomcat / lib中的jar中。 您是否知道为什么会发生这种情况以及如何解决? 问题答案: 从ThreadPoolExec
el-dropdown添加command事件,执行了两次,这是为什么? 查了别人的类似的两次触发问题,查文档证实,command为官方提供方法,不存在.native与二次同时被处罚的情况存在。
当然在文件结束或输入错误发生时返回,但这是否意味着没有更多的数据可用? 使用