【软件测试】性能分析之dubbo性能参数导致单cpu高
今天记录一个小问题。
问题不大，也没什么分析的逻辑可以讲的。但是想着比较典型，所以就写一写。
某年某月的某一天，就像一张破碎的脸 ...... 不对，串台了。
这一日，一个朋友发来个问题。
听起来是个问题。一个线程忙，这种情况应该比较好处理吧。
再看一下CPU的状态是什么样， 记住这一步是看进程中的线程。这种操作我想看过7DGroup公众号上文章的人都已经会了。
然后印下dump信息。printf转换下pid到十六进制，查到如下进程：
这其实是一个挺明确的问题，如果理解了dubbo的话。
不止是dubbo，对其他的应用也是同样的判断逻辑。如果只有一个CPU使用率高。那就三个方向：1. 单线程；2.锁或等待；3.等待。
可是现在是什么年代了？还能有单线程的问题吗？嗯，确实是有的，不管年代。
对于dubbo这种配置参数如此之繁杂的玩意来说，配置更需要麻烦。之前我整理过dubbo和性能相关的参数，有比较直接的关联关系的大概就有四十几个（包括消耗者和生产者）。
在我们的性能分析中，其实有一个环节，至今我看到仍然做的非常差的，就是事先把性能配置参数给梳理一遍。有些问题在梳理的时候就可以看出来了，所以我在工作的时候，在做性能分析之前，都会先干一遍这样的事情。
比如说linux的参数（下图中红色为性能参数，做了标识）：
上图只是展示了一部分，全部参数是什么样的呢？
这样算一屏的话，大概有三屏的参数。
可以想像，配置那么多，在出现性能问题时怎么分辨？
并且一个参数问题，导致的问题表象都会让你觉得非常不理解。
有时候我们费了几天的劲分析了一个问题，最后发现是一个参数导致的，改一下就性能大涨，会觉得特别不值得，想骂人的感觉有没有?
有的人看着写文章中一个性能问题，觉得到最后改一个IP、改一个参数、改一行代码、改一个SQL，就会觉得性能问题无非就是这样嘛。
但是你想过没有，这个过程中要分析多少数据？做多少实验？要多有耐心？要多需要功底？
感慨的差不多了，说一下上面的问题是什么原因吧，要不然，看官们该想扔手机了！
上面的问题是什么呢就是一个connections配置。这个朋友是把connections放到代码里的，写成了这样。
因为限制了连接为1，并且在压测的这个环境中，一个consumer一个provider。这样一来，就完全限制住了吞吐量。
其实是实际的生产dubbo环境中，并不完全是这样。当consumer和provider多的时候，CPU也可以用得起来。但是在这个特定的环境中，就完全被限制了。怎么办呢？这时候，就简单了对不对。
这样就可以用起来了。
因为这个问题比较简单，记录下来，就是为了告诉玩性能的人们，你要关心性能配置参数。
应该说，什么都得关心，缺少一个环节，就是知识的盲区。
以上是 【软件测试】性能分析之dubbo性能参数导致单cpu高 的全部内容， 来源链接： utcz.com/a/132018.html
