ip_soft_rings_cnt参数与Server的压力测试

【好久没写文章了，都有点觉得自己太懒了。遂记录一则最近做的事情，分享给更多朋友。以后要多写多记录，决定了】

问题：
最近在做关于SUN SPARC平台和X86平台的机器的压力测试，实现方法是先抓取生产数据库在peak time的Top SQL，然后用自己写的java多线程脚本进行给机器施压。
发现，无论开多少个Client，都无法将SPARC T系的一款机器压到100% CPU使用率，只能压到30%。而X86平台就没这个问题。
这带来了一个问题是：如果这台机器只能被压到30%，那么我们就不应该设定它的threshold就为它100% CPU了。

分析：
那么究竟是什么造成了CPU无法完全被使用？原因肯定是有其他资源率先成为了瓶颈。
那么IO和NETWORK就成了最先考虑的目标。
首先检查IO，平均响应时间并没有增长到无法接受的地步。
NETWOK呢?在上压力时，大部分等待事件是“SQL*Net message from client”。

我们首先分别在两块网卡的不同ip上，启动两个listener，将压力均摊到两个网卡上，这时，我们就可以将压力压到50% CPU以上了。
这更加说明了瓶颈是出在了网络上。

由于在这个环境中的SQL都是非常轻量级的PK查询，package非常小，会不会是因为package太小太多导致网络堵塞？

结论：
我们根据
http://www.solarisinternals.com/wiki/index.php/Networks#For_10GbE_throughput
的建议，对solaris的一些相关网络参数进行的调整，其中就包括：
“
CMT specific
T5440/T5240/T5140/T5220/T5120/T2000/T1000
For S10U7 or earlier /etc/system
set ip:ip_soft_rings_cnt=16
”

惊奇的发现，经过网络调整之后，可以很轻松地将机器压力调整到100% CPU。
然后我们采用单一变量法，隔离开无关参数，最终定位到了ip_soft_rings_cnt。

知识：
那么为什么设定ip_soft_rings_cnt=16(以前是默认是2)之后，就解决问题了呢？
于是查询相关文档，搜到一篇不错的文章，建议大家精读：
http://blogs.sun.com/krgopi/entry/crossbow_soft_rings


于是整个故事是这样的：
简而言之，ip_soft_rings_cnt控制了有多少个work threads来处理我们incoming package。
由于我们大量的SQL命令发送到网卡上，造成了incoming package的堵塞。
当我们设定ip_soft_rings_cnt=16之后，将有16个CPU threads来处理他们。

在资源守恒定理的想象下，这其实是拿CPU使用率换来了更高的网络进口的吞吐量。
由于机器是有128个CPU threads，原先有2/128的CPU在处理，现在有16/128的CPU在处理。

所以，虽然以前我们压不上机器的CPU使用率，但是由CPU/TPS线性估算出来的peak TPS是更高的。
现在，估算出来的peak TPS稍低一点。
这很显然，因为现在有差不多10%+的CPU在做处理incoming package的事情了。所以，Oracle能使用的peak CPU也下降了10%。

结尾：
当你看到你的机器CPU负载常年在20%浮动的时候，是否会感到十分轻松，觉得机器瓶颈还早着呢？
建议你用当前的Top SQL压力测试一把，或许某个资源在CPU之前率先达到瓶颈，例如网络。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15415488/viewspace-671868/，如需转载，请注明出处，否则将追究法律责任。