性能常识 性能测试之 cpu 篇
2.1 cpu 介绍
CPU 利用率主要依赖于是什么资源在试图存取.内核调度器将负责调度 2 种资源种类:线程 (单一或者多路) 和中断.调度器去定义不同资源的不同优先权.以下列表从优先级高到低排列：
- Interrupts(译注:中断) - 设备通知内核,他们完成一次数据处理的过程.例子,当一块网卡设备递送网络数据包或者一块硬件提供了一次 IO 请求.
- Kernel(System) Processes(译注:内核处理过程) - 所有内核处理过程就是控制优先级别.
- User Processes(译注:用户进程) - 这块涉及” userland”.所有软件程序都运行在这个 user space.这块在内核调度机制中处于低优先级.
从上面,我们可以看出内核是怎样管理不同资源的.还有几个关键内容需要介绍,以下部分就将介绍 context(译注:上下文切换),run queues(译注:运行队列) 以及 utilization(译注:利用率).
2.1.1 上下文切换
多数现代处理器都能够运行一个进程 (单一线程) 或者线程.多路超线程处理器有能力运行多个线程.然而,Linux 内核还是把每个处理器核心的双核心芯片作为独立的处理器.比如,以 Linux 内核的系统在一个双核心处理器上,是报告显示为两个独立的处理器.
一个标准的 Linux 内核可以运行 50 至 50,000 的处理线程.在只有一个 CPU 时,内核将调度并均衡每个进程线程.每个线程都分配一个在处理器中被开销的时间额度.一个线程要么就是获得时间额度或已抢先获得一些具有较高优先级 (比如硬件中断),其中较高优先级的线程将从区域重新放置回处理器的队列中.这种线程的转换关系就是我们提到的上下文切换.
每次内核的上下文切换,资源被用于关闭在 CPU 寄存器中的线程和放置在队列中.系统中越多的上下文切换,在处理器的调度管理下,内核将得到更多的工作.
2.1.2 运行队列
每个 CPU 都维护一个线程的运行队列.理论上,调度器应该不断的运行和执行线程.进程线程不是在 sleep 状态中 (译注:阻塞中和等待 IO 中) 或就是在可运行状态中.如果 CPU 子系统处于高负荷下,那就意味着内核调度将无法及时响应系统请求.导致结果,可运行状态进程拥塞在运行队列里.当运行队列越来越巨大,进程线程将花费更多的时间获取被执行.
比较流行的术语就是” load”,它提供当前运行队列的详细状态.系统 load 就是指在 CPU 队列中有多少数目的线程,以及其中当前有多少进程线程数目被执行的组合.如果一个双核系统执行了 2 个线程,还有 4 个在运行队列中,则 load 应该为 6. top 这个程序里显示的 load averages 是指 1,5,15 分钟以内的 load 情况.
2.1.3 CPU 利用率
CPU 利用率就是定义 CPU 使用的百分比.评估系统最重要的一个度量方式就是 CPU 的利用率.多数性能监控工具关于 CPU 利用率的分类有以下几种:
- User Time(译注:用户进程时间) - 关于在 user space 中被执行进程在 CPU 开销时间百分比.
- System Time(译注:内核线程以及中断时间) - 关于在 kernel space 中线程和中断在 CPU 开销时间百分比.
- Wait IO(译注:IO 请求等待时间) - 所有进程线程被阻塞等待完成一次 IO 请求所占 CPU 开销 idle 的时间百分比.
- Idle(译注:空闲) - 一个完整空闲状态的进程在 CPU 处理器中开销的时间百分比.
2.2 cpu 性能监控
理解运行队列,利用率,上下文切换对怎样 CPU 性能最优化之间的关系.早期提及到,性能是相对于基准线数据的.在一些系统中,通常预期所达到的性能包括：
Run Queues - 每个处理器应该运行队列不超过 1-3 个线程.例子,一个双核处理器应该运行队列不要超过 6 个线程。
CPU Utiliation - 如果一个 CPU 被充分使用,利用率分类之间均衡的比例应该是：
65% - 70% User Time 30% - 35% System Time 0% - 5% Idle Time
- Context Switches - 上下文切换的数目直接关系到 CPU 的使用率,如果 CPU 利用率保持在上述均衡状态时,大量的上下文切换是正常的.
很多 Linux 上的工具可以得到这些状态值,首先就是 vmstat 和 top 这 2 个工具。
2.2.1 vmstat 的使用
vmstat 工具提供了一种低开销的系统性能观察方式.因为 vmstat 本身就是低开销工具,在非常高负荷的服务器上,你需要查看并监控系统的健康情况,在控制窗口还是能够使用 vmstat 输出结果.这个工具运行在 2 种模式下:average 和 sample 模式.sample 模式通过指定间隔时间测量状态值.这个模式对于理解在持续负荷下的性能表现,很有帮助.下面就是
vmstat 运行 1 秒间隔的示例：
# vmstat 1 procs ———–memory———- —swap– —–io—- –system– —-cpu—- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 104300 16800 95328 72200 0 0 5 26 7 14 4 1 95 0 0 0 104300 16800 95328 72200 0 0 0 24 1021 64 1 1 98 0 0 0 104300 16800 95328 72200 0 0 0 0 1009 59 1 1 98 0
2.2.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
根据观察值,我们可以得到以下结论：
- 有大量的中断 (in) 和较少的上下文切换 (cs).这意味着一个单一的进程在产生对硬件设备的请求.
- 进一步显示某单个应用,user time(us) 经常在 85% 或者更多.考虑到较少的上下文切换,这个应用应该还在处理器中被处理.
- 运行队列还在可接受的性能范围内,其中有 2 个地方,是超出了允许限制.
2.2.3 案例学习:超负荷调度
在这个例子中,内核调度中的上下文切换处于饱和
# 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
根据观察值,我们可以得到以下结论：
- 上下文切换数目高于中断数目,说明 kernel 中相当数量的时间都开销在上下文切换线程.
- 大量的上下文切换将导致 CPU 利用率分类不均衡.很明显实际上等待 io 请求的百分比 (wa) 非常高,以及 user time 百分比非常低 (us).
- 因为 CPU 都阻塞在 IO 请求上,所以运行队列里也有相当数目的可运行状态线程在等待执行.
2.2.4. mpstat 工具的使用
如果你的系统运行在多处理器芯片上,你可以使用 mpstat 命令来监控每个独立的芯片.Linux 内核视双核处理器为 2 CPU’s,因此一个双核处理器的双内核就报告有 4 CPU’s 可用.
mpstat 命令给出的 CPU 利用率统计值大致和 vmstat 一致,但是 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
2.2.5. 案例学习: 未充分使用的处理量
在这个例子中,为 4 CPU 核心可用.其中 2 个 CPU 主要处理进程运行 (CPU 0 和 1).第 3 个核心处理所有内核和其他系统功能 (CPU 3).第 4 个核心处于 idle(CPU 2).
使用 top 命令可以看到有 3 个进程差不多完全占用了整个 CPU 核心.
# top -d 1 top - 23:08:53 up 8:34, 3 users, load average: 0.91, 0.37, 0.13 Tasks: 190 total, 4 running, 186 sleeping, 0 stopped, 0 zombie Cpu(s): 75.2% us, 0.2% sy, 0.0% ni, 24.5% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 2074736k total, 448684k used, 1626052k free, 73756k buffers Swap: 4192956k total, 0k used, 4192956k free, 259044k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15957 nobody 25 0 2776 280 224 R 100 20.5 0:25.48 php 15959 mysql 25 0 2256 280 224 R 100 38.2 0:17.78 mysqld 15960 apache 25 0 2416 280 224 R 100 15.7 0:11.20 httpd 15901 root 16 0 2780 1092 800 R 1 0.1 0:01.59 top 1 root 16 0 1780 660 572 S 0 0.0 0:00.64 init # 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
你也可以使用 ps 命令通过查看 PSR 这列,检查哪个进程在占用了哪个 CPU.
# while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep ‘mysqld’; sleep 1; done PID NI PRI %CPU PSR COMMAND 15775 0 15 86.0 3 mysqld PID NI PRI %CPU PSR COMMAND 15775 0 14 94.0 3 mysqld PID NI PRI %CPU PSR COMMAND 15775 0 14 96.6 3 mysqld PID NI PRI %CPU PSR COMMAND 15775 0 14 98.0 3 mysqld PID NI PRI %CPU PSR COMMAND 15775 0 14 98.8 3 mysqld PID NI PRI %CPU PSR COMMAND 15775 0 14 99.3 3 mysqld
2.3. 结论
监控 CPU 性能由以下几个部分组成：
- 检查 system 的运行队列,以及确定不要超出每个处理器 3 个可运行状态线程的限制.
- 确定 CPU 利用率中 user/system 比例维持在 70/30
- 当 CPU 开销更多的时间在 system mode,那就说明已经超负荷并且应该尝试重新调度优先级
- 当 I/O 处理得到增长,CPU 范畴的应用处理将受到影响