我的应用程序安装在 JBOSS EAp 6.1 上。几天前,我们发现应用程序速度缓慢或最终用户无法访问该应用程序。
我们记录了ps -aux
日志,其中一个输出如下。
[Mon Jun 12 08:55:29.218 2017] 500 46257 90.7 10.2 22713508 6779044 ? Sl Apr26 61791:48 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.45.x86_64/jre/bin/java -D[Standalone] -server -XX:+UseCompressedOops -Xms2048m -Xmx4096m -XX:MaxPermSize=512m -Djava
看起来这个 java 进程占用了我的 CPU。而且它处于 Sl 模式。这是我的假设。
这可能是应用程序问题的原因吗?
cpu使用率高的原因可能是什么?
这个进程在JBOSS应用服务器中的作用是什么?
我们没有获取线程转储和 Gc 日志(后来我们检查了 gc 日志未启用)并重新启动了服务器。现在没有日志了。
答案1
您显示的输出不显示除作为服务器运行的 javavm 之外的任何应用程序。
当使用的内存接近极限时,Java 应用程序中经常会出现高 CPU 负载的情况。垃圾收集一直运行以再次释放内存。这会降低应用程序性能并占用几乎所有 CPU 周期。
由于您已经杀死了该进程,因此弄清楚它的机会就消失了。
对于未来我的建议是配置一种监控 JVM 的方法:
- 添加 GCLog 是一种简单的方法。
- 添加JMX远程监控(请添加身份验证!)参见: http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html
- 允许第三方代理直接连接到java虚拟机。
如果您再次遇到这种情况,您可以执行以下操作:
获取 Java 实例的 Java 堆栈跟踪:(
使用 PID 46257 运行的 Java)
jstack -l 46257 >jstack-output.log
然后进行堆转储以进一步分析:
jmap -dump:live,format=b,file=jmap-heapdump.hprof 46257
分析 hprof-heapdumps 可以通过各种工具来完成(google:java heapdump detector)。这可以帮助您更好地找到高 cpu 负载的原因。