代码之家 › 专栏 › 技术社区 › NateS user1274193

调试jboss 100%CPU使用率

cpu-usage web-applications jboss debugging java

NateS user1274193 · 技术社区 · 15 年前

最初发布 on Server Fault ,建议在哪里提出这个问题最好在这里提出。

我们用JBoss来发动两次战争。一个是我们的网络应用,另一个是我们的网络服务。Web应用程序访问另一台计算机上的数据库并向Web服务发出请求。Web服务向其他机器发出JMS请求,聚合数据并返回它。

在我们最大的客户中,每月大约有一次JBaseJava进程占用100%的CPU。运行jboss的机器有8个CPU。在这段时间内,我们的Web应用程序仍然可以访问,但是页面加载大约需要3分钟。重新启动jboss会将一切恢复到正常状态。

数据库机器和所有其他机器都很好,只影响运行jboss的机器。内存使用正常。网络使用正常。jboss日志中没有可疑的错误消息。

我已经建立了一个尽可能接近客户机生产环境的测试环境,并且我已经用最多两倍的并发用户进行了负载测试。我还没有让我的测试环境来复制这个问题。

我们从这里去哪里?我们如何缩小这个问题的范围?

目前我们唯一的计划是等待问题在生产中自行发生,然后进行一些调试以确定原因。到目前为止,人们刚刚重新启动了JBoss,这是为了减少停机时间。下次发生这种情况时,他们会让开发人员来看看。问题是,下次发生这种情况时,可以采取什么措施来确定原因?

我们可以在同一个框中设置单独的JBoss实例,并将Web应用程序与Web服务分开安装。这样,当问题下次出现时,我们就会知道哪场战争有问题(假设这是我们的代码)。但这并不能缩小范围。

我应该启用JMX远程吗?这样,下次出现问题时,我可以连接到VisualVM,查看哪些线程占用了CPU,它们到底在做什么。但是,在生产环境中启用JMX远程是否存在显著的缺点?

有没有另一种方法来查看哪些线程正在占用CPU,并获取stacktrace来查看它们在做什么?

还有其他想法吗?

谢谢!

4 回复 | 直到 13 年前

Alexander Torstling 15 年前

我认为您应该尝试通过一些负载测试来建立一个测试环境,以便重现您的问题。分析无疑有助于查明问题所在。

一个快速的解决方法是下次用kill-3杀死jboss,以便得到一个转储文件进行分析。我要检查的第二件事是,您正在使用-server标志运行,并且您的GC设置是正常的。您还可以运行一些DStat来查看锁定期间的进程。但是再次强调——仅仅建立一个负载测试环境(通过EC2或其他方式)来重现这一点可能更安全。

skaffman 15 年前

有一种快速而肮脏的方法来识别哪些线程占用了JBoss上的CPU时间。使用浏览器进入JMX控制台(通常打开 http://localhost:8080/jmx-console ,但对你来说可能不同),找一个叫 ServerInfo ,它有一个名为 listThreadCpuUtilization 它以一种良好的表格格式转储每个活动线程使用的实际CPU时间。如果有一种行为不端,它通常会像拇指疼痛一样突出。

还有 listThreadDump 将每个线程的堆栈转储到浏览器的操作。

虽然不如分析器好,但它是获取基本信息的更简单的方法。对于生产服务器来说,连接分析器通常是坏消息,它非常方便。

krosenvold 15 年前

这通常发生在对哈希映射的失控代码或不安全的线程访问中。一个简单的线程转储(kill-3,如@disown所说,或者在Windows控制台中使用ctrl-break)将揭示这个问题。

由于您无法使用测试来重现它,我认为这有点像并发问题;通常很难让测试脚本行为足够随机以捕获此类问题。

我通常会尝试将执行线程转储的标准操作过程任何由于操作异常而重新启动的JVM,它实际上是每月捕获这些内容的一个需求。

Sabahat Theem 13 年前

如果您使用的是JBoss5.1.0EAP,那么JBoss中有一个bug,它们也有一个修复程序。以下是网址: https://issues.jboss.org/browse/JBPAPP-5193