jboss 占用cpu 100%

通过Java thread dump分析找到耗费CPU最高的源代码

分类: 9. Java2010-04-11 23:06 9272人阅读 评论(4) 收藏 举报

threadjavaeclipse插件redhatjbosslinux

通过Java thread dump分析找到耗费CPU最高的源代码

作者:胡家辉 2010-04-11

最近产品在运行过程中出现了性能问题,在很低的流量的情况下CPU就达到40%,流量稍高时CPU就达到98%。

产品是Java写的,运行于JBOSS平台。操作系统为redhat linux。当你通过top命令发现你的应用程序的进程占用CPU达98%时,我想你肯定想知道究竟是哪个地方耗费了如此的CPU处理时间。通过thread dump分析就可以找到,但这只是解决问题的第一步,即找到问题的所在。

首先:如何产生thread dump日志?

第一步:找到应用程序所在的进程号,通过top命令可以找到,不详述。

第二步:执行kill -3 pid获取thread dump日志(pid就是第一步获取到的)。注意:在不同的linux环境下执行输出的日志的地方可能不同。在IBM的PowerPC小型机上的linux上执行kill -3 pid会在工作目录下产生类似javacore.20100409.161739.7614.0001.txt的文件。而在我所在的环境中,thread dump信息输出到JBOSS的日志文件中的。

其次:获取线程信息

大多数服务器应用都是多线程,因此必须查到具体是哪些线程占用的CPU高。通过top –H命令可以查看到应用程序的线程信息及占用CPU的情况。

如下所示:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

4280 nbg-syst  18   0 3608m 2.0g  21m R 93.6 25.9   5004:49 java

4279 nbg-syst  18   0 3608m 2.0g  21m R 92.6 25.9   4876:40 java

4281 nbg-syst  18   0 3608m 2.0g  21m R 92.6 25.9   3892:54 java

4282 nbg-syst  18   0 3608m 2.0g  21m R 91.2 25.9   4954:40 java

4244 nbg-syst  15   0 3608m 2.0g  21m S  3.3 25.9 168:34.04 java

PID所在的列即是对应的线程ID,这是十进制的。

最后:找到耗费CPU高的线程及对应的源代码

取上面耗费CPU最高的第一行的PID 4280,将其转化为十六进制得到0x10b8。然后在thread dump日志中搜索0x10b8,将会搜到如下信息:

"Stack.ClientSelector-1" daemon prio=10 tid=0x000000004baeec00 nid=0x10b8 runnable [0x0000000053169000..0x0000000053169c90]

java.lang.Thread.State: RUNNABLE

at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)

at sun.nio.ch.EPollArrayWrapper.poll(Unknown Source)

at sun.nio.ch.EPollSelectorImpl.doSelect(Unknown Source)

at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)

- locked <0x00002aaac4105468> (a sun.nio.ch.Util$1)

- locked <0x00002aaac4131670> (a java.util.Collections$UnmodifiableSet)

- locked <0x00002aaac3f79c78> (a sun.nio.ch.EPollSelectorImpl)

at sun.nio.ch.SelectorImpl.select(Unknown Source)

at com.*****.warlock.protocolstack.impl.layer2.nio.ActiveSelectorImpl.callSelect(ActiveSelectorImpl.java:288)

at com. *****.warlock.protocolstack.impl.layer2.nio.ActiveSelectorImpl.run(ActiveSelectorImpl.java:163)

上面日志中的nid即是线程号。这样可以清晰的看到耗费CPU的源代码的具体位置,可以精确到行号。

备注:上面有部分采用*****是为了屏蔽公司版权信息而设置的,不是*哈。以上举例都是基于HP Blade硬件,redhat企业版操作系统和Sun的JDK。

结束语:thread dump的作用远不只一点,比如还可以从中发现很多应用程序运行问题,比如死锁等。对于该日志还有一个Eclipse插件的可视化分析工具lockness,我试了一下感觉不错。大家可以参考(3)。

下面是关于这个话题的很好的参考资料,一并列出供大家参考。

参考文献:

(1)       http://weblogic.sys-con.com/node/44027 Analyzing Java Application Problems--Using Java thread dumps to assess the problem

(2)       http://publib.boulder.ibm.com/infocenter/wasinfo/v4r0/index.jsp?topic=/com.ibm.support.was40.doc/html/100__CPU_Usage/swg21162381.html Determining which Java thread is consuming CPU cycles on Solaris systems

(3)       http://lockness.plugin.free.fr/home.php Lockness Eclipse Plugin for thread dump GUI analysis tool

jboss 占用cpu 100%,布布扣,bubuko.com

时间: 2025-01-05 00:35:18

jboss 占用cpu 100%的相关文章

nova-conductor单个进程占用CPU 100%

nova-conductor进程在运行时,其中单个进程会周期性的占用CPU 100%的使用率,周期大约2分钟.经调试和排查,发现原因在于nova-conductor在执行某一数据库操作时,请求数据量巨大, 仅数据库查找耗时10s,返回数据大小在2MB.导致数据在进行序列化和解序列化时耗尽CPU,并持续时间较长.详情如下: 操作请求:object_class_action 请求参数:{u'objver': u'1.6', u'objmethod': u'get_by_filters', u'arg

使用dotnet-dump 查找 .net core 3.0 占用CPU 100%的原因

公司的产品一直紧跟 .net core 3.0 preview 不断升级, 部署到 Linux 服务器后, 偶尔会出现某个进程CPU占用100%. 由于服务部署在云上, 不能使用远程调试; 在局域网内的Linux 服务器 或 Windows开发机上又不能重现这个问题, 联想到Java的jstack, 很是羡慕啊. 想到.net core 已经出来这么久了, 还是试着找找看吧, 结果还真找到一篇博客Introducing diagnostics improvements in .NET Core

MySQL 占用cpu 100%

目前的线上数据库,分为主从两个库,从库用来做比较耗时的数据统计分析. 今天top了一下从库服务器,发现mysqld 在很长一段时间都占用105% cpu,一开始以为是从库在处理主库的binlog. 两分钟后,发现不对,单次主从同步不会超过5秒的. 进入mysql命令行 show full processlist  \G; 一个查询线程正在执行.sql 中使用了 in 关键字.非常耗时,几乎不会停止. kill query process_id<查询线程的id> 杀死了这个进程. 果然,cpu

Linux tracker 占用cpu 100%解决

Tracker is used (by gnome) to index files to make them searchable and appear automatically in some programs (like Rhythmbox for music files, etc). More info from the Ubuntu wiki on it here https://wiki.ubuntu.com/Tracker. You can do a hard reset of t

记录Macbook UserEventAgent占用内存20G、CPU 100%的解决方法

现象:开机或登录,UserEventAgent占用CPU 100%,内存占用每秒疯狂增长,达到过20G被Force Quit 可重现:100%重现 解决方法:Repair Disk Permissions 以下是相同案例,但通过禁止某些系统启动项 来解决的 https://discussions.apple.com/message/26003314#message26003314 http://forums.macrumors.com/threads/usereventagent-using-1

千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记

千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记 2007年3月,我写过一篇文章<解决一个 MySQL 服务器进程 CPU 占用 100%的技术笔记>( http://www.xiaohui.com/weekly/20070307.htm ),谈到自己在解决一个拥有 60 万条记录的 MySQL 数据库访问时,导致 MySQL CPU 占用 100% 的经过.在解决问题完成优化(optimize)之后,我发现 Discuz 论坛也存在这个问题,当时稍微提了一下: 发现此主

PHP CGI 进程占用CPU过高导致CPU使用达到100%的另类原因

由于使用的华为云的CDN加速,结果发现我的阿里云服务器突然卡顿,网页打开极慢.登陆华为云CDN管理后台发现最高带宽占用30M,流量短时间内达到10GB以上,这么大的流量我的服务器肯定扛不住啊.于是还跟华为云进行了一个撕逼,然后果断弃了华为云. 但是更换了其他CDN或者WAF之后,CPU占用依然居高不下,网上找了很多办法都不管用. 看了下是 PHP CGI 进程占用CPU最多,而且经过检测发现是 浏览器内核检测 网站的 PHP CGI 占用最高,其他的很少.然而看第三方网站统计,并没有很大的访问量

Linux系统cpu 100%修复案例

Linux系统cpu 100%修复案例 ?阿里云技术支持团队:完颜镇江 案例背景: Linux主机连续三天CPU% 处理思路: 1.  登录服务器查看/var/log/messages+/var/log/messages.1+/var/log/messages.3里恰好没那三天的日志 2.  dmesg里也无有用的信息 ? 3.  至此怀疑是被攻击了,自然而然的去看对应时间点的带宽占用情况,查看之后发现带宽一切正常,继续排查 4.  怀疑是某个程序的异常,首先的从web进程开始查,通过httpd

记一次mogodb占用cpu高问题

公司服务器上安装了contly,是一个开源的node.js项目,用于统计手机app使用情况,后端数据储存使用的mongodb,使用的时候经常发现mongodb占用cpu非常高,打到了210%的爆表值 top - 13:42:39 up 308 days, 23:01, 2 users, load average: 2.84, 2.96, 2.93 Tasks: 209 total, 1 running, 208 sleeping, 0 stopped, 0 zombie %Cpu(s): 59.