案例：相同的场景再跑一遍CPU利用率变了

理论联系实际，解释CPU利用率统计原理、CPU调度原理，内存与CPU亲和性原理

问题描述
测试某服务器上的某交易的性能表现，在TPS（=40）相同的情况下，两次测试的交易响应时间有较大差异，CPU利用率竟然也不一样。

场景1：响应时间长（132.46ms），CPU利用率高，
场景2：响应时间短（105.29ms），CPU利用率低。

场景1，CPU 29%
看起来很标准的图形

场景2：CPU 26%
看起来也很标准

谁占用了CPU
接下来，我们分析谁占用了CPU，是不是有其他进程的干扰。
两个场景均仅有一个进程名占CPU高，即应用本身的进程，并没有别的进程干扰，那么接下来只能看运行环境了。

两场景的CPU配置
CPU设置一直未变

两个场景的进程与CPU亲和性
场景1的进程与CPU亲和性

进程调度到同一个逻辑CPU的比率是98.2%，进程与CPU的亲和性非常好。

场景2的进程与CPU亲和性

进程调度到同一个逻辑CPU的比率是98.2%，甚至还不如场景1，为什么CPU利用率会变低呢？

CPU与内存亲和性两个场景不一样
场景1：

场景1的资源分布在4个抽屉里，并且，其中一个抽屉中的内存没有对应的CPU，需要跨抽屉才能用到CPU。

场景2

场景2的所有资源均在同一个抽屉里，亲和性非常好。

原因
那么为什么两个场景的内存、CPU资源的分布不一样呢？ 一定是LPAR、甚至物理机重启过。按照亲和性较优的情况重新布局过资源。经问询，该LPAR以及物理机的确重启过。

资源亲和性不好的时候为什么响应时间长并且CPU利用率高呢？

首先，CPU利用率和应用的执行时间是成正比的。CPU利用率越高，说明应用执行时间越长。
CPU利用率统计其实就是采用CPU硬件当中的采样，比如100个CPU时间片中，实际用了多少时间片。因此，如果应用执行时间长，用到的时间片多，自然CPU利用率就高。

第二，亲和性不好的时候，进程上CPU执行任务时，需要花更多的时间来从内存向CPU Cache调取数据。场景1中CPU和内存离得很远，离得远就调的慢。尽管场景1中进程和CPU的亲和性很好（即同一个进程几乎每次都调度到同一个CPU上），但即使调度到同一个CPU上又如何？你的内存离着CPU十万八千里，这个调度仍然是低效的。

CPU的时间片最大可用长度是固定的（比如10ms），如果10ms执行不完，这个进程就要下去，等下一次CPU时间片的机会。
在每个时间片中，切换的时间长了，真正执行的时间就短了。那就需要更多的时间片去完成任务，从CPU利用率的统计原理可知，CPU利用率会变高。

这就解释了为什么亲和性不好的那个场景交易响应时间不但长，并且CPU利用率也变高了。

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