可视VM显示异常行为 [英] Visual VM showing strange behavior

查看:90
本文介绍了可视VM显示异常行为的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用VisualVM监视我的JBoss实例。我也附上了它的屏幕截图。

I am using VisualVM to monitor my JBoss instance. I have attached a screenshot of it aswell.

问题是我重新启动JBoss实例后,操作系统上的CPU开始变高。负载可能高达40,并且top命令中的JAVA进程显示使用率高达300%。

The problem is after I restart the JBoss instance, the CPU on the OS starts to go high. Load can go as high as 40 and JAVA process in top command shows upto 300% usage.

然后继续降低前端应用程序的速度。

This then goes on to slow down the application at the front end.

VisualVM显示CPU容量过高并且线程数也在增加。

VisualVM shows that CPU is high and that thread count is increasing also.

我该如何进一步找出问题的根源?

How can I further go to the root cause of this ?

Visual VM输出-常规

推荐答案

对于高CPU使用率,我通常会寻找两件事:

When it comes to high CPU usage, I generally look for two things :


  1. 频繁使用GC的CPU

  2. 消耗CPU的线程

要进一步诊断#1,启用GC日志记录可能是最好的方法。但是,您也可以使用jstat:

To diagnose #1 further, enabling GC Logging may be the best way. However, you can use jstat as well:


jstat -gc PID 60s

jstat -gc PID 60s

上面的命令每60秒钟从JVM收集一次内存使用情况和垃圾回收详细信息。在调试环境中,60s应该可以,但是在生产环境中,3600s就足够了。 jstat的重量很轻,不会造成任何不利影响。输出将帮助您了解是否存在频繁的GC(主要/次要)。频繁的主要收集肯定是一个问题(它会暂停应用程序),但是,非常频繁的次要收集也会导致CPU占用过多(应用程序过于频繁地创建过多的垃圾)。在这种情况下,可能需要先进行转储,并且需要了解应用程序的内存使用详细信息,但在此之前不需要了解。请记住,捕获堆转储可能会挂起您的应用程序(我不建议在生产环境中使用它,除非您可以在捕获数据后立即重新启动应用程序)。

The above command will collect the memory usage and garbage collection details from the JVM every 60s. In a debugging environment, 60s should be OK, but in a production environment 3600s should be sufficient. jstat being very light weight, doesn't create any adverse impact. The output will help you to understand if there are frequent GCs (major/minor). Frequent major collection is a problem for sure (it pauses the application), however, very frequent minor collection could also cause high CPU (application is creating too much of garbage too frequently). If this is the case, probably you need a head dump and you need to understand application's memory usage details, but not before that. Please remember, capturing heap dump may "hang" your application (I don't suggest it in production unless you can restart the application immediately after capturing the data).

要诊断2, top提供了一个选项( H)来检查各个线程消耗的CPU。这将(实时)指出正在消耗CPU的应用程序线程。另外(如其他人所建议),以10秒的间隔捕获5/6线程转储。查找处于RUNNABLE状态的线程。这些是正在工作并因此占用CPU的线程。同一(一组)线程在多个转储中是否处于Runnable状态?可能您遇到了问题。

To diagnose #2, "top" provides an option ("H") to check the CPU consumed by individual threads. That will point (in real time) the application threads which are consuming CPU. Also (as other's have suggested), capture 5/6 thread dumps in an interval of 10 seconds each. Looks for threads in RUNNABLE state. These are the threads which are doing work and hence occupying CPU. Is the same (set of) thread stuck in the Runnable state over multiple dumps? Probably you have got a problem.

希望这会有所帮助。祝你好运!

Hope this helps. Best of luck!

这篇关于可视VM显示异常行为的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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