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

今天记录一个小问题。

问题不大，也没什么分析的逻辑可以讲的。但是想着比较典型，所以就写一写。

某年某月的某一天，就像一张破碎的脸 ...... 不对，串台了。

这一日，一个朋友发来个问题。

听起来是个问题。一个线程忙，这种情况应该比较好处理吧。

再看一下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使用率高。那就三个方向：1. 单线程；2.锁或等待；3.等待。

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

对于dubbo这种配置参数如此之繁杂的玩意来说，配置更需要麻烦。之前我整理过dubbo和性能相关的参数，有比较直接的关联关系的大概就有四十几个（包括消耗者和生产者）。

在我们的性能分析中，其实有一个环节，至今我看到仍然做的非常差的，就是事先把性能配置参数给梳理一遍。有些问题在梳理的时候就可以看出来了，所以我在工作的时候，在做性能分析之前，都会先干一遍这样的事情。

比如说linux的参数（下图中红色为性能参数，做了标识）：

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

这样算一屏的话，大概有三屏的参数。

可以想像，配置那么多，在出现性能问题时怎么分辨？

并且一个参数问题，导致的问题表象都会让你觉得非常不理解。

有时候我们费了几天的劲分析了一个问题，最后发现是一个参数导致的，改一下就性能大涨，会觉得特别不值得，想骂人的感觉有没有?

有的人看着写文章中一个性能问题，觉得到最后改一个IP、改一个参数、改一行代码、改一个SQL，就会觉得性能问题无非就是这样嘛。

但是你想过没有，这个过程中要分析多少数据？做多少实验？要多有耐心？要多需要功底？

感慨的差不多了，说一下上面的问题是什么原因吧，要不然，看官们该想扔手机了！

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

referenceConfig.setConnections(1);

因为限制了连接为1，并且在压测的这个环境中，一个consumer一个provider。这样一来，就完全限制住了吞吐量。

其实是实际的生产dubbo环境中，并不完全是这样。当consumer和provider多的时候，CPU也可以用得起来。但是在这个特定的环境中，就完全被限制了。怎么办呢？这时候，就简单了对不对。

referenceConfig.setConnections(10);

这样就可以用起来了。

因为这个问题比较简单，记录下来，就是为了告诉玩性能的人们，你要关心性能配置参数。

应该说，什么都得关心，缺少一个环节，就是知识的盲区。