目录
第一篇：虚拟化环境下 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 分区
图 1. 创建共享 CPU 分区
在接下来的页面中，需要设置虚拟 CPU 和物理 CPU 的数量：
图 2. 设置虚拟 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 查看分区配置
图 3. 利用 DLPAR 查看分区配置
此时，系统十分空闲：
系统十分空闲
查看到系统中虚拟 CPU 的数量：
# prtconf |grep "Number Of Processors"
Number Of Processors: 6
查看到由于系统开启了 SMT-4，因此系统中逻辑 CPU 的数量为 24
# vmstat 1 5
System configuration: lcpu=24 mem=4096MB ent=0.60
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 295379 699293 0 0 0 0 0 0 0 0 0 0 1 99 0 0.02 2.6
0 0 295379 699293 0 0 0 0 0 0 0 0 0 0 1 99 0 0.01 2.2
0 0 295379 699293 0 0 0 0 0 0 0 0 0 0 1 99 0 0.01 2.0
0 0 295379 699293 0 0 0 0 0 0 0 0 0 0 1 99 0 0.01 1.9
0 0 295379 699293 0 0 0 0 0 0 40 152 204 0 1 99 0 0.01 2.1
此时 6 个虚拟 CPU 的 24 个逻辑 CPU 并未完全展开 :
# mpstat 1 5
System configuration: lcpu=24 ent=0.6 mode=Uncapped
cpu min maj mpc int cs ics rq mig lpa sysc us sy wa id pc %ec lcs
0 27 0 0 308 280 123 1 4 97 395 10 78 0 12 0.01 1.4 252
1 0 0 0 19 0 0 0 0 - 0 0 4 0 96 0.00 0.4 19
2 0 0 0 19 0 0 0 0 - 0 0 5 0 95 0.00 0.4 19
3 0 0 0 19 0 0 0 0 - 0 0 5 0 95 0.00 0.4 19
4 0 0 0 10 0 0 0 0 - 0 0 6 0 94 0.00 0.0 9
12 0 0 0 4 0 0 0 0 - 0 0 3 0 97 0.00 0.0 3
13 0 0 0 37 0 0 0 0 - 0 0 58 0 42 0.00 0.0 31
16 0 0 0 6 0 0 0 0 - 0 0 8 0 92 0.00 0.0 4
20 0 0 0 12 0 0 0 0 - 0 0 14 0 86 0.00 0.0 10
U - - - - - - - - - - - - 0 99 0.59 99.0 -
ALL 27 0 0 434 280 123 1 4 97 395 0 0 0 100 0.02 2.7 366
--------------------------------------------------------------------------------
cpu min maj mpc int cs ics rq mig lpa sysc us sy wa id pc %ec lcs
0 14 0 0 1104 860 376 4 3 97 1609 8 79 0 13 0.01 1.3 851
1 0 0 0 65 0 0 0 0 - 0 0 6 0 94 0.00 0.4 61
2 0 0 0 61 0 0 0 0 - 0 0 2 0 98 0.00 0.3 61
3 0 0 0 47 0 0 0 0 - 0 0 3 0 97 0.00 0.3 47
4 0 0 0 9 0 0 0 0 - 0 0 75 0 25 0.00 0.0 9
13 0 0 0 116 0 0 0 0 - 0 0 56 0 44 0.00 0.0 98
U - - - - - - - - - - - - 0 98 0.59 97.6 -
ALL 14 0 0 1402 860 376 4 3 97 1609 0 1 0 99 0.01 2.4 1127
--------------------------------------------------------------------------------
如果将 vpm_fold_policy 设置为 4，即关闭该功能，那么 24 个逻辑 CPU 将全部展开：
# schedo -o vpm_fold_policy=4
Setting vpm_fold_policy to 4
# mpstat 1 1
System configuration: lcpu=24 ent=0.6 mode=Uncapped
cpu min maj mpc int cs ics rq mig lpa sysc us sy wa id pc %ec lcs
0 61 0 0 194 72 41 0 1 100 17 3 83 0 14 0.01 0.9 151
1 63 0 0 9 1 1 0 1 100 0 0 19 0 81 0.00 0.3 11
2 63 0 0 10 1 1 0 1 100 0 0 19 0 81 0.00 0.3 12
3 63 0 0 9 1 1 0 1 100 0 0 19 0 81 0.00 0.3 10
4 59 0 0 20 24 13 0 1 92 0 0 46 0 54 0.00 0.2 24
5 62 0 0 9 1 1 0 1 100 0 0 38 0 62 0.00 0.1 10
6 63 0 0 90 2 2 0 1 100 0 0 48 0 52 0.00 0.1 90
7 58 0 0 9 1 1 0 1 100 0 0 40 0 60 0.00 0.1 10
8 63 0 0 19 1 1 0 1 0 0 0 50 0 50 0.00 0.2 21
9 63 0 0 10 1 1 0 1 100 0 0 42 0 58 0.00 0.1 12
10 62 0 0 9 1 1 0 1 100 0 0 46 0 54 0.00 0.1 11
11 61 0 0 9 1 1 0 1 100 0 0 46 0 54 0.00 0.1 11
12 64 0 0 10 1 1 0 1 100 0 0 42 0 58 0.00 0.1 12
13 45 0 0 25 1 1 0 1 100 0 0 51 0 49 0.00 0.1 24
14 63 0 0 9 1 1 0 1 100 0 0 45 0 55 0.00 0.1 10
15 63 0 0 9 1 1 0 1 0 0 0 48 0 52 0.00 0.1 10
16 62 0 0 15 6 4 0 3 75 17 1 48 0 51 0.00 0.1 18
17 61 0 0 9 1 1 0 1 100 0 0 38 0 62 0.00 0.1 11
18 64 0 0 9 1 1 0 1 100 0 0 42 0 58 0.00 0.1 11
19 59 0 0 10 1 1 0 1 100 0 0 41 0 59 0.00 0.1 12
20 60 0 0 13 102 52 0 1 98 101 19 58 0 23 0.00 0.4 65
21 62 0 0 9 1 1 0 1 0 0 0 31 0 69 0.00 0.2 10
22 61 0 0 10 1 1 0 1 100 0 0 30 0 70 0.00 0.2 12
23 64 0 0 9 1 1 0 1 100 0 0 30 0 70 0.00 0.2 10
U - - - - - - - - - - - - 0 95 0.57 95.4 -
ALL 1469 0 0 534 225 131 0 26 96 135 0 2 0 98 0.03 5.0 578
在系统中，还有一个内核参数：vpm_xvcpus。它的作用是控制当微分区 CPU 不足的时候，系统可以自动启动的微分区的数量。如果将这个值设置为 -1，则表示关闭此功能；若设置为 0，表示启用了折叠功能 (Processor Folding) 。这意味着虚拟处理器正接受管理，分区启用了 CPU 折叠功能。默认数值设置为 0，表示分区可以启用其关闭的虚拟 CPU；如果 vpm_xvcpus 数值设置大于 1，则表示系统不仅可以启用其关闭的虚拟 CPU，还可以启动额外的虚拟 CPU，前提是分区的虚拟 CPU 总数不大于分区概要文件最大虚拟 CPU 数量的设置。
atsnfs[/]#schedo -h vpm_xvcpus
Help for tunable vpm_xvcpus:
Purpose:
Setting this tunable to a value greater than -1 will enable the scheduler
to enable and disable virtual processors based on the partition's CPU utilization.
Values:
Default: 0
Range: -1 - 2147483647
Type: Dynamic
Unit: processors
Tuning:
The value specified signifies the number of virtual processors to enable in addition
to the virtual processors required to satisfy the workload.
分区需要的虚拟 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
图 4.DLPAR 增加 CPU
接下来，我们将物理 CPU 的数量增加到 4，会看到如下报错：
图 5.DLPAR 增加 CPU
图 5.DLPAR 增加 CPU
在这种情况下，就需要同时增加虚拟 CPU 和物理 CPU 的数量：
图 6.DLPAR 增加 CPU
图 6.DLPAR 增加 CPU
可以添加成功。
DLPAR 能够增加到的最大物理 CPU 的数量，是由设置的物理 CPU 的“ 最大处理单元数”决定的。
系统中查看微分区 CPU 相关配置
在微分区中，我们可以使用 lpatsta – i 命令准确地查看分区 CPU 和内存的相关配置信息。# lparstat -i
Type : Shared-SMT-4 表示分区为共享 CPU 分区，开启了 SMT-4.
Mode : Uncapped 表示本分区为 uncapped 分区
Entitled Capacity : 1.00 表示本分区目前获取到的物理 CPU 的数量
Online Virtual CPUs : 6 表示本分区目前的虚拟 CPU 数量
Maximum Virtual CPUs : 8 表示概要文件设置的分区最大虚拟 CPU 的数量
Minimum Virtual CPUs : 1 表示概要文件设置的分区最小虚拟 CPU 的数量
Variable Capacity Weight : 255 表示分区的 weight 数值，255 为最高值
Minimum Capacity : 0.10 表示概要文件设置的分区最小物理 CPU 的数量
Maximum Capacity : 1.00 表示概要文件设置的分区最大物理 CPU 的数量
Capacity Increment : 0.01 表示物理 CPU 的数量的增量
Maximum Physical CPUs in system : 8 表示本物理服务器中物理 CPU 的数量
Active Physical CPUs in system : 8 表示本物理服务器中活动的物理 CPU 的数量
Active CPUs in Pool : 6 表示 CPU 共享池可以分配给本分区的最多物理 CPU 的数量
Shared Physical CPUs in system : 6 表示所有共享 CPU 分区使用的物理 CPU 的数量我们也可以通过登陆 HMC 查看对应项的数值。
图 7. 查看服务器 CPU 配置
图 7. 查看服务器 CPU 配置
查看分区的概要文件：
图 8. 查看分区概要文件
图 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 分析结果
图 9。查看 Nmon 分析结果
在命令结果的输出中，我们需要关注几个时间点，在 22：05 的时候，系统开始第一个 ncpu 的压力。
从 nmon 结果的另外一个子页，查看 CPU 线程的利用率，基本上符合在 SMT-4 环境下，系统优先使用第一个线程的原则：CPU005、CPU009、CPU013、CPU017、CPU021 的几个线程利用率是最高的线程。
图 10. 查看逻辑 CPU 利用率
图 10. 查看逻辑 CPU 利用率
查看分区 CPU 运行队列的数量变化，可以看出是平缓增加的，符合脚本中平缓加压的规则：
图 11. 查看 CPU 运行队列
图 11. 查看 CPU 运行队列
从 nmon 结果中截取几个关键时间点的 CPU 利用率，这样可以很清楚看出 CPU 整体利用率与线程利用率的关系：
表 1. CPU 整体利用率与线程利用率的关系
Time User% Sys% Wait% Idle% CPU% Virtual CPU
22:04:25 61.7 0.2 0 38 61.9 1st
22:04:45 62.2 0.2 0 37.6 62.4
22:05:05 62.3 0.1 0 37.5 62.4
22:05:25 63.8 0.1 0 36.1 63.9
22:05:45 68.5 0.1 0 31.4 68.6 2nd
22:06:05 74.3 0.1 0 25.6 74.4
22:06:25 78.1 0.1 0 21.8 78.2
22:06:45 84.5 0.1 0 15.4 84.6
22:07:05 88.2 0.1 0 11.7 88.3 3rd
22:07:25 88.1 0.1 0 11.8 88.2
22:07:45 84.7 0.1 0 15.2 84.8
22:08:05 85.4 0.1 0 14.5 85.5
22:08:25 83.7 0.1 0 16.3 83.8 4th
22:08:45 91.3 0.1 0 8.6 91.4
22:09:05 88 0.1 0 11.9 88.1
22:09:25 92.3 0.1 0 7.6 92.4
22:09:45 92.3 0.1 0 7.7 92.4 5th
22:10:05 91.9 0.5 0 7.6 92.4
22:10:25 94 0.1 0 6 94.1
22:10:45 96 0.1 0 4 96.1
22:11:05 98 0.1 0 2 98.1 6th
22:11:25 99.9 0.1 0 0 100
22:11:45 99.9 0.1 0 0 100
22:12:05 99.9 0.1 0 0 100
得出的结论是，对于一个开了 SMT-4 的 CPU，我们压满其第 1 个线程与将 4 个线程都压满，操作看到的整体 CPU 利用率没有太大的变化。
我们还可以得出另外一个结论：压满单个 CPU 对于整体 CPU 利用率的增长，并不是线性关系，与 CPU 数量的比率也不匹配，如下表：
表 2
测试场景中系统整体 CPU 利用率 按照 CPU 数量比计算的理论 CPU 利用率
压满第 1 个 CPU，系统整体 CPU 利用率大约为：63% 1/6 即 17%
压满第 2 个 CPU，系统整体 CPU 利用率大约为：84% 2/6 即 33.3%
压满第 3 个 CPU，系统整体 CPU 利用率大约为：85% 3/6 即 50%
压满第 4 个 CPU，系统整体 CPU 利用率大约为：92% 4/6 即 66.7%
压满第 5 个 CPU，系统整体 CPU 利用率大约为：96% 5/6 即 83.3%
压满第 6 个 CPU，系统整体 CPU 利用率大约为：100%
因此，在多线程应用和开启系统多线程的环境下，我们在监控 CPU 利用率的时候，在衡量系统还能增加多少业务量的时候，不能简单地根据某一条系统命令看到的 CPU 空闲值来衡量。
微分区 CPU 使用率的监控
我们可以通过设置微分区的属性，将其“允许性能信息收集”的选项打开：
图 12. 设置分区属性
图 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 1
System 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 线程数，然后再结合系统的命令进行查看，才能比较准确地预估服务器还能增加多少应用负载。
虚拟CPU、物理CPU、逻辑CPU
查看到系统中虚拟 CPU 的数量：
# prtconf |grep "Number Of Processors"
Number Of Processors: 6查看到由于系统开启了 SMT-4，因此系统中逻辑 CPU 的数量为 24
# vmstat 1 5
System configuration: lcpu=24 mem=4096MB ent=0.60此时 6 个虚拟 CPU 的 24 个逻辑 CPU 并未完全展开（“处理器折叠”功能） :
# mpstat 1 5
System configuration: lcpu=24 ent=0.6 mode=Uncapped
第二篇 性能指标之资源指标 CPU利用率的性能分析
本章介绍如何在非虚拟化环境以及虚拟化环境下准确的读取CPU利用率指标，同时介绍CPU利用率的细分User%、Sys%、Wait%、Idle%各自的含义，以及如何利用它们协助分析性能问题。
总利用率
CPU利用率=用户态CPU%+系统态CPU%
1.获取来源
（1）Dedicated模式
Nmon CPU_ALL Sheet：CPU%
命令行topas：usr%+sys%
（2）Sharing模式
若physical CPU没有超过EC，则采集EC利用率
当Physical CPU<=EC时，EC利用率=（EC_User% + EC_Sys%）/EC值。
Nmon CPU_ALL Sheet：CPU%
或Nmon LPAR Sheet：EC_User% + EC_Sys%
若physical CPU超过EC：
此时若按照EC利用率统计，则CPU利用率很可能超过了100%，出具的测试结果、测试报告容易造成误解。
此时若按照physical CPU利用率（使用的CPU/physical CPU）统计，分母physical CPU是动态的，因此利用率不具有参考价值。
如果一定要统计CPU利用率，可按照VP利用率统计，VP利用率= VP_User% + VP_Sys%。但需要假设CPU物理Core的个数为VP个数。举例说明：
假设EC=2，VP=8，EC利用率为200%，VP利用率为50%。在测试报告中描述CPU利用率为50%（CPU为8核，其中EC为2C，借用为借用资源池）。
2.最佳实践
交易类测试通常在CPU利用率在70%左右，出具系统能够支撑的最大吞吐量的性能指标。不宜在CPU过高的情况给出性能数据，生产环境CPU 70%会产生CPU报警。并且，CPU过满的情况下，各类性能数据会产生变形。不宜在CPU过低的情况给出性能数据，CPU过低的情况下，操作系统和系统软件本身对CPU的消耗占比比较大，若此时统计均摊到每笔业务上的CPU消耗，不太准确。
对于交易类应用，CPU利用率与业务压力（吞吐量）应成近似线性的比例关系。若CPU利用率不能随着吞吐量的增加而增加（如：CPU利用率不能达到70%，最多只能达到30%），需从应用、系统软件、虚拟化配置等方面进行调优。例如：1）应用并发线程数量是否过少，2）消息中间件的队列管理器数量过少、传输通道过少、本地队列过少，3）虚拟化参数配置中若VP与EC的比值越大，Hypervisor层面的系统调度开销越大，操作系统获得的CPU时间片越少，CPU利用率无法随着吞吐量的增长而增长，响应时间也会延长。
3.CPU利用率观察取值方法举例
在压力测试过程中随时通过topas命令可以查看CPU的利用率，若没有达到预期的利用率，说明这次测试的压力（吞吐量）没有达到预期，需要马上分析原因，必要时停止测试，以避免无谓的时间浪费。
同时也可以观察Physical CPU是否已经超过EC。若超过了，说明当前分配的EC值过低，此时可考虑联系系统管理员分配更大的EC，以保证能够出具可靠的性能数据（借用资源池的CPU，没有EC保障下的CPU性能好）。
Entc指的是Physical CPU除以EC的比值。如上图，Entc=199.7%，即此时获得的Physical CPU是EC的约2倍。而此时Physical CPU的值为Physc=1.00，因此可以直接推测EC=0.5。
Topas中的user%和kern%与“Nmon CPU_ALL Sheet“中的user%、sys%类似，它们的和不会超过100%。因此读数时要注意实际获得了多少Physical CPU。
下面场景中，CPU参数设置如下
Entitled Capacity（EC）=0.8，VP=2，capped=0。
红色的线是EC能力。蓝色的线是运行时获得的physical CPU的个数，相当于获得CPU core的个数。
我们发现，蓝色的线已经跑到了红线上方。说明运行时获得的physical CPU超过了标称能力，向CPU资源池进行了借用。
此时CPU_ALL的界面中显示的CPU总利用率如图
取某个时间点的CPU_ALL sheet中的CPU数据，15:25:19这个时刻，CPU利用率为60.7%
取LPAR sheet中的CPU数据（隐去不必要的数据）
按理说CPU利用率=User%+Sys%。但60.7%这个数，即不等于EC_User%+EC_Sys%，也不等于VP_User%+VP_Sys%。
因为此时physical CPU>EC, 因此CPU_ALL中显示的CPU%=使用的CPU/Physical CPU。
以上述数据为例
以EC计算：EC=0.8，EC_User%+EC_Sys% = 87.97%，LPAR相当于使用了0.8 x 0.8797 = 0.70376 个CPU Core
以VP计算：VP=2，VP_User%+VP_Sys%=35.19%，LPAR相当于使用了2 x 0.3519 = 0.7038个CPU Core
以Physical CPU计算：Physical CPU=1.161，CPU%=60.7%，LPAR相当于使用了1.161 x 0.607= 0.704727个CPU Core
三种算法得到相同的结果，说明没有哪个数据是错误的，但由于Physical CPU是波动的，因此CPU_ALL中的CPU%的分母是波动的，此时CPU_ALL sheet中的CPU%不具有统计价值。
Physical CPU>EC的场景，可以采用VP利用率来充当CPU利用率。测试报告中可以描述为CPU利用率35.19%（CPU为2核，其中EC为0.8C，借用资源池1.2C）。
User%
CPU总利用率由用户态CPU利用率和系统态CPU利用率组成。
1.获取来源
Nmon CPU_ALL Sheet：user%
命令行topas：user%
2.最佳实践
对于应用软件在压力测试状态下通常用户态的CPU占比比较高，而系统态占比比较低。用户态可以保护底层硬件资源不直接被程序访问，减少系统crash，所以一般的应用程序跑在用户态的CPU占比大。
Sys%
1.获取来源
Nmon CPU_ALL Sheet：sys%
命令行topas：kern%
2.最佳实践
如果系统态占比比较大，一般有以下几类原因：
（1）为了追求效率，减少用户态到系统态的转换，把用户态的function改到系统态，例如：一些驱动程序，以显卡驱动最为常见
（2）系统有IO问题
（3）应用设计问题
3.举例
通常情况，压力测试下，用户态（蓝色）和系统态（红色）的CPU图形如下：
系统态偏高如下
这种情况下，如何查看是什么进程、什么库文件、什么函数占用的系统态CPU，后续章节专题介绍。
Wait%
Wait%在不同的场景下含义不同。在CPU的4个细分类型中，Wait%是指CPU等待IO的时间占总时间的百分比。如果在CPU sys态（或kernel态）中的wait%则与此处的wait%含义不同。
1.获取来源
获取来源与Usr%类似。
2.最佳实践
Wait%虽然不会统计进CPU总利用率，但仍然是系统CPU性能指标中偶尔关注的指标。
之所以wait%不会统计进CPU总利用率，因为wait%和idle%比较类似，都是CPU闲置状态，只不过一个是等IO，一个是等新的任务。
但如果wait%过大，说明CPU等IO的时间长，系统的处理效率可能比较差。但有时wait%偏高也不构成性能问题，例如，当系统任务较少时，CPU处理一个任务，处理过程中需要等IO，此时就体现在wait%上面；当继续增加压力，CPU接收到新的任务，CPU就不会干等下去，而是去忙着处理别的任务，此时wait%就被压缩了。
Idle%
CPU闲置状态即为idle%。
有人把Idle理解为CPU没有任务时的一个占位进程把CPU占满，这个理解是错误的。在这个进程里出现的CPU占用数值并不是真正的占用而是指CPU的空闲率
Idle%越大CPU的耗电越少，BTW，一台计算机的功耗不是恒定的，影响功耗的因素较多，但最主要的因素是CPU闲置还是运行，但尽管如此，Power服务器CPU闲置时仅比跑满状态省电10%左右，后续可以开个章节专门介绍如何测试功耗。
1.获取来源
获取来源与Usr%类似。
性能指标之资源指标 CPU配置参数对性能的影响性能指标之资源指标 CPU亲和性原理介绍及如何量化读数性能指标之资源指标 CPU亲和性调整优化性能指标之资源指标 如何精确计算每笔交易消耗的CPU
关于文中的一些概念，要参考一下基本文档：
2、理解微分区
3、
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
