大家可能还记得，AWS提供至少两种控制指标：ECU(即EC2计算单元)与vCPU(意为虚拟中央处理单元)。而在为本篇文章收集素材 时，我在AWS的官方页面当中找到一些资料，其指出vCPU概念已经取代了ECU。我个人对此并不理解，因为二者都有着明确且有力的存在理由。经过检查， 我发现AWS也确实对这种结论做出过反驳，即认为两项指标都应当得到重视。事实上，大家可能在实际使用中发现自己确实需要ECU或者其它一些以容量为基础 之指标来在“处理器”数量之外对系统进行进一步控制。具体来讲，ECU控制着——或者是在用户的管理下控制着——计算容量的使用情况。

为了进一步讨论CPU虚拟化在云环境下的实际影响，我们将立足于一套给定的完整SMP系统，且其中包含了系统所能承载的最大限度容量。对于某些特定 工作负载而言，大家可以尽可能从SMP的处理器当中压榨计算资源，从而获取最为可观的吞吐能力。如果大家在同一SMP当中安装多个操作系统实例，而后在其 上运行同样的工作负载，则会发现其整体吞吐量几乎不可能超过此前达到过的上限。而这正是AWS所提出的多工作负载混合概念，或者称其为ECU;当然，其它 云服务厂商也采取了类似的概念。无论我们采用何种SMP系统进行云环境构建，该系统都会存在着最大容量上限。

因此，大家从云中租用多少容量并添加到一个操作系统实例当中——举例为说，以AWS ECU的形式——其永远不能超过这一最大上限。尽管我们并不清楚AWS设定的最大容量上限是什么，但在PowerVM当中用户确实无法让所有活动操作负载 总和超出这一上限。大家需要根据要求/需要为每套操作系统分配一定资源配额，而PowerVM则负责满足/确保达成预期效果。在某种程度上 讲，PowerVM了解其能够为每个操作系统实例分配多少资源，因为我们的操作系统容量需求属于已知量;各部分容量的总和只会等于或者小于整体容量。

云服务供应商的任务在于获取客户提供的参数，并找出——至少会在一段时间之后找到——这些资源的可用位置。当然，仅达到这一目标还远远不够。在分配 完成后，是否有某些因素阻止某个操作系统实例获取全部SMP容量?为了避免这种情况的出现，或者说确保每个实例都能得到自己必需的容量配额，我们可能需要 硬性要求vCPU进行短暂的运行中止。这种状况在其它场景下亦会出现，如果其它实例已经达到了自身容量消耗配额上限，则各操作系统实例会暂时中止以进行配 额调整。这样处理的目的在于确保所有vCPU都能够公平地分配到可用硬件容量。

在这方面，PowerVM采取了一种有趣的衍生处理方式，即封顶与不封顶容量分配，我猜测其它云服务供应商也选择了类似的手段。封顶容量限定操作系 统实例的容量消耗水平不可高于用户所租用容量之上限。举例来说，假设大家使用两个VP并总计为其分配了1.25个计算核心的容量限额。如此一来，我们的应 用程序就只能同时将自身线程分配给这两个VP。然而假如在某些特定时间段内，二者的容量使用量总和超过了这1.25个核心，那么虚拟机管理程序会中止它们 的运行。举例来说，如果其中一个VP始终保持运行，而另一个VP则只有四分之一时间运行，那么我们此前设定的容量上限将永远不会被突破，而应用程序则能够 始终保持正常执行。总体来讲，在这种封顶模式当中，大家可以充分发挥限额之内的容量，直到下一个时间片段开始。

而对于不封顶容量模式，计算消耗量仍然会被正确计量，但会在实例达到容量上限时提出新的问题：是否还有其它操作系统VP需要这部分额外可用容量?如 果没有，即没有其它操作系统VP处于资源等待状态，那么我们的VP将在超出限额后继续运行。但如果存在等待VP或者有需要使用容量的新VP出现，那么新的 VP会接管对应的容量，而原先的VP则需要停止执行。在这种情况下，当等待VP快速完成了自己的执行任务，那么正处于等待/可调度状态的VP则能够继续此 前尚未完成的执行工作，并仍以超出容量上限的方式保持运行。

听起来不错，对吧?在我们列举的例子当中，这可能意味着大家应当优先选择不封顶模式，即2个VP与1.25核心容量的PowerVM操作系统实例能 够在占用2个核心的情况下继续保持运行。在这种情况下，其实际吞吐量为2个完整计算核心，而非预设的1.25个。不错，效果很好——但前提是我们的SMP 系统在资源使用量方面始终较低，只有这样各vCPU才能保持顺畅执行。在这种情况下，大家会习惯了利用2个完整的计算核心——而非1.25个——执行既定 任务。但随着时间推移，某些对资源索求无度的操作系统可能进入我们的同一套SMP系统，并始终处于忙碌状态。这意味着系统当中不再存在可用的闲置容量;容 量重新被限定回了1.25核心，而吞吐量的实际速度表现甚至会比我们的预期水平更低。需要注意的是，这并不属于真正的性能问题，而仅仅属于不当预期管理引 发的冲突。另外，这种方式也不至于损害性能，其它操作系统实例仍然能够如预期般正常运作。

缓存的存在令我们难以准确衡量容量上限

到这里，我们已经了解到了任意单独SMP中都存在着最大可用容量上限。大家也许会争辩称，自己拥有多种方式来衡量这一容量上限——但是实际情况是， 大部分衡量手段会将驻留在处理器缓存中接受访问的大部分数据算入容量水平。由于缓存访问在速度上要远高于DRAM，因此缓存的介入有可能让我们的最大容量 上限评估结果与实际情况相去甚远。如果不考虑缓存机制，那么最大容量上限可能要低得多。另外，如果缓存内的数据与实际访问对象的交集较为有限，那么最大容 量也会受到严重影响。而正是由于这种状况的存在，我们才需要在后文中详加叙述。

大家肯定还记得，我们的操作系统需要与其它一些同类实例共享SMP系统的容量，而且我们所能使用的容量只是SMP系统容量总和的一部分。之所以要使 用处理器虚拟化机制，就是要确保不同实例得以对SMP系统的整体容量加以共享。而只要这种共享效果“还不错”，那么操作系统及其它实例的执行性能就会令人 满意;它们共享的正是测量所得出的容量上限。因此，让我们换个思路，从最糟糕的角度审视这个问题。

在进行讨论之前，让我们首先明确一个相关概念。我们假设能够分配给每个操作系统实例的容量之总和低于SMP系统当中所存在的全部可用容量。我们还需 要强调一点，每个操作系统实例都能够使用一定数量的VP。虽然整体容量已经限定，但并不代表着各活动操作系统中的VP容量总量需要与物理处理器计算核心数 量(或者SMT线程数量)相对等。这意味着VP数量可以进行超额分配，亦有可能超过处理器的实际数量。事实上，有时候我们会倾向于选择这种方式;在中低水 平CPU利用率条件下，更多VP能够保证我们的操作系统拥有更理想的响应时间表现;而并行执行——而非单一VP中的队列执行——机制也能够更快地完成某些 特定任务。

不过这同时也意味着较高的容量使用率，其中活动VP数量要远高于能够分配给它们的物理处理器数量。更直白地解释，为了确保容量能够得到恰当使用，虚 拟机管理程序需要划分出时间片段，从而确保物理处理器能够为更多VP实际使用。举例来说，我们假定系统中存在32个物理处理器以及256个活动VP。这种 设计方式其实非常合理，一套系统资源由数百个操作系统实例共享的机制可谓随处可见。为确保容量的公平分配，虚拟机管理程序必须在32个处理器上为256个 VP设定角色，同时尽可能快地完成这一任务以保证用户在直观感受上认为这些VP是在同时执行。

现在我们再说回缓存。当某个任务开始在某个计算核心上执行，该任务的数据状态并不会驻留在缓存当中。系统需要经过一段时间的运行才会确认这一状况， 并将其从DRAM或者其它缓存中提取到主缓存内。虽然一般来讲缓存中的驻留数据会在相关任务完成的一段时间之后被释放，但对于某些始终在计算核心上执行的 任务，其状态数据倾向于长期驻留在缓存内以接受重复使用。运气好的话，这项任务会长久占用计算核心，而性能也将在缓存驻留数据(及指令)状态的帮助下显著 提高;毕竟缓存的存在意义就是为了实现常用数据的快速访问。

甚至在虚拟环境当中，一项任务仍然能够长时间驻留在处理器缓存之内，从而保证其执行状态始终受到缓存机制的加持。在保持缓存状态的同时，其最终吞吐 量也会因此显著提高。这一点在低利用率及不封顶运行模式当中犹为明显。如果对处理器及其缓存资源的竞争并不激烈，那么该任务的缓存状态将长久保持在稳定水 平。

不过现在让我们添加额外工作负载(以及更多VP)，从而提高虚拟化SMP的资源利用率。在这种情况下，我们可能会发现活动VP数量所带来的超额容量 需求不断增长，而任务状态——也就是在VP被分配给指定处理器时，状态数据进入缓存所需的时间——亦会在虚拟机管理程序在处理器上进行VP切换时被刷新， 这意味着其它VP数据会取而代之。当我们的任务VP不断在处理器之间进行切换时，其运行所处的处理器必然同时发生改变。如此一来，要想让VP恢复执行，那 么状态数据进入缓存的时间将因此而大幅延长。

想象一下，这种状况在每一次VP交换时都会发生。这意味着前面提到过的缓存准确率开始下降，能够完成的任务不断减少，进而导致吞吐总量严重缩水。任 务的完成流程需要消耗更多时间，且长时间驻留在自己的VP当中而非被完成并释放，而在此期间我们也将无法获得能够接受的合理响应时间。

云服务供应商很清楚这些问题

大家需要了解这些会对处理器虚拟机机制产生影响的因素。不过我们几乎可以肯定，云服务供应商们比我们自己更了解这些问题——或者说应该是更了解这些问题。对他们来讲，对自家系统进行妥善管理显然非常重要，而且之前提到的还仅仅其中的一部分相关因素而已。

我们也几乎可以肯定，云服务供应商能够在其整体环境当中部署更多容量以满足客户对性能的实际需求——甚至有能力在全部操作系统实例皆处于忙碌状态时 仍然实现这一目标。他们自己的系统会在容量需求量增长或者出现不可避免的故障时进行主动待机。其中一部分系统甚至会自动关机，以确保在非必要的情况下尽可 能节约能源消耗。

云服务供应商还具备将各类操作系统实例在不同SMP系统之间进行迁移的能力。当某套系统的资源利用率提升到高危层级时，他们可能会决定将用户的操作 系统实例转移到其它负载较低的系统当中。反之亦然;如果存在大量被分布在多套低资源利用率系统当中，那么他们会倾向于将这些操作系统加以收集以减少系统占 用数量——这至少能够有效降低系统运行所带来的整体能耗水平。而这种对操作系统实例的迁移能力以及了解该在何时进行系统关闭与合并，则代表着云服务供应商 一直在对自身环境进行密切监控。正如我们之前所提到，这些供应商会将负载均衡工作当成科学事务来看待，而这种严谨的态度也能够为其带来切实可见的经济回 报。

不过正如大部分企业一样，提高客户与潜在新客户满意度水平也能够带来良好的经济回报。换言之，对容量波动水平进行严格监控以提供稳定且合理的性能水 平不仅有益于客户，同时也有益于云服务供应商自身。因此，虽然从某种角度讲云服务供应商能够通过将尽可能多的操作系统实例塞进少数活动SMP系统来获得最 大程度的经济回报，但他们很清楚这种杀鸡取卵的作法会通过低下的性能水平导致客户满意度下降，并最终导致其自食恶果。具体来讲，过度使用系统资源并不是种 明智的决定。

然而，即使是单一操作系统也可能出现性能波动——但这种偶然性事件就与资源利用规划没什么关系了。