本文转载自公众号“白鳝的洞穴”

经历过小型机时代的运维人员都有一个感觉，好像是小型机上的CPU更经用一些，特别是IBM的小型机。哪怕是CPU使用率达到100%，系统好像还不感觉太慢。而在LINUX上就不同了，CPU使用率高了确实系统就立马变慢了，甚至不用达到100%，系统就慢的可以了。记得十多年前，一个客户为了图便宜，买了一批P5 的P595，系统刚上线，很快CPU使用率就100%了，虽然系统并没感觉慢，不过网管系统整天发告警也是受不了。于是我建议他们不再关注CPU使用率，而是关注r队列的长度，如果r队列的长度达到CPU核数的3倍，才开始报警，当r队列长度超过CPU核数的4倍的时候，系统才开始感觉有些慢。

另外一个案例是一个Oracle数据看用户把自己的P5 570服务器更换为P7 750之后，当开启了SMT4后，从AWR上看到差不多相同负载下的CPU TIME和SQL消耗的CPU time都?突然变大了。当时老白和这个用户分析了好久，在最后在国外的一个BBS上找到了?答案。Karl Arao一篇文章中的关于SMT4的采测启发了我，最终?发现了这个问题，今天?老白把这个发现分享给大家。

实际上现在的CPU都是并行多线程结构的，无论IBM的POWER还是INTEL的至强。多线程结构下一颗CPU中可以通过流水线的方式并发接受多个任务，不过虽然CPU支持多条流水线，实际上其计算单元还是一个，所有的流水线都要共享一个计算单元。多线程架构（比如IBM的SMT）只是增加了一些寄存器，比如IBM的PURR和SPURR寄存器，因此双线程的处理能力并不能等同于2倍，SMT8也并不等同于8倍。通过POWER 8的SMT数据来看：

以单线程为基准，双线程的时候，处理能力大约是1.5倍，四线程接近2倍，8线程是2.2倍。大家可能吓了一跳吧，我们在ORACLE数据库中看到的CPU_COUNT是线程数，对于一个POWER8的系统，4路32核的服务器，我们在ORACLE中看到的是CPU_COUNT是256。而实际上，这个服务器的实际处理能力仅仅是不开SMT的2.2倍，也就是相当于70个核的水平。

早期，AIX统计CPU使用率采用的是传统UNIX的方法，就是占用CPU线程的时间长度来进行统计。比如一个开启了SMT4的服务器上，如果有4颗CPU，如果有4个任务使用CPU，那么占用CPU的时长是1/4，CPU使用率应该被统计为25%，而实际上，IBM从并不是按照任务占用CPU线程的时间来统计使用率的，而是按照占用PURR/SPURR寄存器的情况来统计CPU使用率的。因此，在这个场景中，我们看到的CPU使用率不是25%，而是67%，这和SMT4接近于2倍的SMT1的事实差不太多。IBM曾经做过一个测试，对于一个80并发的网络访问，在同样的硬件环境下，AIX 7.0系统上反馈回来的CPU使用率是23%，而POWER LINUX反馈的CPU使用率是9%。因为AIX使用了PURR占用率来计算CPU使用率，LINUX使用getrusage统计的CPU使用率是基于线程占用CPU的时长进行计算的。

这个问题在我们的X86环境下的LINUX上仍然存在，我们的CPU使用率是按照超线程条件下的CPU占用CPU线程的时间比例来计算CPU使用率的。在超线程下，逻辑CPU的数量是物理CPU的2倍，而实际上，超线程提供的真实的处理能力约为1.2倍。

这意味着什么呢？也就是说我们在LINUX环境下，CPU使用率被远远低估了，真实的CPU资源的使用率是我们看到的CPU USAGE的1.67倍。

那么在AIX上，是不是就真的能准确的反馈出CPU资源的使用情况呢？实际上并不是的。在并发运行的线程数较少的时候，比如单线程占用CPU的时候，CPU使用率的反馈还是十分准确的。当多个线程占用一个物理CPU的时候，CPU使用率的背离就会加大。比如一个SMT4的CPU，当一个线程运行时，CPU使用率为65%，当两个线程运行于这个物理CPU时，CPU使用率不会反馈为100%（预期的推算是130%），而是90%，4线程占满时，每个线程被评估为25%，这颗CPU的使用率是100%，而实际上SMT4的真实处理能力是2倍，也就是此时CPU使用率倍高估了1倍。

从上述数据看，无论是AIX系统还是LINUX系统，把CPU使用率阈值定为90%是同样存在风险的。LINUX上如果CPU使用率长期高于60%，那么持续一段时间后，CPU就会出现耗尽的可能性。幸运的是，我们的CPU使用率总是在波动的，并不长期处于高位运行。互联网公司的CPU日均使用率在30-40%之间，而我们的企业往往就更低了。最为极端的观点认为在LINUX监控中的CPU使用率阈值应该设置为60%。老白觉得，我们也不需要如此谨慎，只有CPU持续处于如此高位运行的时候，才是存在风险的，否则的话也没必要把阈值设的如此之低。

把CPU告警阈值设置的过低会经常出现不必要的预警，因为CPU使用率高峰往往不会持久，偶尔的CPU使用率过高并不会对我们的系统运行性能造成影响（既然花钱买了这么多CPU，那么不用是最浪费的），只有长时间持续的?CPU使用率高峰才会对运行性能造成影响。在观察CPU使用率的时候，同时观察r队列的长度，可以较为准确的?掌握CPU资源是否存在瓶颈。下面我们在一台INTEL E8的服务器上做一个实验，这台服务器有两颗18核的CPU，在Oracle能够看?到的CPU_COUNT是72。

首先我们在没有任何负载的情况下来看看ps命令的执行情况：

可以看出执行时间是0.02秒，其中在SYS上花费了0.02秒，USER上没有消耗时间。当对系统进行加压，但是还没有达到物理内核数的时候，执行情况差异不大：

大家可以看到real是0.03，USER还是0，SYS还是0.02,这个real似乎增加了一秒，实际上可能差异并没有这么大，因为存在四舍五入的问题。当负载让r队列未超过物理CPU的核数的时候，运行效率还是差不多的。如果当R队列超过系统的CPU线程数后会出现什么情况呢？

当前的CPU线程数是72，当r队列超过72后，执行时间居然高达0.09秒，sys的时间也翻了一倍。

最后我们来看看r队列超过物理核数，但是未达到线程数的情况：

SYS的CPU时间比r队列未超过CPU物理核数时候略大一些。虽然CPU使用率只有75左右，但是实际上运行性能已经受到了明显的影响了。上面的所有实验和我们前面对超线程架构的CPU的分析是完全吻合的。

最后我们总结一下今天的分析结论，首先在超线程或者SMT下的CPU使用率指标可能存在误导性，甚至可能导致AWR中的CPU time相关的指标不准确。其次是R队列对于我们判断CPU资源是否存在瓶颈具有很好的指导意义。在进行CPU资源监控的时候，CPU资源的告警可以考虑r队列超过CPU线程数后进行告警。当然大部分应用对于CPU资源排队并不十分敏感，我们也不必要太过于纠结CPU资源的瓶颈。哪怕出现了CPU资源瓶颈，如果系统运行的性能还不算太差，我们也是可以忍受的。互联网公司把CPU使用率的日平均值指标定位30-40%，是十分合理的，既保证了资源的效率，又不会对核心业务运行带来太大的风险。