性能分析之 dubbo 性能参数导致单 cpu 高

x33g5p2x  于10个月前 转载在 其他  
字(3.5k)|赞(0)|评价(0)|浏览(86)

背景

今天记录一个小问题。
问题不大,也没什么分析的逻辑可以讲的。但是想着比较典型,所以就写一写。
这一日,一个朋友发来个问题。

一个 Java 应用,从 visualVm 这里看,有 10 个 new I/O worker 线程。具体 top -d -Ph pid 看到只有一个线程在忙。

问题分析

听起来是个问题。一个线程忙,这种情况应该比较好处理吧。
再看一下 CPU 的状态是什么样, 记住这一步是看进程中的线程。这种操作我想看过 7DGroup 公众号上文章的人都已经会了。

然后印下 dump信 息。printf 转换下 pid 到十六进制,查到如下进程:

"New I/O worker #8" #124 daemon prio=5 os_prio=0 tid=0x00007f4c100a2800 nid=0xd232 runnable [0x00007f4ba45c7000]
   java.lang.Thread.State: RUNNABLE
        at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2449)
        at com.alibaba.dubbo.common.serialize.support.hessian.Hessian2ObjectInput.readObject(Hessian2ObjectInput.java:76)
        at com.alibaba.dubbo.rpc.protocol.dubbo.DecodeableRpcResult.decode(DecodeableRpcResult.java:83)
        at com.alibaba.dubbo.rpc.protocol.dubbo.DecodeableRpcResult.decode(DecodeableRpcResult.java:109)
        at com.alibaba.dubbo.rpc.protocol.dubbo.DubboCodec.decodeBody(DubboCodec.java:90)
        at com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:118)
        at com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:79)
        at com.alibaba.dubbo.rpc.protocol.dubbo.DubboCountCodec.decode(DubboCountCodec.java:46)
        at com.alibaba.dubbo.remoting.transport.netty.NettyCodecAdapter$InternalDecoder.messageReceived(NettyCodecAdapter.java:134)
        at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
        at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
        at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
        at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
        at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
        at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
        at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
        at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
        at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
        at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
   Locked ownable synchronizers:
        - <0x00000007500fccf0> (a java.util.concurrent.ThreadPoolExecutor$Worker)

这其实是一个挺明确的问题,如果理解了dubbo 的话。

不止是 dubbo,对其他的应用也是同样的判断逻辑。如果只有一个 CPU 使用率高。

那就三个方向:

  • 单线程;
  • 锁或等待;
  • 等待。

可是现在是什么年代了?还能有单线程的问题吗?嗯,确实是有的,不管年代。

对于 dubbo 这种配置参数如此之繁杂的玩意来说,配置更需要麻烦。之前我整理过 dubbo 和性能相关的参数,有比较直接的关联关系的大概就有四十几个(包括消耗者和生产者)。
在我们的性能分析中,其实有一个环节,至今我看到仍然做的非常差的,就是事先把性能配置参数给梳理一遍。有些问题在梳理的时候就可以看出来了,所以我在工作的时候,在做性能分析之前,都会先干一遍这样的事情。

比如说 Linux 的参数(下图中红色为性能参数,做了标识):

上图只是展示了一部分,全部参数是什么样的呢?

样算一屏的话,大概有三屏的参数。
可以想像,配置那么多,在出现性能问题时怎么分辨?
并且一个参数问题,导致的问题表象都会让你觉得非常不理解。

有时候我们费了几天的劲分析了一个问题,最后发现是一个参数导致的,改一下就性能大涨,会觉得特别不值得,想骂人的感觉有没有?
有的人看着写文章中一个性能问题,觉得到最后改一个IP、改一个参数、改一行代码、改一个SQL,就会觉得性能问题无非就是这样嘛。
但是你想过没有,这个过程中要分析多少数据?做多少实验?要多有耐心?要多需要功底?
感慨的差不多了,说一下上面的问题是什么原因吧,要不然,看官们该想扔手机了!

上面的问题是什么呢就是一个 connections 配置。这个朋友是把 connections 放到代码里的,写成了这样。

referenceConfig.setConnections(1);

因为限制了连接为 1,并且在压测的这个环境中,一个 consumer 一个 provider。这样一来,就完全限制住了吞吐量。
其实是实际的生产 dubbo 环境中,并不完全是这样。当 consumer 和 provider 多的时候,CPU 也可以用得起来。

但是在这个特定的环境中,就完全被限制了。怎么办呢?这时候,就简单了对不对。

referenceConfig.setConnections(10);

这样就可以用起来了。

小结

因为这个问题比较简单,记录下来,就是为了告诉玩性能的人们,你要关心性能配置参数。
应该说,什么都得关心,缺少一个环节,就是知识的盲区。

相关文章