完整的GC实时性远远超过用户+系统时间 [英] Full GC real time is much more that user+sys times

查看:114
本文介绍了完整的GC实时性远远超过用户+系统时间的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们有一个在JBoss上运行的基于Web Java的应用程序,允许最大堆大小约为1.2 GB(总机器物理内存为2 GB)。在某些时候,应用程序停止响应(对客户端)几分钟。经过一番分析后,我们发现罪魁祸首是Full GC。以下是详细的GC日志摘录:

74477.402:[Full GC [PSYoungGen:3648K-> 0K(332160K)] [PSOldGen:778476K-> 589497K(819200K) ] 782124K-> 589497K(1151360K)[PSPermGen:102671K-> 102671K(171328K)],646.1546860秒] [times:user = 3.84 sys = 3.72,real = 646.17 secs]

b
$ b

我不明白在完整GC上花费的时间实时大概是11分钟(646秒),而用户+系统时间仅为7.5秒。对我而言,7.5秒的声音更适合用于清洁老一代的200 MB以上的合理时间。其他时间去哪里?

非常感谢。

解决方案

< blockquote>

所有其他时间去哪里?

这很可能是您的应用程序导致虚拟内存抖动。基本上,您的应用程序需要更多的虚拟内存页面,而不是可用于保存虚拟内存的物理页面。因此,它花费大部分时间等待vm页面读取和写入光盘。



有关更多信息,请阅读本维基百科页面



治疗方法是或者减少虚拟内存使用量或增加系统上的物理内存量。例如,您可以:


  • 在机器上运行更少的应用程序,
  • 减少Java应用程序堆大小或

  • ,如果您正在虚拟中运行,则会增加虚拟物理内存的分配。



  • (请注意,减少JVM堆大小可以是一把双刃剑,如果太多地减小堆大小,应用程序将会死于OutOfMemoryErrors,花费太多时间垃圾收集,或者无法缓存事情有效。)


    We have a Web Java based application running on JBoss with allowed maximum heap size of about 1.2 GB (total machine physical memory is 2 GB). At some point the application stops responding (to clients) for several minutes. After some analysis we found out that the culprit is the Full GC. Here's an excerpt from the verbose GC log:

    74477.402: [Full GC [PSYoungGen: 3648K->0K(332160K)] [PSOldGen: 778476K->589497K(819200K)] 782124K->589497K(1151360K) [PSPermGen: 102671K->102671K(171328K)], 646.1546860 secs] [Times: user=3.84 sys=3.72, real=646.17 secs]

    What I don't understand is how is it possible that the real time spent on Full GC is about 11 minutes (646 seconds), while user+sys times are just 7.5 seconds. 7.5 seconds sound to me much more logical time to spend for cleaning <200 MB from the old generation. Where does all the other time go?

    Thanks a lot.

    解决方案

    Where does all the other time go?

    It is most likely that your application is causing virtual memory thrashing. Basically, your application needs significantly more pages of virtual memory than there are physical pages available to hold them. As a result, it is spending most of the time waiting for vm pages to be read from and written to disc.

    For more information, read this wikipedia page.

    The cure is to either reduce virtual memory usage or increase the amount of physical memory on the system. For example, you could:

    • run fewer applications on the machine,
    • reduce Java application heap sizes, or
    • if you are running in a virtual, increase the virtual's allocation of physical memory.

    (Note however that reducing the JVM heap size can be a two-edged sword. If you reduce the heap size too much the application will either die from OutOfMemoryErrors, spend too much time garbage collecting, or suffer from not being able to cache things effectively.)

    这篇关于完整的GC实时性远远超过用户+系统时间的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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