Linux System and Performance Monitoring
Darren Hoch
翻译：李彦荣
如有错误，多多指正。
--------------------------------------------------------------------------------------------------------
1. 性能监控介绍
性能优化是找出系统的瓶颈并优化操作系统来消除这些瓶颈的过程。许多系统管理员认为性能优化可以通过阅读cook book，设置一些内核参数就可以简单解决，但事实并非如此。性能优化是实现各个子系统之间性能平衡。这些子系统包括
- CPU
- 内存
- I/O
- 网络
这些子系统是高度相互依赖的。其中任何一个子系统的高负载都很容易导致其他子系统出现问题。比如
- 大量的页面调入I/O请求会使内存队列堵塞
- 全负荷的网卡会使CPU繁忙
- 维护闲置内存队列会使CPU繁忙
- 大量的内存写入硬盘的请求会使CPU和I/O通道繁忙
为了做修改来优化系统，必须找到出现瓶颈的地方。有时候某个子系统看似出现了问题，其实有可能是其他子系统的超负载造成的。
1.1 确定应用类型
为了知道从何处着手优化瓶颈，第一要点是理解要分析的系统的特点。一般系统的应用程序堆栈分为两种类型:
- I/O约束的。I/O约束的应用需要大量使用内存和其他存储设备。原因是I/O约束的应用处理大量的数据（在内存中），但不需要太多的CPU和网络资源（除非是使用网络上的存储设备）。I/O约束的应用使用CPU来处理I/O请求，然后一般会进入休眠状态。数据库类型的应用一般都是I/O约束的。
- CPU约束的。CPU约束的应用需要使用大量的CPU，来批处理或者数学计算。大容量的网站服务器，邮件服务器和其他类型的服务器一般都是CPU约束的。
1.2 确定统计基准
系统利用效率取决于管理员的经验和系统的规格。确认系统是否有性能问题的唯一途径是了解系统应该优化成什么效果,哪些性能是应该实现的以及定量的参考量是什么。这就需要确立一个参考基准。这个基准统计应当是系统性能可承受的,这样才能与后来实现的性能做比较。
下面这个例子中,比较了系统的一个基准统计快照与高负荷时的快照
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
1 0 138592 17932 126272 214244 0 0 1 18 109 19 2 1 1 96
0 0 138592 17932 126272 214244 0 0 0 0 105 46 0 1 0 99
0 0 138592 17932 126272 214244 0 0 0 0 198 62 40 14 0 45
0 0 138592 17932 126272 214244 0 0 0 0 117 49 0 0 0 100
0 0 138592 17924 126272 214244 0 0 0 176 220 938 3 4 13 80
0 0 138592 17924 126272 214244 0 0 0 0 358 1522 8 17 0 75
1 0 138592 17924 126272 214244 0 0 0 0 368 1447 4 24 0 72
0 0 138592 17924 126272 214244 0 0 0 0 352 1277 9 12 0 79
# 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 0 145940 17752 118600 215592 0 1 1 18 109 19 2 1 1 96
2 0 145940 15856 118604 215652 0 0 0 468 789 108 86 14 0 0
3 0 146208 13884 118600 214640 0 360 0 360 498 71 91 9 0 0
2 0 146388 13764 118600 213788 0 340 0 340 672 41 87 13 0 0
2 0 147092 13788 118600 212452 0 740 0 1324 620 61 92 8 0 0
2 0 147360 13848 118600 211580 0 720 0 720 690 41 96 4 0 0
2 0 147912 13744 118192 210592 0 720 0 720 605 44 95 5 0 0
2 0 148452 13900 118192 209260 0 372 0 372 639 45 81 19 0 0
2 0 149132 13692 117824 208412 0 372 0 372 457 47 90 10 0 0
比较一下最后一列的数字,其代表了CPU的空闲时间比,我们可以看到,在基准统计下,CPU的空闲时间占70%-90%。在第二次输出中,系统百分之百运行而没有空闲。由此我们可以确定系统的CPU是否被充分利用。
2. 安装监控工具
大多数的类Unix系统都带有一系列标准的监控命令。这些监控命令起初就已经是类Unix系统的一部分。Linux也以基本安装或者插件的形式提供这些命令。总之,大多数的发布版本都有这些命令的安装包。当然有很多开源或者第三方的监控工具,本文只讨论Linux发布中带有的监控工具。
本文讨论如何用下面的工具来监控系统性能:
工具 描述 基本安装 软件仓库
vmstat 各种目的的监控监测工具 有 有
mpstat 每个CPU的统计 没有 有
sar 各种目的的性能监控工具 没有 有
iostat 磁盘统计 没有 有
netstat 网络统计 有 有
dststat 监控统计合辑 没有 大多数的发布
iptraf 流量检测 没有 有
netperf 网络带宽工具 没有 某些发布
ethtool 以太网络配置报告 有 有
iperf 网络带宽工具 没有 有
tcptrace 数据包分析工具 没有 有
3. CPU介绍
CPU的利用率很大程度上决定于什么样的资源在使用它。内核有一个调度器专门负责两种资源: (单或多)线程和中断。调度器给不同的资源指定不同的优先
级。下面的列表按优先级从高到低的顺序排列,
• 中断——设备通知内核完成了处理,例如网卡传送一个数据包或者硬盘完成一次I/O请求。
• 内核进程——所有的内核进程都具有这个等级的优先级。
• 用户进程——这块通常称为“用户区”。所有的应用软件有在用户块执行。在内核调度机制中这块具有最低的优先级。
为了了解内核如何管理这些资源,需要介绍一些关键的概念。下面的章节介绍了上下文切换、运行队列和CPU利用率。
3.1 上下文切换
大多数现代的处理器每次只能执行一个进程或线程。n路的超线程处理器同时可以运行n个线程。但是Linux内核仍旧把双核中每个处理器视为独立的。例如, 对于系统中双核处理器, Linux内核报道为两个独立的处理器。
标准的Linux内核可以运行50-5000个线程。对于单个CPU,内核必须调度和平衡这些线程。每个线程都被分配了一定的处理器时间单元。当线程完成了所分配的时间单元或者被一些更高优先级的线程或中断(如硬件中断)抢断时,更高优先级的线程送到处理器上执行而这个线程就被送回到运行队列。这种线程的切换就称为上下文切换。
内核每执行一次上下文切换,额外的资源用来将线程从CPU寄存器中移动到运行队列中。系统中越多的上下文切换,意味着内核需要做更多额外的工作来管理线程调度。
3.2 运行队列
每个CPU都维护着一个线程的运行队列。在理想状态下,每个调度器都在运行线程。线程的状态是休眠(被抢断或者等待I/O)或者运行。如果CPU高度负载, 调度器有可能无法及时响应系统需求。结果导致可运行的线程占满了运行队列,运行队列越庞大,线程执行所需的等待时间就越长。
一个常用的词汇“负载”就用来描述运行队列的状况。系统的负载就是目前正在执行的线程数量和运行队列中线程数量的总和。比如在一个双核的系统上,2个线程正在执行,4个线程在运行队列中,那么系统负载就是6。top命令显示的是1、10、15分钟内系统的平均负载。
3.3 CPU利用率
CPU利用率定义为CPU使用的百分比,是衡量系统的一个重要指标。大多数的性能监测工具把CPU利用率分为以下几类
• 用户时间——CPU执行用户区的线程所花费的时间百分比。
• 系统时间——CPU执行内核线程和中断所花费的时间百分比。
• IO等待时间——所有线程被阻塞,等待I/O请求的完成。此时CPU处于空闲状态的时间百分比。
• 空闲时间——CPU处于完全空闲状态的时间百分比。
4. CPU性能监控
确定CPU运行的性能有多好涉及到理解运行队列、CPU利用率和上下文切换。前面已经提到,性能都是相对于具体的统计基准而言的。但是在任何系统上,仍有一些通用的系能预期,这包括
• 运行队列——每个处理器的运行队列不应多于1-3个。例如一个双核处理器的运行队列不应当多于6个进程。
• CPU利用率——如果CPU充分利用,应该达到一下的平衡比例
– 65-70%的用户时间
– 30-35%的系统时间
– 0-5%的空闲时间
• 上下文切换——上下文切换的数量直接决定了CPU的利用率。如果CPU利用率保持在上述的平衡比列,那么大量的上下文切换是正常的。
Linux上有很多工具来获得这些统计。首先介绍的两个工具是vmstat和top。