本章介绍如何在非虚拟化环境以及虚拟化环境下准确的读取CPU利用率指标，同时介绍CPU利用率的细分User%、Sys%、Wait%、Idle%各自的含义，以及如何利用它们协助分析性能问题。

总利用率

CPU利用率=用户态CPU%+系统态CPU%

1.获取来源

（1）Dedicated模式
Nmon CPU_ALL Sheet：CPU%
命令行topas：usr%+sys%
（2）Sharing模式
若physical CPU没有超过EC，则采集EC利用率
当Physical CPU<=EC时，EC利用率=（EC_User% + EC_Sys%）/EC值。
Nmon CPU_ALL Sheet：CPU%
或Nmon LPAR Sheet：EC_User% + EC_Sys%

若physical CPU超过EC：
此时若按照EC利用率统计，则CPU利用率很可能超过了100%，出具的测试结果、测试报告容易造成误解。
此时若按照physical CPU利用率（使用的CPU/physical CPU）统计，分母physical CPU是动态的，因此利用率不具有参考价值。
如果一定要统计CPU利用率，可按照VP利用率统计，VP利用率= VP_User% + VP_Sys%。但需要假设CPU物理Core的个数为VP个数。举例说明：
假设EC=2，VP=8，EC利用率为200%，VP利用率为50%。在测试报告中描述CPU利用率为50%（CPU为8核，其中EC为2C，借用为借用资源池）。

2.最佳实践

交易类测试通常在CPU利用率在70%左右，出具系统能够支撑的最大吞吐量的性能指标。不宜在CPU过高的情况给出性能数据，生产环境CPU 70%会产生CPU报警。并且，CPU过满的情况下，各类性能数据会产生变形。不宜在CPU过低的情况给出性能数据，CPU过低的情况下，操作系统和系统软件本身对CPU的消耗占比比较大，若此时统计均摊到每笔业务上的CPU消耗，不太准确。

对于交易类应用，CPU利用率与业务压力（吞吐量）应成近似线性的比例关系。若CPU利用率不能随着吞吐量的增加而增加（如：CPU利用率不能达到70%，最多只能达到30%），需从应用、系统软件、虚拟化配置等方面进行调优。例如：1）应用并发线程数量是否过少，2）消息中间件的队列管理器数量过少、传输通道过少、本地队列过少，3）虚拟化参数配置中若VP与EC的比值越大，Hypervisor层面的系统调度开销越大，操作系统获得的CPU时间片越少，CPU利用率无法随着吞吐量的增长而增长，响应时间也会延长。

3.CPU利用率观察取值方法举例

在压力测试过程中随时通过topas命令可以查看CPU的利用率，若没有达到预期的利用率，说明这次测试的压力（吞吐量）没有达到预期，需要马上分析原因，必要时停止测试，以避免无谓的时间浪费。

同时也可以观察Physical CPU是否已经超过EC。若超过了，说明当前分配的EC值过低，此时可考虑联系系统管理员分配更大的EC，以保证能够出具可靠的性能数据（借用资源池的CPU，没有EC保障下的CPU性能好）。

Entc指的是Physical CPU除以EC的比值。如上图，Entc=199.7%，即此时获得的Physical CPU是EC的约2倍。而此时Physical CPU的值为Physc=1.00，因此可以直接推测EC=0.5。

Topas中的user%和kern%与“Nmon CPU_ALL Sheet“中的user%、sys%类似，它们的和不会超过100%。因此读数时要注意实际获得了多少Physical CPU。

下面场景中，CPU参数设置如下

Entitled Capacity（EC）=0.8，VP=2，capped=0。

红色的线是EC能力。蓝色的线是运行时获得的physical CPU的个数，相当于获得CPU core的个数。

我们发现，蓝色的线已经跑到了红线上方。说明运行时获得的physical CPU超过了标称能力，向CPU资源池进行了借用。

此时CPU_ALL的界面中显示的CPU总利用率如图

取某个时间点的CPU_ALL sheet中的CPU数据，15:25:19这个时刻，CPU利用率为60.7%

取LPAR sheet中的CPU数据（隐去不必要的数据）

按理说CPU利用率=User%+Sys%。但60.7%这个数，即不等于EC_User%+EC_Sys%，也不等于VP_User%+VP_Sys%。

因为此时physical CPU>EC, 因此CPU_ALL中显示的CPU%=使用的CPU/Physical CPU。
以上述数据为例

以EC计算：EC=0.8，EC_User%+EC_Sys% = 87.97%，LPAR相当于使用了0.8 x 0.8797 = 0.70376 个CPU Core

以VP计算：VP=2，VP_User%+VP_Sys%=35.19%，LPAR相当于使用了2 x 0.3519 = 0.7038个CPU Core

以Physical CPU计算：Physical CPU=1.161，CPU%=60.7%，LPAR相当于使用了1.161 x 0.607= 0.704727个CPU Core

三种算法得到相同的结果，说明没有哪个数据是错误的，但由于Physical CPU是波动的，因此CPU_ALL中的CPU%的分母是波动的，此时CPU_ALL sheet中的CPU%不具有统计价值。

Physical CPU>EC的场景，可以采用VP利用率来充当CPU利用率。测试报告中可以描述为CPU利用率35.19%（CPU为2核，其中EC为0.8C，借用资源池1.2C）。

User%

CPU总利用率由用户态CPU利用率和系统态CPU利用率组成。

1.获取来源

Nmon CPU_ALL Sheet：user%
命令行topas：user%

2.最佳实践

对于应用软件在压力测试状态下通常用户态的CPU占比比较高，而系统态占比比较低。用户态可以保护底层硬件资源不直接被程序访问，减少系统crash，所以一般的应用程序跑在用户态的CPU占比大。

Sys%

1.获取来源

Nmon CPU_ALL Sheet：sys%
命令行topas：kern%

2.最佳实践

如果系统态占比比较大，一般有以下几类原因：
（1）为了追求效率，减少用户态到系统态的转换，把用户态的function改到系统态，例如：一些驱动程序，以显卡驱动最为常见
（2）系统有IO问题
（3）应用设计问题

3.举例

通常情况，压力测试下，用户态（蓝色）和系统态（红色）的CPU图形如下：

系统态偏高如下

这种情况下，如何查看是什么进程、什么库文件、什么函数占用的系统态CPU，后续章节专题介绍。

Wait%

Wait%在不同的场景下含义不同。在CPU的4个细分类型中，Wait%是指CPU等待IO的时间占总时间的百分比。如果在CPU sys态（或kernel态）中的wait%则与此处的wait%含义不同。

1.获取来源

获取来源与Usr%类似。

2.最佳实践

Wait%虽然不会统计进CPU总利用率，但仍然是系统CPU性能指标中偶尔关注的指标。
之所以wait%不会统计进CPU总利用率，因为wait%和idle%比较类似，都是CPU闲置状态，只不过一个是等IO，一个是等新的任务。

但如果wait%过大，说明CPU等IO的时间长，系统的处理效率可能比较差。但有时wait%偏高也不构成性能问题，例如，当系统任务较少时，CPU处理一个任务，处理过程中需要等IO，此时就体现在wait%上面；当继续增加压力，CPU接收到新的任务，CPU就不会干等下去，而是去忙着处理别的任务，此时wait%就被压缩了。

Idle%

CPU闲置状态即为idle%。
有人把Idle理解为CPU没有任务时的一个占位进程把CPU占满，这个理解是错误的。在这个进程里出现的CPU占用数值并不是真正的占用而是指CPU的空闲率

Idle%越大CPU的耗电越少，BTW，一台计算机的功耗不是恒定的，影响功耗的因素较多，但最主要的因素是CPU闲置还是运行，但尽管如此，Power服务器CPU闲置时仅比跑满状态省电10%左右，后续可以开个章节专门介绍如何测试功耗。

1.获取来源

获取来源与Usr%类似。

专栏其他链接
性能指标之资源指标 CPU配置参数对性能的影响
性能指标之资源指标 CPU亲和性原理介绍及如何量化读数
性能指标之资源指标 CPU亲和性调整优化
性能指标之资源指标 如何精确计算每笔交易消耗的CPU

微信公众号：性能测试与调优