似乎正在等待的线程的CPU使用率高

  • Z时代
  • 2024-01-10
  • 分类：问答

我目前正在运行一些JMeter测试，以测试Web服务的性能。它使用了大量的CPU。对于一个JMeter请求线程，它的使用率在10％到30％之间（取决于请求的类型）。当我将其最多泵入15个线程时，我获得了约95％的CPU使用率。自然，我想弄清楚发生了什么。我做了一个Hprof

CPU示例（我尝试了times选项，但是花了一个半小时才开始我的服务，并且没有消息通过）。以下是该采样结果的摘要（跨15分钟）。

CPU SAMPLES BEGIN（总计= 220846）2014年8月22日星期五
等级自累计数跟踪方法
   1 14.96％14.96％33038 300514 java.net.PlainSocketImpl.socketAccept
   2 14.84％29.80％32776 301258 sun.nio.ch.EPollArrayWrapper.epollWait
   3 12.45％42.26％27505 313002 sun.nio.ch.EPollArrayWrapper.epollWait
   4 7.48％49.73％16517 300604 java.net.PlainSocketImpl.socketAccept
   5 7.18％56.91％15856 303203 sun.nio.ch.EPollArrayWrapper.epollWait
   6 6.18％63.09％13639 313001 sun.nio.ch.ServerSocketChannelImpl.accept0
   7 6.04％69.13％13329 304259 sun.nio.ch.Epoll.epoll等待
   8 5.11％74.23％11275 307102 sun.nio.ch.EPollArrayWrapper.epollWait

以及那些顶级样本的对应堆栈：

跟踪300514：
    java.net.PlainSocketImpl.socketAccept（：未知行）
    java.net.AbstractPlainSocketImpl.accept（：未知行）
    java.net.ServerSocket.implAccept（：未知行）
    java.net.ServerSocket.accept（：未知行）
    sun.rmi.transport.tcp.TCPTransport $ AcceptLoop.executeAcceptLoop（：未知行）
    sun.rmi.transport.tcp.TCPTransport $ AcceptLoop.run（：未知行）
    java.lang.Thread.run（：未知行）
TRACE 301258：
    sun.nio.ch.EPollArrayWrapper.epollWait（：未知行）
    sun.nio.ch.EPollArrayWrapper.poll（：未知行）
    sun.nio.ch.EPollSelectorImpl.doSelect（：未知行）
    sun.nio.ch.SelectorImpl.lockAndDoSelect（：未知行）
    sun.nio.ch.SelectorImpl.select（：未知行）
    org.apache.tomcat.util.net.NioBlockingSelector $ BlockPoller.run（NioBlockingSelector.java:327）
TRACACE 313002：
    sun.nio.ch.EPollArrayWrapper.epollWait（：未知行）
    sun.nio.ch.EPollArrayWrapper.poll（：未知行）
    sun.nio.ch.EPollSelectorImpl.doSelect（：未知行）
    sun.nio.ch.SelectorImpl.lockAndDoSelect（：未知行）
    sun.nio.ch.SelectorImpl.select（：未知行）
    org.apache.tomcat.util.net.NioEndpoint $ Poller.run（NioEndpoint.java:1163）
    java.lang.Thread.run（：未知行）
跟踪300604：
    java.net.PlainSocketImpl.socketAccept（：未知行）
    java.net.AbstractPlainSocketImpl.accept（：未知行）
    java.net.ServerSocket.implAccept（：未知行）
    java.net.ServerSocket.accept（：未知行）
    sun.management.jmxremote.LocalRMIServerSocketFactory $ 1.accept（：未知行）
    sun.rmi.transport.tcp.TCPTransport $ AcceptLoop.executeAcceptLoop（：未知行）
    sun.rmi.transport.tcp.TCPTransport $ AcceptLoop.run（：未知行）
    java.lang.Thread.run（：未知行）
TRACE 303203：
    sun.nio.ch.EPollArrayWrapper.epollWait（：未知行）
    sun.nio.ch.EPollArrayWrapper.poll（：未知行）
    sun.nio.ch.EPollSelectorImpl.doSelect（：未知行）
    sun.nio.ch.SelectorImpl.lockAndDoSelect（：未知行）
    sun.nio.ch.SelectorImpl.select（：未知行）
    net.spy.memcached.MemcachedConnection.handleIO（MemcachedConnection.java:217）
    net.spy.memcached.MemcachedConnection.run（MemcachedConnection.java:836）
TRACE 313001：
    sun.nio.ch.ServerSocketChannelImpl.accept0（：未知行）
    sun.nio.ch.ServerSocketChannelImpl.accept（：未知行）
    org.apache.tomcat.util.net.NioEndpoint $ Acceptor.run（NioEndpoint.java:793）
    java.lang.Thread.run（：未知行）
TRACE 304259：
    sun.nio.ch.EPoll.epollWait（：未知行）
    sun.nio.ch.EPollPort $ EventHandlerTask.poll（：未知行）
    sun.nio.ch.EPollPort $ EventHandlerTask.run（：未知行）
    java.lang.Thread.run（：未知行）
TRACE 307102：
    sun.nio.ch.EPollArrayWrapper.epollWait（：未知行）
    sun.nio.ch.EPollArrayWrapper.poll（：未知行）
    sun.nio.ch.EPollSelectorImpl.doSelect（：未知行）
    sun.nio.ch.SelectorImpl.lockAndDoSelect（：未知行）
    sun.nio.ch.SelectorImpl.select（：未知行）
    net.spy.memcached.MemcachedConnection.handleIO（MemcachedConnection.java:217）
    net.spy.memcached.MemcachedConnection.run（MemcachedConnection.java:836）

如您所见，超过一半的CPU使用率似乎来自应该等待的线程。那不应该占用CPU时间吗？

我看到了该线程http://www.brendangregg.com/blog/2014-06-09/java-cpu-sampling-using-

hprof.html，这可能使我认为此结果具有误导性，但我的“ top

-H”结果显示最大的CPU使用率，Zabbix监视也是如此。因此，看来它实际上是在消耗CPU。但是，这里有一个指向hprof作者的报价的链接，其中指出：

如果您有Java线程以某种方式不使用CPU，而是设法保持活动状态，那么看起来好像这些堆栈跟踪在不使用它们时正在消耗大量的CPU时间。

有人可以解释为什么会这样吗，在这些情况下我可以做些什么来减少CPU使用率？还是所有CPU使用率指标实际上都具有误导性？如果是这样，什么是了解我的服务中真实CPU利用率的更好方法？

回答：

正如Brendan

Gregg指出您链接的博客文章一样，JVM认为可运行的所有线程中的hprof示例。如您在Thread.state的Javadoc中所见，JVM区分以下线程状态：

  • 新：尚未启动的线程处于此状态。

  • 可运行：在Java虚拟机中执行的线程处于此状态。

  • BLOCKED：处于等待监视器锁定状态的被阻塞线程处于此状态。

  • 等待：无限期等待另一个线程执行特定操作的线程处于此状态。

  • TIMED_WAITING：正在等待另一个线程执行操作的线程最多达到指定的等待时间，该线程处于此状态。

  • 终止：退出的线程处于此状态。

如我们所见，JVM没有专用于等待I /

O的线程的状态。这是因为这样的线程实际上是由操作系统而不是JVM阻止的。也就是说，就JVM而言，等待网络适配器的线程是可运行的。实际上，用于RUNNABLE状态的详细Javadoc写道：

可运行线程的线程状态。处于可运行状态的线程正在Java虚拟机中执行，但它可能正在等待来自操作系统（例如处理器）的其他资源。

因此，在hprof“ cpu”采样中存在I / O方法并不表示这些方法消耗了CPU，因为它们的等待时间也被计算在内。

您可以：

  • 假定I / O方法不导致CPU消耗，并着重于其他方法

  • 使用更好的探查器，将等待操作系统级别的资源考虑在内

以上是 似乎正在等待的线程的CPU使用率高 的全部内容， 来源链接： utcz.com/qa/427403.html

回到顶部