【.com快译】众所周知，了解容量的自然特性是我们采用云服务解决方案的前提，因为并不是每个系统的hypervisor都使用以相同方式运行的虚拟计算机制。而这一切都将对运行在云环境中的应用产生重要影响。大家可能还记得，AWS至少提供了两个控制指标：ECU（EC2计算单元）和vCPU（虚拟中央处理器）。在为本文搜集资料时，在AWS官方页面上找到了一些资料，指出vCPU的概念已经取代了ECU。我个人不明白这一点，因为两者都有明确而有力的存在理由。查了下发现AWS确实反驳了这个结论，这两个指标都要重视。事实上，在实际使用中你可能会发现，你确实需要一个ECU或其他一些基于容量的指标来控制系统，而不是“处理器”的数量。具体来说，ECU控制（或受用户管理）计算能力的使用。为了进一步讨论CPU虚拟化在云环境中的实际影响，我们将立足于给定的一个完整的SMP系统，包括该系统所能承载的最大容量。对于某些特定的工作负载，您可以尽可能地从SMP处理器中榨取计算资源，以获得最可观的吞吐量。如果在同一个SMP中安装多个操作系统实例，然后在它们上面运行相同的工作负载，你会发现它的整体吞吐量几乎不可能超过之前达到的上限。而这就是AWS提出的多工作负载混合概念，或者ECU；当然，其他云服务厂商也采用了类似的理念。无论我们使用什么样的SMP系统来构建云环境，系统都会有一个最大容量限制。因此，您从云端租用并添加到操作系统实例的容量（例如，以AWSECU的形式）永远不会超过此最大限制。虽然我们不知道AWS设置的最大容量限制是多少，但在PowerVM中，用户确实不能让所有活动操作负载的总和超过这个限制。您需要根据要求/需要为每个操作系统分配一定的资源配额，PowerVM负责满足/确保预期结果。在某种程度上，PowerVM知道它可以为每个OS实例分配多少资源，因为我们的OS容量需求是已知数量；各部分的总和只会等于或小于总容量。云服务提供商的工作是获取客户提供的参数并找出（至少在一段时间后）这些资源可用的位置。当然，仅仅达到这个目标是不够的。分配完成后，是否存在阻止OS实例获取完整SMP容量的因素？为了避免这种情况，或者保证每个实例都能得到自己必要的容量配额，我们可能需要强制vCPU做一个短暂的运行中断。这种情况在其他场景中也会出现。如果其他实例已经达到自身容量消耗配额的上限，则各操作系统实例将被暂停以调整配额。此过程的目的是确保所有vCPU都公平地分配给可用的硬件容量。在这方面，PowerVM对有上限和无上限的容量分配进行了有趣的衍生，我怀疑其他云提供商也选择了类似的方法。Cappedcapacity限制操作系统实例的容量消耗水平，不高于用户租用的容量上限。例如，假设您使用两个VP并为它们分配1.25个计算核心的总容量限额。这样我们的应用只能同时将自己的线程分配给这两个VP。但是，如果在一定时间内两者的容量使用总和超过了1.25个核心，则hypervisor将停止它们的运行。例如，如果一个VP一直运行，而另一个VP只运行了四分之一的时间，那么我们之前设置的容量上限将永远不会被突破，应用程序将继续正常运行。一般来说，在这种封顶模式下，大家可以在限制范围内充分利用容量，直到下一个时间段开始。对于uncappedcapacity模式，计算消耗仍然会被正确衡量，但是当实例达到capacitylimit时会提出一个新的问题：是否有其他操作系统VP需要这个额外的可用capacity？如果没有，没有其他运行系统VP处于资源等待状态，那么我们的VP超过限制后会继续运行。但是如果有等待的VP或者出现需要使用capacity的新VP，新的VP会接管相应的capacity，而原来的VP需要停止执行。在这种情况下，当等待的VP快速完成其执行任务时，处于等待/可调度状态的VP可以继续之前未完成的执行工作，仍然以超过容量上限的方式继续运行.听起来不错，对吧？在我们的示例中，这可能意味着您应该更喜欢无上限模型，其中PowerVMOS实例的2个VP和1.25个内核可以继续在2个内核上运行。跑步。在这种情况下，实际吞吐量是2个完整的计算核心，而不是预设的1.25。是的，这很好用——但前提是我们的SMP系统在资源使用方面一直很低，这样vCPU才能保持平稳运行。在这种情况下，每个人都会习惯使用2个完整的计算核心——而不是1.25个——来执行给定的任务。但是随着时间的推移，一些资源匮乏的操作系统可以进入我们同一个SMP系统并一直保持忙碌。这意味着系统中不再有可用的空闲容量；容量重新封顶到1.25个核心，吞吐量的实际速度性能甚至会低于我们的预期水平。请注意，这不是真正的性能问题，而只是期望管理不当造成的冲突。此外，这种做法不会损害性能，其他操作系统实例仍然可以按预期正常运行。缓存的存在让我们很难准确衡量容量的上限。至此，我们了解到在任何单个SMP中都存在最大可用容量限制。有人可能会争辩说，有多种方法可以衡量这一容量上限——但现实情况是，大多数衡量标准都将驻留在处理器缓存中的大部分数据计算为容量水平的一部分。由于缓存访问速度远快于DRAM，缓存的介入可能会使我们的最大容量限制估算结果与实际情况相差甚远。如果不考虑缓存机制，那么最大容量限制可能会低很多。另外，如果缓存中的数据与实际访问对象的交集比较有限，最大容量也会受到严重影响。也正是因为有这种情况的存在，后面才需要我们详细描述。你会记得，我们的操作系统需要和其他一些同类型的实例共享SMP系统的容量，而我们可以使用的容量只是SMP系统总容量的一小部分。之所以使用处理器虚拟化机制，是为了保证不同的实例可以共享SMP系统的整体容量。只要这种共享“足够好”，操作系统和其他实例的性能就会令人满意；他们共享测量的上限。因此，让我们换个角度，从最坏的角度来看这个问题。在展开讨论之前，我们先厘清一个相关的概念。我们假设可以分配给每个OS实例的容量总和小于SMP系统中存在的总可用容量。我们还需要强调的是，每个OS实例都可以使用一定数量的VP。虽然整体容量受到限制，但这并不意味着每个活动操作系统中的总VP容量需要等于物理处理器的计算核心数（或SMT线程数）。这意味着VP的数量可以被超额订阅，可能会超过实际的处理器数量。事实上，有时我们倾向于选择这种方式；在中低CPU利用率的情况下，更多的VP可以保证我们的操作系统有更好的响应时间性能；和并行执行——而不是单个VP中的队列执行机制还可以更快地完成某些任务。然而，这也意味着更高的容量利用率，其中活动VP的数量远高于可分配给它们的物理处理器数量。更直白的解释，为了保证容量被正确使用，hypervisor需要划出时间片来保证物理处理器实际上可供更多的VP使用。例如，我们假设系统中有32个物理处理器和256个活动VP。这种设计方式其实非常合理，一套系统资源被数百个操作系统实例共享的机制随处可见。为确保容量的公平分配，管理程序必须将角色分配给32个处理器上的256个VP，同时尽可能快地分配角色以确保用户直观地感知到这些VP正在同时执行。现在让我们再谈谈缓存。当任务开始在计算核心上执行时，任务的数据状态不驻留在缓存中。系统需要运行一段时间才能确认这种情况，并从DRAM或其他缓存中提取到主缓存中。虽然一般来说缓存中的常驻数据会在相关任务完成一段时间后释放，但对于一些始终在计算核心上执行的任务，其状态数据往往会长期驻留在缓存中接受重用的时间。运气好的话，这个任务会长期占用计算核心，借助缓存常驻数据（和指令）状态，性能会得到显着提升；毕竟缓存的目的是为了实现对常用数据的快速访问。即使在虚拟环境中，任务仍然可以长期驻留在处理器缓存中，从而保证其执行状态始终得到缓存机制的支持。在保持缓存状态的同时，其最终吞吐量将因此得到显着提升。这在低利用率和无上限操作模式下尤为明显。如果对处理器及其缓存资源的竞争不多，则任务的缓存状态会长期保持稳定。但现在让我们添加额外的工作负载（和更多VP）以提高虚拟化SMP的资源利用率。在这种情况下，我们可能会发现活跃的VP数量导致的过剩容量需求在增长，而任务状态——即VP分配到指定的时候状态数据进入缓存所花费的时间processor-当管理程序在处理器上执行VP切换时，它也会被刷新，这意味着其他VP数据将取代它。当我们的任务VP不断的在处理器之间切换的时候，它运行的处理器肯定会同时发生变化。这样，如果VP要恢复执行，状态数据进入缓存的时间就会大大延长。想象一下每次交换VP时都会发生这种情况。这意味着上面提到的缓存准确率开始下降，能够完成的任务不断减少，进而导致总吞吐量严重缩水。任务的完成过程需要更多的时间，并且长期驻留在自己的VP中而不是完成并发布，在此期间我们将无法获得可接受的合理响应时间。云服务提供商很清楚这些问题。大家需要了解影响处理器虚拟机机制的这些因素。但我们几乎可以肯定，云服务提供商比我们更了解这些问题——或者应该更了解它们。对他们来说，管理好自己的系统显然很重要，上述只是一些相关因素。我们还几乎可以肯定，云服务提供商将能够在其整体环境中部署更多容量以满足客户对性能的实际需求——即使所有操作系统实例都处于繁忙状态。当容量需求增长或不可避免地发生故障时，他们自己的系统会主动待命。其中一些系统甚至会自动关闭，以确保在不需要时尽可能地节省能源消耗。云服务提供商也有能力在不同的SMP系统之间迁移各种操作系统实例。当某个系统的资源利用率增加到高风险级别时，他们可能会决定将用户的操作系统实例转移到另一个负载较低的系统。反之亦然；如果有大量的系统分布在多套低资源利用率的系统中，那么它们会倾向于收集这些操作系统来减少系统占用的数量——这样可以有效降低系统运行带来的整体性能.消费水平。这种迁移操作系统实例并知道何时关闭和整合系统的能力意味着云服务提供商会不断密切监控他们的环境。正如我们前面提到的，这些供应商将负载平衡视为一门科学，这种严谨可以带来真金白银的回报。但与大多数企业一样，提高客户和潜在新客户的满意度也能带来丰厚的财务回报。换句话说，严格监控容量波动水平以提供稳定合理的性能水平不仅有利于客户，也有利于云服务提供商本身。因此，虽然云服务提供商在某些方面能够通过将尽可能多的操作系统实例塞入少量活动SMP系统来最大化经济回报，但他们很清楚这种方法会通过低端杀死鸡和鸡蛋。低性能水平会导致客户满意度下降，并最终导致自我造成的后果。具体来说，过度使用系统资源并不是一个明智的决定。然而，即使是单一操作系统也可能会出现性能波动——但这种偶然事件与资源利用规划关系不大。原始标题：云中的CPU虚拟化：获取您的切片等
