Linux kernel 性能优化（三）CPU性能监控
要理解CPU的性能，就要懂得解读运行队列，使用率以及上下文切换。正如前文描述，性能是和基准数据相关。然而在任何系统上都有通用的性能期望。这些期望包括：
• 运行队列
• 运行队列
-- 一个处理器上的运行队列应该有少于1-3个线程。也就是说一个双核系统的运行队列上不应该有多于六个线程。
• CPU使用率
– 如果一个CPU被完全使用，那么应该达到以下的平衡
• 65% – 70% User Time
• 30% - 35% System Time
• 0% - 5% Idle Time
• 上下文切换
• 上下文切换
– 上下文切换的总量与CPU占用率直接相关。如果CPU占用率在上述的平衡中，那么大量的上下文切换是可以接受的。Linux下有许多可用的工具用来衡量这些数据。头两个工具就是vmstat & top.
3.1 使用vmstat
vmstat工具提供了一个很好的低开销的监听系统性能的方式。因为vmstat是如此低开销的工具，在高负载的服务器上仍旧可以用它在console下使用来监听系统的健康。这个工具有两种运行模式：平均模式和采样模式。采样模式将会在一个特定的间隔中测量数据，这种模式在持续负载的情况下非常有用。以下vmstat是在一秒的间隔下运行。
输出中相关的域如下所示：
3.3 CPU性能优化
alpha-> vmstat
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
0 0 200560 88796 88612 179036 0 1 1 20 112 20 3 1 1 96
输出中相关的域如下所示：
R：运行队列中的进程数。这些是可运行进程，不过CPU还无法执行他们。
B：被阻塞等待IO请求结束的进程数。
In：中断执行数目。
Cs：当前系统中发生的上下文切换数。
Us：用户CPU占用百分比。
Sys：内核和中断占用百分比。
Wa：所有可运行进程都被IO请求阻塞，所导致的CPU空闲时间。
Id： CPU完全空闲的时间百分比。
3.1.1 案例分析：应用Spike
在接下来这个例子中，一个系统正在经历CPU性能起伏，从完全空闲到完全被占用。
alpha-> vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
4 0 200560 91656 88596 176092 0 0 0 0 103 12 0 0 0 100
0 0 200560 91660 88600 176092 0 0 0 0 104 12 0 0 0 100
0 0 200560 91660 88600 176092 0 0 0 0 103 16 1 0 0 99
0 0 200560 91660 88600 176092 0 0 0 0 103 12 0 0 0 100
0 0 200560 91660 88604 176092 0 0 0 80 108 28 0 0 6 94
0 0 200560 91660 88604 176092 0 0 0 0 103 12 0 0 0 100
1 0 200560 91660 88604 176092 0 0 0 0 103 12 0 0 0 100
1 0 200560 91652 88604 176092 0 0 0 0 113 27 14 3 0 83
1 0 200560 84176 88604 176092 0 0 0 0 104 14 95 5 0 0
2 0 200560 87216 88604 176092 0 0 0 324 137 96 86 9 1 4
2 0 200560 78592 88604 176092 0 0 0 0 104 23 97 3 0 0
2 0 200560 90940 88604 176092 0 0 0 0 149 63 92 8 0 0
2 0 200560 83036 88604 176092 0 0 0 0 104 32 97 3 0 0
2 0 200560 74916 88604 176092 0 0 0 0 103 22 93 7 0 0
2 0 200560 80188 88608 176092 0 0 0 376 130 104 70 30 0 0
3 0 200560 74028 88608 176092 0 0 0 0 103 69 70 30 0 0
2 0 200560 81560 88608 176092 0 0 0 0 219 213 38 62 0 0
1 0 200560 90200 88608 176100 0 0 8 0 153 118 56 31 0 13
0 0 200560 88692 88612 179036 0 0 2940 0 249 249 44 4 24 28
2 0 200560 88708 88612 179036 0 0 0 484 254 94 39 22 1 38
0 0 200560 88708 88612 179036 0 0 0 0 121 22 0 0 0 100
0 0 200560 88708 88612 179036 0 0 0 0 103 12 0 0 0 100
可以根据观察得到以下结论:
•运行队列在高峰时到达了3，几乎要超过阈值。
•用户空间的CPU占用时间几乎要到达90%，接着马上就降下来。
•在这段时间里，上下文切换并没有显著的增加，这个可以说明一个单独的线程应用在段时间里占用了大量的处理器资源。
•这个看起来像是一个应用在一个动作里批处理了所有写磁盘的动作。有一秒，CPU经历了磁盘使用的高峰 (wa = 24%)
3.1.2 案例分析：可持续的CPU占用
下个例子中，整个系统被完全占用了。
下个例子中，整个系统被完全占用了。
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
3 0 206564 15092 80336 176080 0 0 0 0 718 26 81 19 0 0
2 0 206564 14772 80336 176120 0 0 0 0 758 23 96 4 0 0
1 0 206564 14208 80336 176136 0 0 0 0 820 20 96 4 0 0
1 0 206956 13884 79180 175964 0 412 0 2680 1008 80 93 7 0 0
2 0 207348 14448 78800 175576 0 412 0 412 763 70 84 16 0 0
2 0 207348 15756 78800 175424 0 0 0 0 874 25 89 11 0 0
1 0 207348 16368 78800 175596 0 0 0 0 940 24 86 14 0 0
1 0 207348 16600 78800 175604 0 0 0 0 929 27 95 3 0 2
3 0 207348 16976 78548 175876 0 0 0 2508 969 35 93 7 0 0
4 0 207348 16216 78548 175704 0 0 0 0 874 36 93 6 0 1
4 0 207348 16424 78548 175776 0 0 0 0 850 26 77 23 0 0
2 0 207348 17496 78556 175840 0 0 0 0 736 23 83 17 0 0
0 0 207348 17680 78556 175868 0 0 0 0 861 21 91 8 0 1
根据输出有以下观察:
•大量的中断和少量的上下文切换。看起来有一个进程在不断的请求硬件设备。
•有进一步证据表明是某个单独的应用，us时间保持在85%以上。并且只有少量的上下文切换，某个进程一直占用了处理器
•运行队列一直在可接受的性能边缘。甚至有几次超过了可接受的极限。
3.1.3 案例分析：超负荷调度器
再接下来这个例子里，内核调度器不断进行上下文切换以至于饱和。
alpha-> vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
2 1 207740 98476 81344 180972 0 0 2496 0 900 2883 4 12 57 27
0 1 207740 96448 83304 180984 0 0 1968 328 810 2559 8 9 83 0
0 1 207740 94404 85348 180984 0 0 2044 0 829 2879 9 6 78 7
0 1 207740 92576 87176 180984 0 0 1828 0 689 2088 3 9 78 10
2 0 207740 91300 88452 180984 0 0 1276 0 565 2182 7 6 83 4
3 1 207740 90124 89628 180984 0 0 1176 0 551 2219 2 7 91 0
4 2 207740 89240 90512 180984 0 0 880 520 443 907 22 10 67 0
5 3 207740 88056 91680 180984 0 0 1168 0 628 1248 12 11 77 0
4 2 207740 86852 92880 180984 0 0 1200 0 654 1505 6 7 87 0
6 1 207740 85736 93996 180984 0 0 1116 0 526 1512 5 10 85 0
0 1 207740 84844 94888 180984 0 0 892 0 438 1556 6 4 90 0
根据输出可以得出以下结论：
•上下文切换的总量比中断高，意味着内核正在使用可接受的上下文切换的总量。
•上下文切换的总量比中断高，意味着内核正在使用可接受的上下文切换的总量。
•大量的上下文切换导致了一个不健康的CPU使用率负载。这个可以根据IO等待的比例非常高而用户消耗比例非常低推断而得。
•因为CPU被IO等待阻塞住，运行队列开始被填充并且阻塞在IO的线程也变多。
3.2 使用mpstat工具
如果你的系统是多核处理器，即可以用mpstat命令来监控么个单独的核。Linux内核对待一个双核处理器为两个CPU。所以，一个有两个CPU的双核处理器系统将会显示为4个可用CPU。mpstat命令提供和vmstat同样的CPU使用数据，不过mpstat把数据分解到每个独立的处理器上。
# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain) 05/23/2006
05:17:31 PM CPU %user %nice %system %idle intr/s
05:17:32 PM all 0.00 0.00 3.19 96.53 13.27
05:17:32 PM 0 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 1 1.12 0.00 12.73 86.15 13.27
05:17:32 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 3 0.00 0.00 0.00 100.00 0.00
3.2.1 案例分析：未完全利用的处理器负载
在以下案例中，是一个4CPU的处理器。其中有两个CPU紧张地运行（CPU 0 & 1）.第三个CPU处理所有内核和其他系统功能（CPU 3）。第四个处理器一直保持空闲（CPU 2）。
# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain) 05/23/2006
05:17:31 PM CPU %user %nice %system %idle intr/s
05:17:32 PM all 81.52 0.00 18.48 21.17 130.58
05:17:32 PM 0 83.67 0.00 17.35 0.00 115.31
05:17:32 PM 1 80.61 0.00 19.39 0.00 13.27
05:17:32 PM 2 0.00 0.00 16.33 84.66 2.01
05:17:32 PM 3 79.59 0.00 21.43 0.00 0.00
05:17:32 PM CPU %user %nice %system %idle intr/s
05:17:33 PM all 85.86 0.00 14.14 25.00 116.49
05:17:33 PM 0 88.66 0.00 12.37 0.00 116.49
05:17:33 PM 1 80.41 0.00 19.59 0.00 0.00
05:17:33 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:33 PM 3 83.51 0.00 16.49 0.00 0.00
05:17:33 PM CPU %user %nice %system %idle intr/s
05:17:34 PM all 82.74 0.00 17.26 25.00 115.31
05:17:34 PM 0 85.71 0.00 13.27 0.00 115.31
05:17:34 PM 1 78.57 0.00 21.43 0.00 0.00
05:17:34 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:34 PM 3 92.86 0.00 9.18 0.00 0.00
05:17:34 PM CPU %user %nice %system %idle intr/s
05:17:35 PM all 87.50 0.00 12.50 25.00 115.31
05:17:35 PM 0 91.84 0.00 8.16 0.00 114.29
05:17:35 PM 1 90.82 0.00 10.20 0.00 1.02
05:17:35 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:35 PM 3 81.63 0.00 15.31 0.00 0.00
3.3 CPU性能优化
Linux 2.6 内核并没有提供任何给CPU子系统可优化的参数。最好的优化方式就是熟悉正常的CPU使用比率。如果一个CPU被过度使用，用类似top和ps这样的命令来定位出问题的进程，这个进程或许需要被移到另一个系统或者提供给它更多的硬件资源。
下面这个top的输出显示了一个运行StrongMail MTA服务器的CPU使用信息。这个系统处在一个可接受的CPU使用范围内。任何多余的StrongMail MTA将会需要额外的CPU。
下面这个top的输出显示了一个运行StrongMail MTA服务器的CPU使用信息。这个系统处在一个可接受的CPU使用范围内。任何多余的StrongMail MTA将会需要额外的CPU。
# top
Tasks: 102 total, 5 running,
97 sleeping, 0 stopped,m 406m 69m R 89.6 10.0 26:15.64 strongmail-sm
0 zombie
Cpu(s): 51.8% us, 47.8% sy,
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2717 strongma 18 0 799m 703m 68m R 12.6 17.4 29:43.39 strongmail-sm
tp :03.85 strongmail-smtp
2663 strongma 25 0 457m 450m 68m R 36.3 11.1 30:26.71 strongmail-sm
tp
2719 strongma 20 0 408m 406m 69m R 63.6 10.0 26:17.55 strongmail-sm
--More--(74%)4k free, 1543392k m 2428 S 9.1 0.3 2:08.91 strongmail-psto
cached
2702 strongma 15 0 13688 10m 1788 S 0.0 0.2 0:00.97 strongmail-logp