刚进行完压力测试，发现在如下场景下，业务响应时间很接近，为何？

这个是需要运气的。

是否做上下文切换，取决于进程是不是每次被调用到同一个VP上，VP是不是每次被调用到同一个物理CPU上。

如果你的资源池，资源比较充足，那么hypervisor按照亲和性调度，你的VP每次得到的物理CPU是一样的，所以响应时间不受影响

反之，资源紧张，多个lpar争抢，亲和性大打折扣，响应时间就起伏很大。

亲和性的数值，可以通过下面方式查询

Nmon的BBBP sheet

命令行Mpstat –d

看到各位专家的解释，到现在才来探讨。

那么如果要看运气的话，物理资源多少才算闲置，总利用率多少需要开始关注CPU亲和度了，需要开始着手处理此类问题了。

一方面既想提高整体物理机CPU利用率，一方面又想提高单个虚拟化Lpar的性能，既然如此，考虑亲和度也是必须的工作，那么闲置状态时，可能lpar的性能并不受CPU资源调度的影响，那么物理机的整体CPU利用率究竟达到多少时，需要考虑扩大lpar的EC，才能保证lpar的性能得到保证。

我们其实还是有考虑继续扩大测试，在CPU整体利用率提升的同时，保持VP不变，分别提升EC，看有何效果。

相同压力下不同比例下资源使用情况是什么样的？如果资源充足，在最大压力下是不是还是接近？

针对问题1、 \"那么如果要看运气的话，物理资源多少才算闲置，总利用率多少需要开始关注CPU亲和度了，需要开始着手处理此类问题了\"

首先要理解亲和度的概念，是CPU是否能从cache1、2、3里面读到数据。举个例子，有1000个进程跑在一个CPU上，但都是不怎么干活的进程，一会儿进程A上来占用，一会进程B上来占用，但总体CPU利用率并不高，但每个进程上来后都要有自己的进程上下文。可能此时cache1、2、3根本缓存不了这么多上下文。结果就是大量的上下文切换。

因此不会有一个绝对的指标，说物理资源多少 才开始关注CPU亲和度。

针对问题2、“物理机的整体CPU利用率究竟达到多少时，需要考虑扩大lpar的EC”

是否扩大LPAR的EC，主要考虑的是你的业务需求是否能够得到满足（例如，响应时间是否满足要求，吞吐量是否跟得上），而不是主要考虑物理机的整体CPU利用率。

资源空闲的情况下，CPU的调度几乎可以忽略不计。如想测出不同，可以找只有2C和4C的物理机进行对比测试。

CPU上下文切换，肯定是耗时的，亲和性对于CPU效率的影响，也得足够影响到业务响应时间的，否则power设计也不会在亲和性设计上大做文章了。

hypervisor的调度是就近原则。

从进程调度上来说，如果一个进程运行时，上一个使用cpu仍然空闲，就不会发生上下文切换。如果运行的CPU不在不同的物理CPU之间切换，也就不会产生跨CPU笼子访问内存等影响亲和性的现象聘。

长见识了。