从CLI监视OpenJDK

最新推荐文章于 2023-03-17 06:21:08 发布

dnc8371

最新推荐文章于 2023-03-17 06:21:08 发布

阅读量278

点赞数 1

文章标签： java linux jvm python 编程语言

目前，我大部分时间在Java虚拟机（JVM）内或周围进行大量工作，大部分时间是在Linux上。

当事情变得不对劲并且我试图确定原因时，我接触了Java性能分析工具。这些工具有两种形式，一种是精美的GUI（称为visualvm），当我在本地计算机上工作时会使用它；另一种是Java开发工具包（JDK）附带的cli工具（当我在远程工作时使用）。

我指的CLI工具是：

我最常用的工具是jps，jstat和jstack，jahat工具也非常方便，但实际上确实需要一个完整的博客文章，因为您疯狂地使用它可以做什么。在这篇文章中，我整理了一些技巧，观察和示例输出，以说明如何使用它们。

当我使用ubuntu 11.10（仅安装Java运行时环境（JRE））时，我将需要安装JDK。就我而言，我决定尝试一下openjdk 7，但是版本6可以正常工作。

root@oneric:~# apt-get install openjdk-7-jdk

要尝试这些命令，我已经安装了tomcat7，可以通过ubuntu上的apt来完成，同样，以前的版本是tomcat 6。

root@oneric:~# apt-get install tomcat7

现在我已经安装了tomcat，我想列出Java进程，请注意，这样做时最好假定使用与服务相同的用户帐户。在ubuntu上，我将使用用户帐户，因为tomcat7用户是系统帐户，我必须覆盖shell，因为默认情况下它是/ bin / nologin ，然后我可以以该用户身份运行jps。

jps命令输出java进程的PID以及启动时传递给它的主类名称和参数。

root@oneric:~# su - tomcat7 -s /bin/bash 
tomcat7@oneric:~$ jps -ml
12728 org.apache.catalina.startup.Bootstrap start
13926 sun.tools.jps.Jps -ml
tomcat7@oneric:~$

现在我们有了这些进程的PID，可以运行jstat了，我使用的第一个开关是-gcutil，这使我对jvm中的堆使用有了一个总体了解。如果出现暂停或性能下降的情况，我将查看最后两列。其中包含垃圾收集时间（GCT）和完整垃圾收集时间（FGCT）。如果FGCT列每秒增加一次，则可能是我们遇到了问题。

下面的示例针对tomcat的PID运行jstat 。我还指示该命令每20行显示表头并以1000毫秒的间隔连续打印统计信息，就像正常的控件C一样，在输出末尾显示。

此示例显示了一个很少发生的新启动的tomcat 7，这从完全垃圾收集时间（FGCT）和垃圾收集时间（GCT）列中的值可以清楚地看出。

还要注意的是，目前的Permgen空间（P）占70％。 permgen空间是堆的重要区域，因为它保存用户类，方法名称和内部jvm对象。如果您使用tomcat已有一段时间，您将看到java.lang.OutOfMemoryError：PermGen空间错误，该错误指示何时该空间被填满并且无法被垃圾回收。重新部署大型Web应用程序时经常发生这种情况。

同样在示例中，我们可以看到幸存者0（S0），幸存者1（S1），伊甸园和旧空间具有相当大的可用空间。

tomcat7@oneric:~$ jstat -gcutil -h20 12728 1000
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
  0.00  17.90  32.12   4.81  71.41      5    0.009     1    0.023    0.032
  0.00  17.90  32.12   4.81  71.41      5    0.009     1    0.023    0.032
  0.00  17.90  32.12   4.81  71.41      5    0.009     1    0.023    0.032

为了说明相比之下，tomcat的负载情况，我们可以安装一个称为Apache Bench的工具。

root@oneric:~# apt-get install apache2-utils

并运行以下命令以同时访问具有大量请求的基本页面。

markw@oneric:~$ ab -n 1000000 -c 100 http://localhost:8080/

下面是该测试运行了一段时间后的输出，因为我们可以看到幸存者1，伊甸园和旧空间有了相当大的增长，但是服务器并没有花费很多时间来进行完整的垃圾收集，如下所示完整垃圾收集计数（FGC）的值只有10，从年轻一代收集计数（YGC）的增加可以看出，大部分工作是在年轻一代中进行的。

还要注意的是，permgen空间没有太多变化，实际上下降了，这是由于堆大小的增加。

tomcat7@oneric:~$ jstat -gcutil -h20 12728 1000
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
  0.00 100.00  52.02  81.84  59.62    117    1.176    10    0.074    1.250
  0.00 100.00  52.02  81.84  59.62    117    1.176    10    0.074    1.250
  0.00 100.00  52.02  81.84  59.62    117    1.176    10    0.074    1.250
  0.00 100.00  52.02  81.84  59.62    117    1.176    10    0.074    1.250

为了更深入地了解垃圾收集的原因，我们使用了带有-gccause选项的jstat命令，该命令显示的列与上一个命令相同，但有两个额外的列提供了GC的原因。

在下面的示例中，我们可以看到分配失败的示例，这表明由于堆太小，正在执行完整的gc。

tomcat7@oneric:~$ jstat -gccause -h20 12728 1000
100.00   0.00   0.00  78.91  59.67    168    1.680    14    0.083    1.763 unknown GCCause      No GC               
100.00   0.00  72.61  83.73  59.67    170    1.698    14    0.083    1.781 unknown GCCause      No GC               
  0.00 100.00  46.24  91.83  59.67    173    1.729    14    0.083    1.811 unknown GCCause      No GC               
100.00   0.00  11.39  29.80  59.67    176    1.759    16    0.086    1.846 unknown GCCause      No GC               
100.00   0.00  92.41  35.30  59.67    179    1.777    16    0.086    1.864 unknown GCCause      Allocation Failure  
  0.00 100.00  62.58  43.05  59.67    181    1.803    16    0.086    1.889 unknown GCCause      No GC

诊断性能问题时，我还想研究的另一个领域是虚拟机中运行的线程。这可以帮助我理解是否有任何组件超载，因此可以运行许多线程来追赶。这主要仅适用于异步过程，例如消息传递或调度例程。

要转储线程及其当前堆栈的列表，请使用jstack命令，如下面的示例所示，我通常再次以进程所有者的身份运行它。

tomcat7@oneric:~$ jstack 12728
2011-10-16 14:53:58
Full thread dump OpenJDK 64-Bit Server VM (20.0-b11 mixed mode):

"Attach Listener" daemon prio=10 tid=0x00000000015be800 nid=0x4004 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"http-bio-8080-exec-182" daemon prio=10 tid=0x00007f9d84274800 nid=0x3cd3 waiting on condition [0x00007f9d7a0df000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000ef16da38> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject. await(AbstractQueuedSynchronizer.java:2043)
        at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
        at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
        at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:679)
...

我计划用jruby在一些可视化工具上做一些工作，但是这可能是我下一篇文章的重点。在撰写本文的过程中，我找到了一些有趣的文章，这些文章链接如下：

参考： Mark Wolfe博客上的 JCG合作伙伴 Mark Wolfe 从CLI监视OpenJDK 。

相关文章：

翻译自: https://www.javacodegeeks.com/2011/10/monitoring-openjdk-from-cli.html

dnc8371

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
从CLI监视OpenJDK

目前，我大部分时间在Java虚拟机（JVM）内或周围进行大量工作，大部分时间是在Linux上。当事情变得不对劲并且我试图确定原因时，我接触了Java性能分析工具。这些工具有两种形式，一种是精美的GUI（称为visualvm），当我在本地计算机上工作时会使用它；另一种是Java开发工具包（JDK）附带的cli工具（当我在远程工作时使用）。我指的CLI工具是： jps – ...
复制链接

扫一扫