ParallelGCFailedAllocation的大'同步'值 [英] Large 'sync' value for ParallelGCFailedAllocation

查看:1249
本文介绍了ParallelGCFailedAllocation的大'同步'值的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

有时我会在gc.log中看到长时间的停顿


2014-07-18T18:42:26.137 + 0400:7846.980:[

10032K(87744K)] 251198K-175254K(272512K),0.0066190秒] [时间:用户= 0.08 sys = 0.00,实际= 0.01秒] p>停止应用程序线程的总时间: 0.6394170



停止应用程序线程的总时间:0.0014570秒


但是,这些暂停不会影响GC时间和CPU使用时间。

Safepoint统计数据(+ XX:PrintSafePointStatistics):


vmop [threads:总计starts_running wait_to_block] [时间:旋转块同步清除vmop] page_trap_count
7846.348:ParallelGCFailedAllocation [370 0 2] [0 0 630 1 7] 0


(同步时间= 630ms)在这种情况下,'sync'是什么意思?

解决方案

sync 这里是达到安全点所用的总时间。换句话说,它是保证点请求与所有可运行的Java线程最终被阻止之间的延迟。



安全点同步有时可能会花费太长时间,原因如下:


  • 应用程序没有获得足够的CPU时间,因为操作系统忙于密集磁盘I / O或启动时交换或其他高优先级进程占用所有CPU时间。

  • 某些Java线程执行长时间的不可中断操作,例如使用 System.arraycopy() clone() ByteBuffer复制大量数据。 get()等。

  • MappedByteBuffer I / O。 / ul>

    要在500 ms内记录无法在安全点上阻止的线程名称,请使用

      -XX:+ SafepointTimeout -XX:SafepointTimeoutDelay = 500 


    Sometimes I see long pauses in my gc.log

    2014-07-18T18:42:26.137+0400: 7846.980: [GC [PSYoungGen: 86267K->10032K(87744K)] 251198K-175254K(272512K), 0.0066190 secs] [Times: user=0.08 sys=0.00, real=0.01 secs]

    Total time for which application threads were stopped: 0.6394170 seconds

    Total time for which application threads were stopped: 0.0014570 seconds

    But these pauses don't affect GC time and CPU usage time.

    Safepoint statistics (+XX:PrintSafePointStatistics):

    vmop [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 7846.348: ParallelGCFailedAllocation [ 370 0 2 ] [ 0 0 630 1 7 ] 0

    (sync time = 630ms) What does 'sync' mean in this context?

    解决方案

    sync here is the total time spent to reach a safepoint. In other words, it is the latency between the safepoint request and the moment when all runnable Java threads are finally blocked.

    The safepoint synchronization may sometimes take too long due to one of the following reasons:

    • The application does not receive enough CPU time because the OS is busy with intensive disk I/O or when it starts swapping or when another high-priority process takes all CPU time.
    • Some Java thread performs long non-interruptible operation, e.g. copies large amount of data using System.arraycopy(), clone(), ByteBuffer.get() etc.
    • MappedByteBuffer I/O.

    To log the names of the threads that could not get blocked on a safepoint in 500 ms use

    -XX:+SafepointTimeout -XX:SafepointTimeoutDelay=500
    

    这篇关于ParallelGCFailedAllocation的大'同步'值的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆