福州智能建站,电子政务网站开发和设计的关系,肃宁县做网站价格,免费建立手机网站以下问题将测试您对Linux操作系统上运行的Java应用程序的垃圾回收和高CPU故障排除的知识。 当调查过多的GC和/或CPU利用率时#xff0c;此故障排除技术尤其重要。 它将假定您没有访问高级监视工具的能力#xff0c;例如Compuware dynaTrace甚至JVisualVM。 将来会介绍使用此类… 以下问题将测试您对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策略和服务器规范HotSpotJRockit JVM将创建一定数量的GC线程这些线程将执行旧空间和旧空间的收集。 通过生成JVM线程转储可以轻松识别此类线程。 如下面的示例所示Oracle JRockit JVM确实创建了4个GC线程标识为“GC Worker Thread X”。 FULL THREAD DUMP Fri Nov 16 19:58:36 2012BEA JRockit(R) R27.5.0-110-94909-1.5.0_14-20080204-1558-linux-ia32Main Thread id1 idx0x4 tid14911 prio5 alive, in native, waiting-- Waiting for notification on: weblogic/t3/srvr/T3Srvr0xfd0a4b0[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/T3Srvr0xfd0a4b0[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) id2 idx0x8 tid14920 prio5 alive, in native, daemon(GC Main Thread) id3 idx0xc tid14921 prio5 alive, in native, native_waiting, daemon(GC Worker Thread 1) id? idx0x10 tid14922 prio5 alive, in native, daemon(GC Worker Thread 2) id? idx0x14 tid14923 prio5 alive, in native, daemon(GC Worker Thread 3) id? idx0x18 tid14924 prio5 alive, in native, daemon(GC Worker Thread 4) id? idx0x1c tid14925 prio5 alive, in native, daemon……………………… 现在让我们通过一个简单的示例将所有这些原理放在一起。 步骤1 –监视GC线程CPU利用率 调查的第一步是监视并确定 通过Linux top -H 命令显示的每个GC工作线程标识本机线程ID。 确定每个GC工作线程的CPU。 步骤2 –生成和分析JVM线程转储 在Linux的顶部-H的同时 产生2个或3 JVM线程转储通过kill快照-3 JavaPID。 打开JVM线程转储然后找到JVM GC工作线程。 现在通过查看本机线程IDtid属性将“ top -H”输出数据与JVM Thread Dump数据相关联。 正如您在我们的示例中看到的那样这种分析确实使我们能够确定我们所有的GC工作线程每个都使用大约20的CPU。 这是由于当时发生了重大收藏。 请注意启用verbosegc也是非常有用的因为它将允许您将此类CPU峰值与次要和主要集合相关联并确定JVM GC进程对服务器总体CPU利用率的贡献程度。 参考 Java EE支持模式博客上的JCG合作伙伴 Pierre-Hugues Charbonneau提供的Linux上的HotSpot GC线程CPU占用空间 。 翻译自: https://www.javacodegeeks.com/2013/04/hotspot-gc-thread-cpu-footprint-on-linux.html
