性能分析之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);

这样就可以用起来了。

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

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

原文发布于微信公众号 - V社 北京社(SoftwareTesters)

原文发表时间:2019-07-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券