理解微分区：关于 AIX 上处理器虚拟化的提示

核心提示： 虚拟处理器的作用从 OS 的角度来看，AIX 把虚拟处理器当作真实的 CPU，理解微分区：关于 AIX 上处理器虚拟化的提示(2)，您必须把它们看作是一个物理处理器周期复制的逻辑实体，对于每个虚拟处理器，系统上的 LPAR 越多，就可以设置更高的利用率目标，可以分配 0.1 到 1.0 个物理处

虚拟处理器的作用

从 OS 的角度来看，AIX 把虚拟处理器当作真实的 CPU。您必须把它们看作是一个物理处理器周期复制的逻辑实体。对于每个虚拟处理器，可以分配 0.1 到 1.0 个物理处理器以执行虚拟处理器运行队列中的任务。在任何情况下，一个虚拟处理器都不会占用超过 1.0 个物理处理器。因此，在线虚拟处理器数量决定 LPAR 可以达到的绝对最大 CPU 占用量（如果它的共享处理器池中有足够的可用容量）。也就是说，如果一个 LPAR 的标称值是 2.0 个处理器和 4 个虚拟处理器，那么这个 LPAR 最多能够占用 4 个物理处理器；在这种情况下，它报告 200% 的 CPU 利用率。必须牢记，在系统上配置虚拟处理器时，分配的虚拟处理器数量可以超过共享处理器池中的物理处理器数量，因此可能无法让 LPAR 的 CPU 占用量达到它的虚拟处理器数量。

同样，在配置 LPAR 时，必须为虚拟处理器数量设置最小/期望/最大值。这些值只作为动态 LPAR 操作的限制，在正在运行的 LPAR 上更改虚拟处理器数量时起作用。

从专用到共享

目前，非常多的客户以专用模式运行 LPAR。我经常遇到的一个问题是：在不影响性能的前提下，把 LPAR 从专用模式转移到共享不封顶模式的最佳方法是什么？最简单的方法是把模式从专用改为共享不封顶，并确保虚拟处理器数量等于标称处理能力。这样做，LPAR 会保留其标称处理能力，这是有保证的处理周期。有保证的标称处理能力确保这个 LPAR 得到的处理能力不至于太少，应用程序响应时间不会受影响。直接的好处是，这个 LPAR 不使用的 CPU 周期不会像专用模式下那样浪费掉，而是交给共享处理器池，可以供需要处理能力的其他 LPAR 使用。第二步是检查这个 LPAR 的 CPU 占用量，决定它是否可以使用更多 CPU。如果这个 LPAR 的 CPU 利用率有长时间稳定在 100% 的迹象，那么增加虚拟处理器数量（每次一个），让这个 LPAR 能够从未充分使用标称处理能力的其他 LPAR 借用处理周期。

在实现这种非常简单的方法时，有几个重要的注意事项。如果 LPAR 现在使用的处理能力超过它的标称处理能力，它报告的 CPU 利用率就会超过 100%。这会在一些性能监视软件中造成问题，也会让一些人不放心。另一个注意事项是，根据处理器池中的可用 CPU 数量，应用程序响应时间在不同时候会有变化。如果处理器池达到充分使用，使用的处理能力超过标称设置的应用程序的响应时间可能会降低到接近专用模式的水平。幸运的是，这种情况不常出现。如果您还没有在配置中启用处理器池，应该试一试；您会对释放的 CPU 数量感到吃惊。

优化池中的资源

过去几年，我开发了一种充分利用微分区环境的非常简单的方法。这种方法基于对标称处理能力的充分理解。在优化系统的利用率时，希望让每个 LPAR 的利用率尽可能接近平均 100%。把一个 LPAR 从专用模式转换到共享不封顶模式之后，逐步减少它的标称处理能力，让它报告更高的利用率，直到 LPAR 的平均利用率达到您满意的水平为止。LPAR 的负载高峰很可能会超过标称处理能力（100%），这没关系。如果受管理系统上所有 LPAR 的平均利用率都达到 90%，而且所有标称处理能力都分配了，那么整个受管理系统的利用率就会达到 90%。

在决定期望的 LPAR 平均利用率时，一个非常重要的考虑因素是受管理系统的规模。系统越大，系统上的 LPAR 越多，就可以设置更高的利用率目标。这反映了概率理论中的大数定律。