PowerVM虚拟化环境下 CPU 利用率的监控与探究

本文主要介绍在 PowerVM 虚拟化环境下，微分区 CPU 利用率的监控方法，并且深入讨论在虚拟化环境下，CPU 的调度原理。

普通 LPAR CPU 利用率的查看

在 AIX 操作系统中，可以监控 CPU 利用率的命令有很多，最常用的 nmon、topas、vmstat、sar –u 等等。

在 单 CPU 线程（SMT OFF），单线程应用的环境下，CPU 利用率的输出结果很容易看懂，如下：User% 代表系统中用户进程占用的 CPU 比率；Sys% 代表系统调用所占的 CPU 比率，Wait% 代表等待 I/O 响应的 CPU 比率，Idle% 代表空闲 CPU 的比率。下面我们将主要分析在微分区中，CPU 的调度原理以及监控方法，以及在多 CPU 线程和多线程应用的环境下，监控 CPU 利用率的方法。

CPU User%  Sys%   Wait%   Idle%|
0   0.0      1.0      1.0      98.0|>
1   0.0      0.0      0.0     100.0|>
2   0.0      20.0     0.0      80.0|ssssssssss>
3   0.0      10.0     0.0      90.0|sssss>
4   0.0      4.1      1.0      94.8|ss>
5   0.0      0.0      0.0     100.0|>
6   0.0      10.0     0.0      90.0|sssss>
7   0.0      30.0     0.0      70.0|s

微分区 CPU 利用率以及调度的探究

微分区概要文件的设置规则

在创建分区的时候，选择创建共享 CPU 分区，如下图：

图 1. 创建共享 CPU 分区

在接下来的页面中，需要设置虚拟 CPU 和物理 CPU 的数量：

图 2. 设置虚拟 CPU 和共享 CPU 的数量。

关于上图几个数值，这里需要详细说明。

我 们知道，在当前的 PowerVM 版本中，一个虚拟 CPU 最多可以调度 1 个物理 CPU。在概要文件的设置中，我们既不能将虚拟处理器设置的太多，这样会造成过多的 CPU 上下文切换；也不能将其设置的过低，那样微分区将不能调度或者获取足够的物理 CPU。

物理 CPU 的“最小处理单元数”、“ 期望处理单元数”、“ 最大处理单元数”的含义与普通 LPAR 没有区别，分别代表“激活分区所需的最少物理 CPU 资源”、“激活分区时期望获取的物理 CPU 资源”、“分区可以获得最多物理 CPU 资源”。就普通 LPAR 而言，一个分区激活以后，其自动获取的 CPU 资源处于“大于等于“最小处理单元数”、小于等于“ 期望处理单元数”的闭区间内”。“ 最大处理单元数”的设置数值，是手工对分区做 DLPAR 操作时，LPAR 可以增加到的最多 CPU 数量。

虚拟 CPU 的“最小虚拟处理器数”、“ 期望虚拟处理器数”、“ 最大虚拟处理器数”的含义分别为：“激活分区所需的最少虚拟 CPU 数量”、“激活分区时期望获取的虚拟 CPU 数量”、“分区可以获得最多虚拟 CPU 数量”。从概念的描述上看，虚拟 CPU 的数值含义似乎无太大的差别，只是多了“虚拟”两个字，实际上区别很大。实际上，虚拟 CPU 的数量我们可以设置的很大，因为这个较大数值不会给客户带来成本，而事实上，虚拟 CPU 实际上也不存在不够用的情况，除非我们将其设置得过小，而共享 CPU 池中的空闲物理 CPU 很多。

微分区的意义在于降低 CPU 的空闲率，从而降低客户的 IT 成本。因此，在这种情况下，我们通常将 对等的虚拟 CPU 的数量设置的比物理 CPU 的数量要高，否则就失去了微分区意义。

专用 CPU 分区的 CPU 共享功能

在 PowerVM 中，专用 CPU 分区在其 CPU 空闲的时候，也可以将其空闲的 CPU 处理能力分给 CPU 共享池。这个功能的打开与关闭，由如下两个系统参数控制，我们一般将两个参数的数值设置相同 :

smt_snooze_delay：控制 CPU 的第 1 个、第 2 个线程的释放时间。

smt_tertiary_snooze_delay：控制 CPU 的第 3 个、第 4 个线程的释放时间。

这 两个参数的含义是：当 Hypervisor 发现专用 CPU 分区 CPU 空闲的时候，将空闲的 CPU 分给 CPU 共享池使用的 delay 时间，如果这个数值设置为 0，则表示没有延迟，即立刻将空闲 CPU 共享给 CPU 共享池；设置为 -1，表示关闭此功能；如果将数值设置成 0-100000000 之前的数值，则表示延迟的微秒数，数字越大，延迟越大，CPU 共享池能获取到的专用 CPU 分区的空闲 CPU 的时间就更长。

在系统中，我们用 schedo -h 命令可以查看两个参数的含义：

#schedo -h smt_snooze_delay
 Help for tunable smt_snooze_delay: 
 Purpose: 
 Amount of time in microseconds in idle loop without 
 useful work before snoozing (calling h_cede). 
 Values: 
        Default: 0 
        Range: -1 - 100000000 
        Type: Dynamic 
        Unit: microsecs 
 Tuning: 
 A value of -1 indicates to disable snoozing, a value of 0 
 indicates to snooze immediately. The maximum value of 100000000 
 corresponds to 100 seconds. 
 atsnfs[/atspersonal/weixinyu/123]# 

 #schedo -h smt_tertiary_snooze_delay 
 Help for tunable smt_tertiary_snooze_delay: 
 Purpose: 
 Amount of time in microseconds in idle loop on tertiary thread without 
 useful work before snoozing (calling h_cede). 
 Values: 
        Default: 0 
        Range: -1 - 100000000 
        Type: Dynamic 
        Unit: microsecs 
 Tuning: 
 A value of -1 indicates to disable snoozing, a value of 0 indicates to 
 snooze immediately. The maximum value of 100000000 corresponds to 100 seconds.

微分区“处理器折叠”（Processor Folding）功能

在 PowerVM 的微分区环境下，PowerVM Hypervisor 负责虚拟 CPU 的调度。

我们继续上一小节中关于设置微分区概要文件的例子，假设我们将概要文件中虚拟 CPU 的数量设置的比物理 CPU 数量多（实际上这样才有意义）。

在 微分区中，系统在 CPU 利用率低的时候，可以关闭一些虚拟 CPU，以减少 CPU 上下文切换，降低系统开销，从而提高性能；而当 CPU 利用率很高，系统将会相应地启用被关闭的 CPU，这个功能被成为“处理器折叠”(Processor Folding) 功能，它主要由如下参数决定：

 # schedo -o vpm_xvcpus 
 vpm_xvcpus = 0

vpm_xvcpus 可调参数的缺省值是 0，表示启用了折叠 (Processor Folding) 功能。这意味着虚拟处理器正接受管理。

 # schedo -o vpm_fold_policy 
 vpm_fold_policy = 1

可以根据分区是共享处理器分区还是专用处理器分区来启用或禁用“处理器折叠” (Processor Folding) 这一虚拟处理器管理功能。另外，当分区处于静态省电方式时，将对共享处理器分区或专用处理器分区自动启用处理器折叠功能 (Processor Folding) 。

vpm_fold_policy参数有三个设置功能位：

设置为 1 时，此位表明启用处理器折叠功能（如果分区正在使用共享处理器）。

设置为 2 时，此位表明启用处理器折叠功能（如果分区正在使用专用处理器）。

设置为 4 时，如果分区处于静态省电方式，那么此位将禁止自动设置处理器折叠功能。

对于微分区的环境下，vpm_xvcpus 为 0，vpm_fold_policy设置为 1 即可，我们不需要对两个参数的默认数值进行修改。

例如，我们有一个分区，虚拟 CPU 的数量是 6，物理 CPU 的资源是 0.6：

图 3. 利用 DLPAR 查看分区配置

此时，系统十分空闲：

查看到系统中虚拟 CPU 的数量： # prtconf |grep "Number Of Processors" Number Of Processors: 6 查看到由于系统开启了 SMT-4，因此系统中逻辑 CPU 的数量为 24

此时 6 个虚拟 CPU 的 24 个逻辑 CPU 并未完全展开 :

如果将 vpm_fold_policy 设置为 4，即关闭该功能，那么 24 个逻辑 CPU 将全部展开：

在 系统中，还有一个内核参数：vpm_xvcpus。它的作用是控制当微分区 CPU 不足的时候，系统可以自动启动的微分区的数量。如果将这个值设置为 -1，则表示关闭此功能；若设置为 0，表示启用了折叠功能 (Processor Folding) 。这意味着虚拟处理器正接受管理，分区启用了 CPU 折叠功能。默认数值设置为 0，表示分区可以启用其关闭的虚拟 CPU；如果 vpm_xvcpus 数值设置大于 1，则表示系统不仅可以启用其关闭的虚拟 CPU，还可以启动额外的虚拟 CPU，前提是分区的虚拟 CPU 总数不大于分区概要文件最大虚拟 CPU 数量的设置。

分 区需要的虚拟 CPU 的总数 = 物理 CPU 使用数 + 要启用的更多虚拟处理器的数目。如果所需的虚拟处理器的数目小于当前已启用的虚拟处理器的数目，则利用分区的 CPU 折叠功能 (Processor Folding) 停用部分虚拟处理器。如果所需的虚拟处理器的数目大于当前已启用的虚拟处理器的数目，则启用已禁用的虚拟处理器。连接到已禁用的虚拟处理器的线程仍然能够 在该处理器上运行。

uncapped 分区 CPU 调度

分区激活的时候，会读 取概要文件中物理 CPU“期望处理单元数”的数值，如果可以从 CPU 共享池中获取到设定的 CPU 资源，则以这个数量的物理 CPU 激活；若能获取到得物理 CPU 的资源小于概要文件中“最小处理单元数”数值的设置，则无法激活分区；或若能获取到得物理 CPU 的资源介于“期望处理单元数”和“最小处理单元数”之间，则会以这个数值激活分区。

分区激活以后，系统将会监控 CPU 的利用率，如果每个虚拟 CPU 的利用率都低于 50%，系统将会关闭一些虚拟 CPU，以减少 CPU 的上下文切换。当然，减少后的虚拟 CPU 的数量应不小于物理 CPU 的数量。此时，微分区中物理 CPU 总的利用率超过 50%，那么系统会将关闭的虚拟 CPU 重新打开，以便分区可以获取到额外的物理 CPU 资源。

我们知道，Power7 服务器 CPU 支持四线程，CPU 的第 2，3，4 个线程在 CPU 空闲的时候是不启用的。因此，在已获取的物理 CPU 的第一个线程利用率达 100% 的时候，如果此时 CPU 共享池中有空闲的物理 CPU，系统将会优先启用被关闭的虚拟 CPU，以便获取而外的物理 CPU；如果此时 CPU 共享池中没有可以获取到的物理 CPU，那么系统首先不会启用被关闭的虚拟 CPU，而是使用已获取的物理 CPU 的第 2 个、第 3 个、和第 4 个线程，直到整个物理 CPU 的利用率超过 80%，才会启用新的虚拟 CPU。

如果一个微分区很繁忙，并且该分区已经获取的物理 CPU 的数量已经达到该分区设置的期望获取的虚拟 CPU 的数量，如果条件允许，我们还想给微分区增加物理 CPU 资源的方法是用 DLPAR 增加该分区的虚拟 CPU 的数量，然后该分区会继续获取物理 CPU 资源。

所以说，对于一个 uncapped 分区，它能够自动获取到的最多物理 CPU 资源，是由概要文件中的“期望虚拟处理器数”决定的。

capped 分区 CPU 调度

对于 capped 分区，虚拟 CPU 的调度与 uncapped 是一样的。不一样的是分区自动可以获取到的 最多物理 CPU 的数量是由概要文件中设置的“期望处理单元数”决定的。因为，当微分区以小于“期望处理单元数”的物理 CPU 数量激活以后，即使该分区的 CPU 利用率很高，并且 CPU 共享池中的物理 CPU 很空闲，但是由于概要文件中受限分区的设置，它都无法自动获取额外的 CPU 资源。在这种情况下，为了环境分区的 CPU 紧张的情况，我们可以通过 DLPAR，手工给分区增加物理 CPU 资源，增加后的物理 CPU 数量不能大于分区的“最大处理单元数”。并且增加后的物理 CPU 数量如果超过了虚拟 CPU 的数量，也是不能添加成功的。

例如，我们有一个微分区，分配的物理 CPU 为 3，虚拟 CPU 为 3：

图 4.DLPAR 增加 CPU

接下来，我们将物理 CPU 的数量增加到 4，会看到如下报错：

图 5.DLPAR 增加 CPU

在这种情况下，就需要同时增加虚拟 CPU 和物理 CPU 的数量：

图 6.DLPAR 增加 CPU

可以添加成功。

DLPAR 能够增加到的最大物理 CPU 的数量，是由设置的物理 CPU 的“ 最大处理单元数”决定的。

系统中查看微分区 CPU 相关配置

在微分区中，我们可以使用 lpatsta – i 命令准确地查看分区 CPU 和内存的相关配置信息。

点击查看代码清单

我们也可以通过登陆 HMC 查看对应项的数值。

图 7. 查看服务器 CPU 配置

查看分区的概要文件：

图 8. 查看分区概要文件

所以，针对本案例，通过上面 lpatstat-i 的输出，我们可以得到几个重要的信息；当前分区获取到的物理 CPU 是 1 个，虚拟 CPU 是 6 个，由于开启了 SMT-4，因此系统有 24 个逻辑 CPU，可以认为系统有 24 个 CPU 线程。

 # vmstat 1 

 System configuration: lcpu=24 mem=4096MB ent=1.00

 kthr    memory              page              faults              cpu          
 ----- ----------- ------------------------ ------------ ----------------------- 
 r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa    pc    ec 
 0  0 302870 688838   0   0   0   0    0   0   0    0   0  0  1 99  0  0.01   1.4 
 0  0 302870 688837   0   0   0   0    0   0   0    0   0  0  1 99  0  0.01   1.2 
 0  0 302870 688836   0   0   0   0    0   0   7   57  46  0  1 99  0  0.02   2.0

（微分区）CPU 使用率的监控误区

继续上一小节的例子，目前系统有 24 个逻辑 CPU，我写一个脚本，调用 ncpu 命令，依次发 24 个 cpu 压力，为了使加压平缓，将加压间隔设置为 20 秒：

 # cat  final.sh 

 echo "Begin to Collect the Nmon data "
 cd /weixinyu;nmon -f -s 1 -c 1000000 
 echo "Let's Begin CPU press test after 5 seconds!"
 sleep 5 
 for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
 do 
 echo "Begin The $i*CPU press"
 ./ncpu -p 1& 
 date 
 sleep 20 
 done 
 echo "The CPU press will be moved!"
 ps -e |grep ncpu |awk '{ print $1}' |xargs kill -9  
 echo "Nmon date will be finished after 5 seconds"
 echo "No CPU press now"
 ps -e |grep nmon |awk '{ print $1}' |xargs kill -9 
 echo "This test has been finished, observe the Nmon data under /weixinyu" 
 #

然后，执行这个脚本：

 # sh final.sh 
 Begin to Collect the Nmon data 
 Let's Begin CPU press test after 5 seconds! 
 Begin The 1*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:04:25CDT 2012
 Begin The 2*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:04:45CDT 2012
 Begin The 3*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:05:05CDT 2012
 Begin The 4*CPU press 
 Wed Aug  822:05:25CDT 2012
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Begin The 5*CPU press 
 Wed Aug  822:05:45CDT 2012
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Begin The 6*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:06:05CDT 2012
 Begin The 7*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:06:25CDT 2012
 Begin The 8*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:06:45CDT 2012
 Begin The 9*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:07:05CDT 2012
 Begin The 10*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:07:25CDT 2012
 Begin The 11*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:07:45CDT 2012
 Begin The 12*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:08:05CDT 2012
 Begin The 13*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:08:25CDT 2012
 Begin The 14*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:08:45CDT 2012
 Begin The 15*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:09:05CDT 2012
 Begin The 16*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:09:25CDT 2012
 Begin The 17*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:09:45CDT 2012
 Begin The 18*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:10:05CDT 2012
 Begin The 19*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:10:25CDT 2012
 Begin The 20*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:10:45CDT 2012
 Begin The 21*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:11:06CDT 2012
 Begin The 22*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:11:26CDT 2012
 Begin The 23*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:11:46CDT 2012
 Begin The 24*CPU press 
 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever 
 Wed Aug  822:12:06CDT 2012
 The CPU press will be moved! 
 Nmon date will be finished after 5 seconds 
 No CPU press now 
 This test has been finished, observe the Nmon data under /weixinyu

将收集到的 nmon 信息用 nmon analyzer 进行分许，得出的结果如下：

图 9。查看 Nmon 分析结果

在命令结果的输出中，我们需要关注几个时间点，在 22：05 的时候，系统开始第一个 ncpu 的压力。

从 nmon 结果的另外一个子页，查看 CPU 线程的利用率，基本上符合在 SMT-4 环境下，系统优先使用第一个线程的原则：CPU005、CPU009、CPU013、CPU017、CPU021 的几个线程利用率是最高的线程。

图 10. 查看逻辑 CPU 利用率

查看分区 CPU 运行队列的数量变化，可以看出是平缓增加的，符合脚本中平缓加压的规则：

图 11. 查看 CPU 运行队列

从 nmon 结果中截取几个关键时间点的 CPU 利用率，这样可以很清楚看出 CPU 整体利用率与线程利用率的关系：

表 1. CPU 整体利用率与线程利用率的关系

得出的结论是，对于一个开了 SMT-4 的 CPU，我们压满其第 1 个线程与将 4 个线程都压满，操作看到的整体 CPU 利用率没有太大的变化。

我们还可以得出另外一个结论：压满单个 CPU 对于整体 CPU 利用率的增长，并不是线性关系，与 CPU 数量的比率也不匹配，如下表：

表 2

因此，在多线程应用和开启系统多线程的环境下，我们在监控 CPU 利用率的时候，在衡量系统还能增加多少业务量的时候，不能简单地根据某一条系统命令看到的 CPU 空闲值来衡量。

微分区 CPU 使用率的监控

我们可以通过设置微分区的属性，将其“允许性能信息收集”的选项打开：

图 12. 设置分区属性

打开这个参数以后，我们可以用 lparstat 命令监控到更多的 CPU 利用率信息。

如果我们要监控每个 CPU 线程的利用率，可以使用 mpstat 命令。

如果我们要监控整体 CPU 利用率，可以使用 topas 或者 nmon。

但 是从我个人来见，在这种多线程 CPU 和多线程应用的环境下，我比较倾向于使用 mpstat 来监控每一个 CPU 的利用率。在下面的输出结果中，Proc0、Proc4、Proc8、Proc12、Proc16、Proc20 分别代表该系统的 6 个虚拟 CPU，cpu0-cpu23 则代表 24 个逻辑 CPU（每个虚拟 CPU 有 4 个逻辑 CPU）。

# mpstat -s 1 1System configuration: lcpu=24 ent=1.0 mode=Uncapped
Proc0      Proc4        Proc8
1.08%      99.96%        99.96%      
cpu0   cpu1   cpu2   cpu3   cpu4    cpu5    cpu6    cpu7    cpu8    cpu9    cpu10   cpu11
0.62%  0.16%  0.15%  0.15%  62.14%  12.61%  12.61%  12.61%  62.14%  12.61%  12.61%  12.61%

Proc12      Proc16      Proc20
0.00%        0.00%        0.01%      
cpu12  cpu13  cpu14  cpu15  cpu16  cpu17  cpu18  cpu19  cpu20  cpu21  cpu22  cpu23
0.00%  0.00%  0.00%  0.00%  0.00%  0.00%  0.00%  0.00%  0.00%  0.00%  0.00%  0.01%

通过命令的输出，我们可以看到每一个虚拟 CPU 及其下面 4 个逻辑 CPU 的利用率，这样就比仅从 nmon 来看系统的整体 CPU 利用率要更为细致。

在 性能测试中，对于真实的应用，并不是 CPU 数量越高，CPU 线程数越多，应用的 TPS 就越高。在多线程应用和开启 CPU 多线程的环境下，我们更多地需要考虑到客户应用的线程数、系统 CPU 线程数、应用中负责调度的进程数，充分考虑到 CPU 线程数与应用线程数的配比关系。如果 CPU 线程数过多而应用线程数很少，可能会造成系统调度开销增大，应用性能会下降；如果应用线程数很多而 CPU 线程数不足，又可能造成应用线程调度不开，影响性能。因此，我们有时候需要根据应用的表现来调整 CPU 的数量和 SMT 的设置。

总之，在多线程应用和开启系统多线程的环境下，我们监控 CPU 利用率，需要考虑到客户线程的数量以及 CPU 线程数，然后再结合系统的命令进行查看，才能比较准确地预估服务器还能增加多少应用负载。