Question

我使用了很多客户端向服务器发送一个请求，每秒客户端大约有1000个请求，服务器的CPU很快升到600％（8个核心），并始终保持这种状态。当我使用jstack打印处理内容时，我发现SelectorImpl处于BLOCKED状态。记录如下：

nioEventLoopGroup-4-1 prio=10 tid=0x00007fef28001800 nid=0x1dbf waiting for monitor entry [0x00007fef9eec7000]
java.lang.Thread.State: BLOCKED (on object monitor)
at sun.nio.ch.EPollSelectorImpl.doSelect(Unknown Source)
- waiting to lock <0x00000000c01f1af8> (a java.lang.Object)
    at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
    - locked <0x00000000c01d9420> (a io.netty.channel.nio.SelectedSelectionKeySet)
    - locked <0x00000000c01f1948> (a java.util.Collections$UnmodifiableSet)
    - locked <0x00000000c01d92c0> (a sun.nio.ch.EPollSelectorImpl)
    at sun.nio.ch.SelectorImpl.select(Unknown Source)
    at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:635)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:319)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
    at java.lang.Thread.run(Unknown Source)

高CPU与此有关吗？另一个问题是，当我连接很多客户端时，发现一些客户端会连接，错误如下：

"nioEventLoopGroup-4-1" prio=10 tid=0x00007fef28001800 nid=0x1dbf waiting for monitor entry [0x00007fef9eec7000]
java.lang.Thread.State: BLOCKED (on object monitor)
at sun.nio.ch.EPollSelectorImpl.doSelect(Unknown Source)
- waiting to lock <0x00000000c01f1af8> (a java.lang.Object)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
- locked <0x00000000c01d9420> (a io.netty.channel.nio.SelectedSelectionKeySet)
- locked <0x00000000c01f1948> (a java.util.Collections$UnmodifiableSet)
- locked <0x00000000c01d92c0> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(Unknown Source)
at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:635)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:319)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
at java.lang.Thread.run(Unknown Source)

生成客户端是通过使用线程池完成的，并且已设置连接超时，但为什么频繁的连接超时？是服务于诉讼的事业吗？

    public void run() {

    System.out.println(tnum + " connecting...");
    try {
        Bootstrap bootstrap = new Bootstrap();
        bootstrap.group(group)
        .channel(NioSocketChannel.class)
        .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 30000)
        .handler(loadClientInitializer);

        // Start the connection attempt.
        ChannelFuture future = bootstrap.connect(host, port);
        future.channel().attr(AttrNum).set(tnum);
        future.sync();
        if (future.isSuccess()) {
            System.out.println(tnum + " login success.");
            goSend(tnum, future.channel());
        } else {
            System.out.println(tnum + " login failed.");
        }
    } catch (Exception e) {
        XLog.error(e);
    } finally {

// group.shutdownGracefully（）; }

Answer 1

高CPU与此有关吗？

可能是。我会按照以下方式诊断此问题（在Linux机器上）：

查找正在吃CPU的线程

使用pidstat我会发现哪些线程正在占用CPU以及花费的模式（用户/内核）时间。

$ pidstat -p [java-process-pid] -tu 1 | awk '$9 > 50'

此命令显示占用至少50％CPU时间的线程。您可以使用jstack，VisualVM或Java Flight Recorder检查这些线程正在执行的操作。

如果渴望CPU的线程和BLOCKED线程是相同的，那么CPU的使用似乎会引发争用。

查找连接超时的原因

如果两个操作系统无法在给定时间内完成TCP握手，则基本上会出现连接超时。有几个原因：

网络链接饱和度。可以使用sar -n DEV 1进行诊断，并将rxkB/s和txkB/s列与您的链接最大吞吐量进行比较。
服务器（Netty）在给定的超时时间内没有响应accept()。该线程可以被BLOCKED或饿死CPU时间。您可以使用accept()找到正在调用strace -f -e trace=accept -p [java-pid]的线程（因此完成TCP握手）。然后使用pidstat / jstack。

您还可以使用netstat -an | grep -c SYN_RECV

找到已接收的连接打开请求数（但未确认）

Answer 2

如果您可以详细说明您的Netty正在做什么，它可能会有所帮助。无论如何 - 请确保您关闭频道。来自Channel javadoc：

的通知

完成频道后，调用close（）或close（ChannelPromise）来释放所有资源非常重要。这确保以适当的方式释放所有资源，即文件句柄

如果你正在关闭通道，那么问题可能在于它自身的逻辑 - 运行到无限循环或类似 - 这可能能够解释高CPU。

SelectorImpl是BLOCKED

2 个答案:

查找正在吃CPU的线程

查找连接超时的原因