理解Power Systems下的处理器利用率 - AIX

原文地址： https://www.ibm.com/developerworks/community/wikis/home?lang=en-us#!/wiki/Not%20AIX/page/Understanding%20Processor%20Utilization%20on%20Power%20Systems%20-%20AIX
原文标题：Understanding Processor Utilization on Power Systems - AIX Understanding Processor Utilization on Power Systems - AIX 

简介

传统习惯下，我们通常将CPU使用率作为衡量系统负载的主要性能指标，以此为据规划产能与预算。然而在近期十年间，CPU技术发生了巨大的发展，所以我们在此呼吁对CPU使用率正确计算与解读。本文将详细解读在AIX环境下CPU使用率的计算方法，及其十年间与IBM POWER 处理器技术的发展变化过程。

背景

当今这个行业正朝着计算资源更加整合以最高效化运算的方向发展。通过云计算服务将可以处理更大的事务，理解资源使用率的指标，并推动其提高至接近100%，对这些服务的供应商与客户而言均是很重要的。

理解资源使用率与闲置状况将比早前更加重要。处理器是一个系统资源中最为重要的部分，处理器使用率也是衡量系统负载性能的主要指标。IBM POWER处理器技术在过去十年间经历了重大的发展。与此同时，在AIX上的CPU使用率计算方法也发生了相应的变化。

	注：
	在本文中，“核心（Core）”一词代表了CPU(Central Processing Unit)。曾经我们使用过的为单芯片CPU，而今天我们在一个芯片上可拥有多个CPU，每个芯片上的单个CPU即称为“核”。也请注意，本文中的“任务（task）”代表的是操作系统线程（软件线程或工作单元）

理解处理器使用率

处理器使用率标示了当前处理器的繁忙程度，并还有多少空闲资源处理能力。处理器核心用于执行事务。单位时间内处理器核心执行事务的繁忙程度即核心使用率。一个POWER处理器核心执行事务的频率差不多为每个处理器周期运行一次。（处理器周期取决于处理器运行频率：4GHz频率的处理器——每秒运行40亿个周期——即每个周期为4纳秒）一条事务并非总在一个处理器周期就能执行完毕。相反，一条事务的完成将通过多个场景，每个场景为一个处理器周期时间，直到处理器核心将事务处理完毕。我们可以将其想象为一条生产流水线，每个场景在一个周期处理事务的一部分内容后交由下一个场景处理。像是生产流水线一样，一旦事务经过了一个场景，随后场景可以从前述场景处理的状态继续。图-1举例说明了执行事务A到G的过程，我们将其形象地称之为“管道”。

图-1
每个管道运行最大执行事务频率为每个周期一条事务。通常在单一管道架构，处理器核心将在执行时间内积极处理来自任务的事务。因此，任务的总体执行时间即很好的反应了处理器核心的使用率。在此架构下，处理器核心资源使用率的计算，可仅通过单一任务的执行时间直观反应出来。

图-2
如图-2，处理器使用率，单纯通过计算处理器核心处理任务消耗的时间即可得知。对于多处理器环境，通过系统使用率总量平均至单个处理器亦可得出单核心使用水平。该情况可见图-3。

图-3
Core1、Core3被标记为红色表示它们状态为充分使用，这意味着它们正忙于处理任务。Core2、Core4没有运行任何东西，因此处于闲置。在这个例子中，总的CPU使用率为50%,其中Core1、Core3繁忙度为100%；而Core2、Core4繁忙度为0%，因此平均值为50%。上述情况简单说明了任务的执行时，处理器核心使用率的计算方法。

让我们来看一个非常简单的例子。应用程序“myapp”需要单个处理器有每秒处理两条事务的处理能力与足够的执行时间。在空闲的单处理器系统下执行“myapp”将花费一秒完成，因此在AIX中执行time命令将输出如下结果：

通过上述输出报告可看出，该应用程式实际运行了1秒使用“real”表示，在用户状态下消耗了1秒使用“user”表示。这对于理解“real”表示实际经过时间，且同时为处理器处理执行“myapp”程序事务时间是“user”总量与“sys”之和是重要的。此时通过AIX的sar命令我们可以看到如下输出：

此处sar输出结果中已删除了header与system configuration行，以提高可读性。

sar命令明确表示了使用率的百分比情况。监控间隔为1秒，sar命令输出表示处理事务时仅cpu0为100%繁忙。行“-”表示整个系统的使用率，且由于该系统中仅有一个cpu，所以系统使用率也为100%。接下来我们在有2个处理器的系统下运行同样的“myapp”程序。time命令输出依旧，但是sar命令输出发生了变化，结果如下：

此处sar输出结果中已删除了header与system configuration行，以提高可读性。且该例子中，“myapp”始终运行于cpu0之上。

上述输出系统使用率为50%，这是由于处理器核心只有一个繁忙而可使用的为两个。

理解近期POWER服务器的处理器使用率

通过上一节，我们简单理解了传统方式下处理器使用率的计算方式。正如前文所述，IBM POWER处理器在近十年间经历了相当大的发展。自IBM POWER4家族起，处理器核心支持多“管道场景”方式，其允许独立的事务并行执行。这使得执行事务的处理能力有了显著提高。通过引入多管道，最重要的是确保了所有管道场景高效与充分利用。图-4举例展示了各种执行单元如何利用典型的多管道架构。

图-4
每一行代表一个执行单元；而每一列代表了一个处理器周期。蓝色方块表示该执行单元在当前周期为忙碌。现在，我们以顺序流方式为例，看一下事务A到H的任务如何通过多管道执行。

图-5
注意某些事务如E与D虽然可以并行执行，但是单任务事务流在整个管道场景下仍旧不会更高效。为了更高效利用整个管道场景，同步多线程（Simultaneous Multi-threading即SMT）的概念产生了。SMT可使同一核心下运行来自多个任务的多个事务流。它们那些通常情况下独立的事务流，确实以并发方式执行着；如果一个管道场景未被某一任务的事务占用，其它任务的事务即可使用它。相反，如果多任务事务想要使用某一管道场景，一个周期内仅它可以使用，其它任务事务即刻延迟。此处区别尤为重要。

图-6描述了在硬件双线程SMT模式下，管道场景如何得到利用：

图-6
通过SMT，处理器核心可提供多硬件线程环境。如果是POWER5与POWER6处理器，每个核心可支持1、2个硬件多线程环境。POWER7处理器可支持每核心1、2或4个硬件多线程环境。（译者：据称过不久将发布的POWER8最大可支持硬件多线程数量可达为8条）在AIX操作系统中，每条硬件线程将会被看成一个逻辑CPU。图-7描述了POWER5与POWER6处理器的行为：

图-7
图-8描述了这样一个例子：在早前例子中（图-6）我们增加了一个任务事务流，可以看到显著的效果。注意此时Task1所花费的周期保持不变，同时增加了Task2的事务流的执行，因为核心管道足以提供两个事务流所需的管道场景。当然，并非总是都能如此；如果管道场景不足以满足所需，任务将必须等待。一般来说，这通常意味着两个任务的执行速率均会变慢。

图-8
值得注意的是，同一核心之上执行两个任务于相较两个核心并不尽相同。如前文所述，AIX操作系统支持SMT将硬件多线程（Hardware thread context-Htc)视为一个逻辑处理器，这可使硬件多线程实现更加简单。而由于操作系统将硬件多线程视为逻辑处理器，导致传统的资源计算方式的结果不再准确。让我们回顾一下执行“myapp”的那个例子。图-9表现了“myapp”的两个实例运行于不同的两个核心：

图-9
两个实例每秒合计可以执行4个事务。让我们回顾一下，在传统计算方式下，一个“myapp”实例的sar输出。

此处sar输出结果中已删除了header与system configuration行，以提高可读性。

sar的cpu列，代表AIX的逻辑CPU id号，并对应了相应Htc。在这里，我们假设cpuid0与1在第一个核心上；2与3在第二个核心上。（注：逻辑CPU 或硬件CPU id号并不会被连续分配。）sar命令看到此时可用资源为50%。通常情况下我们会预期，由于仍然还有50%可用，如果增加两个“myapp”的实例，其tps（transactions pr seconds）将应当线性增长至接近8。我们可通过图-10来看看。

图-10
图-10表现了“myapp”以单命令方式运行，其time命令输出如下：

我们注意到，相比单个实例，完成两个事务“myapp”多花了0.33秒，tps降低了1.5。相比两个核运行在单核心吞吐量同样的时间内降低了2-3tps。这意味着吞吐量为6 tps而非8 tps。显然系统的剩余资源并非有50%那么多。当核心开启SMT模式时，准确理解剩余资源是多重要的事情。

除了SMT以外，IBM POWER引入了可以在多个逻辑分区（logical partitions - lpar）间共享处理器核心的功能。图-11即这种方式。

图-11
PowerVM Hypervisor可以将物理处理器核心通过虚拟化方式分配给AIX操作系统。PowerVM管理物理处理器核心的时间片，分配给操作系统。AIX操作系统只会将其看成虚拟的核心。当SMT功能关闭时，一个hypervisor虚拟出的处理器核心对应AIX当中的一个逻辑处理器核心。当处在共享处理器核心资源方式下，使用的是处理器的片段，理解处理器利用率则更加重要。

自POWER5处理器架构开始，引入了一个名为PURR新的寄存器，用于协助利用率计算。PURR即Processor Utilization of Resources Register，且可供于每个Htc。PURR作用于硬件线程的实际物理计算时间单元。PURR的硬件增量基于每个硬件线程如何使用处理器核心资源。PURR的计数与实时时钟（timebase）成比例。因此一段时间内处理器核心的独立硬件线程PURR合计值将非常接近timebase。PURR与Timebase之比的分数即被赋值为一段时间内核心利用率。AIX性能报告工具对CPU利用率计算方式更新引入PURR后，相比传统模型提供了更加精准的结果。现在，让我们再来回顾在AIX下，当两个“myapp”实例运行于两个不同核心上时，sar命令的输出结果：

此处sar输出结果中已删除了header与system configuration行，以提高可读性。

在以上输出中，sar新增了一列用于显示核心消耗分数，名为“physc”。并且系统资源利用率修改为报告处理器资源的物理利用率，不再以传统单个CPU利用率平均值的方式给出。以上输出显示，2个“myapp”实例运行于不同2个核心时，消耗了整个核心且没有空余资源可供使用。

接下来的场景，我们再来看4个“myapp”实例运行于两个核心时sar的输出情况：

此处sar输出结果中已删除了header与system configuration行，以提高可读性。

注意每个“myapp”的实例仅得到了50%的物理核心。这显然指出了为何吞吐量有所降低，如果两个“myapp”实例安排到同一核心，其将从2tps降低至1.5tps。AIX新进提供了名为“mpstat”的小工具可以印证上述观点。这将有助于理解独立Htc（逻辑处理器）利用率。在上述场景中，mpstat的输出将得到如下结果：

注意，以上输出中“Proc*”条目表示的为虚拟处理器。“cpu*”条目表示的则为逻辑处理器。在任一时间点内，虚拟处理器将被执行于一个核心之上。

自POWER6处理器架构开始，处理器频率可以改变。这使得用户在处理器使用方面的更能灵活有效利用能源。因此，处理器频率可以运行于默认频率之下。这意味着性能报告的复杂性增加到了另一水平。通过PURR用户将可以看到处理器基于当前频率运行时的利用率，同时用户可以了解在他们系统中的所有闲置可用资源。出于这个原因，POWER6新增增加了一个寄存器，SPURR。SPURR即Scaled Processor Utilization of Resources Register。SPURR与PURR类似，除了在处理器核心频率相对比率上有所不同。这意味着，当CPU运行频率仅为默认频率50%时，SPURR的增量比率也仅为PURR的一半。For accounting or charge back，AIX的计算利用率始终基于SPURR，而报告利用率始终基于PURR。SPURR-PURR比率用于计算频率变化。AIX的lparstat、sar与mpstat工具修改并新增了报告PURR-SPURR比率的列，名为“nsp”。PURR基准利用率仅用于指出基于当前处理器频率的空余资源，与用户想要知道可用剩余资源的情况。

试想一个LPAR上运行着4个物理处理器核心。当其运行于标称频率F，其50%计算负载下，基于PURR与SPURR，两者physc均为2。当处理器运行于频率为0.5F，基于PURR的physc将报告为4，而基于SPURR的physc则为2。基于SPURR的报告值显出处理器核心有额外的空闲能力，这是由于虽然处理器频率相对额定频率降低，可以视为频率恢复额定后系统当中将会拥有相应的空闲处理能力。基于PURR的标准并不能表现以上信息。所以基于SPURR的标准广泛用于产能计算与规划。当运行于turbo模式下也将如此，图-12表现了这些方式：

图-12
现在来回顾一下上述表现时AIX lparstat命令的表象：

上述lparstat快照为处理器运行在50%额定频率（F/2）时截取，因此%nsp报告值为50。

在POWER7架构下，处理器核心支持4硬件线程上下文，这意味着一个核心将可以运行4条线程的指令流。并且POWER7为用户提供了灵活可选方式，用户可以根据自己情况时期运行在硬件单线程（ST）、双线程（SMT2）或四线程（SMT4）负载下。POWER7处理器的PURR作出了改进，以提供更精准的处理器利用率级别测量。显而易见的问题是，为什么改进PURR，其与POWER5或POWER6时在利用率度量方面有何差距。让我们来回顾一下前面的“myapp”示例：
核心运行单实例

核心运行双实例

当两个“myapp”的实例运行在一个核心上时，比单实例多花费了0.33秒即完成。通过简单的数学运算，一个“myapp”实例获取仅50%的核心时间，之后它应该花费1.50秒来完成两笔事务。相反“myapp”可以在1.33秒内就完成两笔事务。这实际意味着，当“myapp”仅有单实例运行时，是有一些额外的空闲资源可用的，结果这部分资源被调用于“myapp”实例的执行。这导致了可用空闲处理器负载资源方面的理解偏差。下面的章节详细讲述了关于基于POWER7处理器系统的处理器利用率报告。

理解基于POWER7处理器系统的处理器利用率

在POWER7中PURR被改进得更适于描述核心空余资源。这个显著的变化，使得处理器利用率与可用资源更好计算。因此利用率数值将看起来与POWER5或POWER6处理器有所不同。这意味着真正的不同在于理解上的差异。

如前面所述，POWER7处理器可以运行于ST、SMT2、SMT4模式。单进程与单线程应用适用于ST模式运行；多线程与（或）多进程应用更适合在SMT2或SMT4模式下运行。在应用进程数量小于分区分配核心数量时，ST模式则可使多进程应用运行得更好。不大量使用CPU数量的应用在SMT2或ST模式下相比SMT4可能更适用，因为更少的SMT线程将意味着逻辑CPU的数量更少。

ST、SMT2或者SMT4模式的选择可以通过AIX下的smtctl命令来设置。默认模式为SMT4。让我们再次使用“myapp”示例，以更好形象理解资源利用率的描述。我们将运行“myapp”应用到如下scenarios：
Scenario-1: ST mode
Scenario-2: SMT2 mode
Scenario-3: SMT4 mode
为了更简单理解，我们仅使用一个核心。 Scenario-1(ST Mode)

图-13
因为只有一个Htc，因此该场景将类似单处理器核心架构，即一个核心上仅能运行一个“myapp”实例。由于核心仅能在同一时间允许一条指令流，time与sar命令的输出将如下：

此处sar输出结果中已删除了header与system configuration行，以提高可读性。

Scenario-2(SMT2 Mode)

图-14
在此场景，核心上将运行两个Htc。现在使用改进版的PURR，AIX将可识别估算一个核心上有两个Htc时，运行“myapp”的相关实际可用资源。 现在让我们来看看此时AIX下time与sar命令的输出，结果如下：

此处sar输出结果中已删除了header与system configuration行，以提高可读性。

以上输出显示cpu0（其实为Htc0）在运行“myapp”应用时使用率为100%，但是对整个核心（Htc0，Htc1）而言，“myapp”的占用资源率为仅69%（0.69个物理处理器核心，此处用physc表示）。这明确显出，处理器还具有额外的工作负载处理能力。与此更重要的一个区别为time输出，即红圈部分。简单说，time命令输出的“user”时间为0.69秒。早前解释过time命令输出时，有以下内容：

这对于理解“real”表示实际经过时间，且同时为处理器处理执行“myapp”程序事务时间是“user”总量与“sys”之和是重要的。

由于改进版PURR的估算，现在“user”与“sys”的结果也更加精准。另一需要紧记的是，处理器的繁忙时间总是与其所具处理能力相关。因此处理器的处理能力有所上升，则处理器在同样负载下的繁忙时间也会相应减少。
Scenario-3(SMT4 Mode)

图-15
在此场景，核心上将运行四个Htc。这意味着处理器处理能力将可支持同时并发执行4个任务。现在让我们来看看此时AIX下time与sar命令的输出，结果如下：

此处sar输出结果中已删除了header与system configuration行，以提高可读性。

上述输出可看出，Htc增加到4条之后，可用处理能力由31%增长到了37%。可用处理能力并未随着Htc出现线性增长。这是由于，这些Htc是被一定数量的资源共享使用的。time命令的输出显出了不同时间“myapp”积极使用核心资源的情况。

这里上述场景为例，表现出了POWER7与早期POWER家族处理器之间，基于实际工作负载的资源利用率计算方面的不同。

SMT处理器——自POWER5到POWER7——提供了一个内部机制来追踪每个相关核心的使用情况。POWER7进一步调整了该测算方式。其常规目的为用于测算CPU利用率在当前吞吐量（如transactions per second，每秒事务量）与CPU利用率的吞吐量间的线性关系。例如，假设CPU处理能力不会受到其它不相干问题影响，那利用率50%时候吞吐量为10，000 tps应该意味着利用率100%吞吐量可以达到200，000tps。

POWER7的利用率测量表现一些典型负载情况时吞吐量与CPU利用率呈的接近线性关系。然而，非典型负载看来将从SMT4能得到少量甚至很大好处，其呈非线性关系。通过POWER7的利用率测量，用户将可以做出更准确的处理能力规划与分级。

后续的部分，将讲述在核心为被逻辑分区共享情况下——即微分区环境，如何理解处理器利用率。

理解微分区环境下的处理器利用率

在微分区环境（micro-partitioned environment）下处理器核心将被分配给各个逻辑分区(logical partitions)共享使用。每个逻辑分区将至少分配到1/10个处理器核心。因此逻辑分区将运行在所得到的处理器片段下。被分配到一个分区的处理器核心被称为"Entitlement"。逻辑分区可以运行在处理器核心片段受限（capped）与非受限（uncapped）模式，可以根据需求与可用情况得到更多额外的处理器片段。

让我们来看一个简单的例子，在entitlement为0.1个物理核心、且SMT关闭的受限分区下。这意味着该分区仅能使用10%的核心资源。我们运行“myapp”应用并查看time与sar命令的输出：

上述报告中，“real”显出，“myapp”实际经过了10秒得以完成。原因在于仅有10%的核心资源分配到分区参与了应用的计算，使得耗费了更多的时间完成。“user”得出结果仍然为1秒，即核心积极处理“myapp”事务的话仅需1秒。显而易见的问题是，那么剩下的9秒核心都干嘛去了。如前面说提到，核心其实与其他分区共享的，那么该核心就有可能正在其它逻辑分区积极处理着事务。并且sar命令的输出是间隔1秒，那分配给这个分区10%核心的的处理器总是100%繁忙，那么“physc”列报告即为0.1个处理器核心被消耗。

理解在节能模式下处理器的利用率

从POWER6家族起，引入了节能模式。通过节能特征，用户将可以限制处理器资源的能源消耗。基于POWER7处理器动态节电模式的引入，能耗将可以自动根据处理器资源利用率来控制，调节水平可以根据用户节能或性能需求进行优化。处理器资源的能耗取决于控制调节处理器核心的频率。这些功能需引入新的报告方式，以在用户理解当前处理器运行频率下，基于当前频率和额定频率的利用率关系。

在AIX 5.3 TL11与 AIX 6.1 TL04中，lparstat工具引入了一个新的报告方式。新报告同时使PURR与SPURR同时基于处理器频率变化而变化。以下为lparstat工具的简单输出：

该报告中系统运行了128个逻辑CPU且开启了SMT4。这意味着可用物理核心数量为32。该报告同时提供了Actual与Normalized（额定频率）。actual使用PURR计数；normalized使用SPURR计数。每种模式所示的值对应该模式所使用的实际物理处理器数量。actual与normalized两边增加的所有值（user，sys，idle，wait）将等于分区所有的entitlement。但是在共享非受限模式下不用如此，实际的处理器消耗可以超过entitlement。所以在这种情况下这些值可能不相等。且idle值亦被修改，以显示实际可用entitlement。所以这种情况下所示的值不应与lparstat的默认视图相比。此处的idle值为可用计算能力。

idle = Entitlement - ( user + sys + wait

当分区运行在降频模式，那么实际可用计算能力（idle）与两者所示的计数是不同的。当前的idle资源为通过PURR所示；SPURR所示idle值为（近似）处理器核心运行在额定频率idle资源。

参考资料

Simultaneous Multi-Threading on POWER7 ^TM Processors
CPU Frequency Monitoring using AIX? lparstat tool

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29375284/viewspace-1062716/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29375284/viewspace-1062716/