以下问题将测试您对Linux操作系统上运行的Java应用程序的垃圾回收和高CPU故障排除的知识。 当调查过多的GC和/或CPU利用率时,此故障排除技术尤其重要。 它将假定您没有访问高级监视工具的能力,例如Compuware dynaTrace甚至JVisualVM。 将来会介绍使用此类工具的未来教程,但请确保您首先掌握基本的故障排除原理。
题:
在Linux OS上,如何在运行时监视和计算每个Oracle HotSpot或JRockit JVM垃圾回收(GC)线程使用了多少CPU%?
回答:
在Linux OS上,Java线程被实现为本机线程,这导致每个线程是一个单独的Linux进程。 这意味着您可以使用top -H 命令 (“线程”切换视图)监视HotSpot JVM创建的任何Java线程的CPU%。
也就是说,根据您使用的GC策略和服务器规范,HotSpot&JRockit JVM将创建一定数量的GC线程,这些线程将执行旧空间和旧空间的收集。 通过生成JVM线程转储,可以轻松识别此类线程。 如下面的示例所示,Oracle JRockit JVM确实创建了4个GC线程,标识为“(GC Worker Thread X)”。
===== FULL THREAD DUMP ===============
Fri Nov 16 19:58:36 2012
BEA JRockit(R) R27.5.0-110-94909-1.5.0_14-20080204-1558-linux-ia32
"Main Thread" id=1 idx=0x4 tid=14911 prio=5 alive, in native, waiting
-- Waiting for notification on: weblogic/t3/srvr/T3Srvr@0xfd0a4b0[fat lock]
at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)
at java/lang/Object.wait(J)V(Native Method)
at java/lang/Object.wait(Object.java:474)
at weblogic/t3/srvr/T3Srvr.waitForDeath(T3Srvr.java:730)
^-- Lock released while waiting: weblogic/t3/srvr/T3Srvr@0xfd0a4b0[fat lock]
at weblogic/t3/srvr/T3Srvr.run(T3Srvr.java:380)
at weblogic/Server.main(Server.java:67)
at jrockit/vm/RNI.c2java(IIIII)V(Native Method)
-- end of trace
"(Signal Handler)" id=2 idx=0x8 tid=14920 prio=5 alive, in native, daemon
"(GC Main Thread)" id=3 idx=0xc tid=14921 prio=5 alive, in native, native_waiting, daemon
"(GC Worker Thread 1)" id=? idx=0x10 tid=14922 prio=5 alive, in native, daemon
"(GC Worker Thread 2)" id=? idx=0x14 tid=14923 prio=5 alive, in native, daemon
"(GC Worker Thread 3)" id=? idx=0x18 tid=14924 prio=5 alive, in native, daemon
"(GC Worker Thread 4)" id=? idx=0x1c tid=14925 prio=5 alive, in native, daemon
………………………
现在,让我们通过一个简单的示例将所有这些原理放在一起。
步骤#1 –监视GC线程CPU利用率
调查的第一步是监视并确定:
步骤#2 –生成和分析JVM线程转储
在Linux的顶部-H的同时 ,产生2个或3 JVM线程转储通过kill快照-3 <JavaPID>。
- 打开JVM线程转储,然后找到JVM GC工作线程。
- 现在,通过查看本机线程ID(tid属性),将“ top -H”输出数据与JVM Thread Dump数据相关联。
正如您在我们的示例中看到的那样,这种分析确实使我们能够确定我们所有的GC工作线程每个都使用大约20%的CPU。 这是由于当时发生了重大收藏。 请注意,启用verbose:gc也是非常有用的,因为它将允许您将此类CPU峰值与次要和主要集合相关联,并确定JVM GC进程对服务器总体CPU利用率的贡献程度。
翻译自: https://www.javacodegeeks.com/2013/04/hotspot-gc-thread-cpu-footprint-on-linux.html