vmstat 命令
第一个要使用的工具是 vmstat 命令,该命令可迅速提供关于各种系统资源和与之相关的性能问题的简要信息。
# vmstat 2
kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
1 0 22478 1677 0 0 0 0 0 0 188 1380 157 57 32 0 10
1 0 22506 1609 0 0 0 0 0 0 214 1476 186 48 37 0 16
0 0 22498 1582 0 0 0 0 0 0 248 1470 226 55 36 0 9
2 0 22534 1465 0 0 0 0 0 0 238 903 239 77 23 0 0
2 0 22534 1445 0 0 0 0 0 0 209 1142 205 72 28 0 0
2 0 22534 1426 0 0 0 0 0 0 189 1220 212 74 26 0 0
3 0 22534 1410 0 0 0 0 0 0 255 1704 268 70 30 0 0
2 1 22557 1365 0 0 0 0 0 0 383 977 216 72 28 0 0
2 0 22541 1356 0 0 0 0 0 0 237 1418 209 63 33 0 4
1 0 22524 1350 0 0 0 0 0 0 241 1348 179 52 32 0 16
1 0 22546 1293 0 0 0 0 0 0 217 1473 180 51 35 0 14此输出显示了在一个死循环中将程序引入到一个繁忙的多用户系统中所带来的效果。 头三个报告(已删除摘要)表明系统平衡在 50-55% 的用户、30-35% 的系统和 10-15% 的 I/O 等待处。 当循环程序开始运行,所有可用的 CPU 周期都被耗用。 因为循环程序不进行 I/O,所以它可以占有前面因为 I/O 等待而未用过的所有周期。 更糟的是,这代表当一个有用进程放弃 CPU 时,始终有一个进程准备接管 CPU。 因为循环程序的优先级与所有其他前台进程一样,所以当另一个进程变得可分派时它也没必要一定得放弃 CPU。 该程序运行大约 10 秒钟(五个报告),然后由 vmstat 命令报告的活动恢复到较正常的模式。
最佳利用是让 CPU 在 100% 的时间中工作。 这适用于单用户系统的情况,不需要共享 CPU。 通常,如果us+sy时间低于 90% ,单用户系统不被视为 CPU 受限。 但是,如果us+sy多用户系统上的时间超过 80% ,这些进程可能会花费时间在运行队列中等待。 响应时间和吞吐量会受损害。
要检查 CPU 是否是瓶颈,请考虑四个cpu列和两个列kthrvmstat 报告中的 (内核线程) 列。 可能也值得看faults列:
- cpu
在该时间间隔内使用 CPU 时间的百分比细分。 该cpu列如下所示:
- us
该us列显示在用户方式下耗用的 CPU 时间百分比。 UNIX 进程可以在用户模式或系统(内核)模式下执行。 当在用户方式下时,进程在它自己的应用程序代码中执行,不需要内核资源来进行计算、管理内存或设置变量。
- sy
该sy列详细说明 CPU 在系统方式下执行进程的时间百分比。 这包括内核进程(kproc)和其他需要访问内核资源的进程所消耗的 CPU 资源。 如果一个进程需要内核资源,它必须执行一个系统调用,并由此切换到系统方式从而使该资源可用。 例如,对一个文件的读或写操作需要内核资源来打开文件、寻找特定的位置,以及读或写数据,除非使用内存映射文件。
- 标识
该id列显示在没有暂挂本地磁盘 I/O 的情况下 CPU 处于空闲或等待状态的时间所占的百分比。 如果没有可供执行的线程 (运行队列为空) ,那么系统会分派名为 wait的线程,也称为 空闲 kproc。 在一个 SMP 系统中,每个处理器都有一个 wait 线程可分派。 ps 命令生成的报告 (使用 -k 或 -g 0 选项) 将此报告标识为kproc或wait。如果 ps 报告显示此线程的聚集时间较长,那么这意味着没有其他线程准备好在 CPU 上运行或等待执行时有很长一段时间。 系统因此大部分时间空闲和等待新任务。
- wa
该wa列详细说明 CPU 与暂挂本地磁盘 I/O 和 NFS安装的磁盘 空闲 时间的百分比。 如果在运行 wait 时至少有一个未完成的 I/O 到磁盘,那么时间将分类为等待 I/O。 除非该进程正在使用异步 I/O ,否则对磁盘的 I/O 请求会导致调用进程阻塞 (或休眠) ,直到请求完成为止。 一旦进程的 I/O 请求完成,该进程就放入运行队列中。 如果 I/O 很快完成,该进程可以使用更多的 CPU 时间。
Awa值超过 25% 可能指示磁盘子系统可能未正确均衡,或者可能是磁盘密集型工作负载的结果。
有关更改的信息wa,请参阅 等待 I/O 时间报告。
- us
- kthr
每秒钟在采样时间间隔上对各种队列中的内核线程数求得的平均值。 该kthr列如下所示:
- R
可运行的内核线程平均数,包括正在运行的线程和正在等待 CPU 的线程。 如果这个数字大于 CPU 的数目,至少有一个线程要等待 CPU,等待 CPU 的线程越多,越有可能对性能产生影响。
- 博
每秒 VMM 等待队列中的内核线程平均数。 这包括正在等待文件系统 I/O 的线程,或由于内存装入控制而暂挂的线程。
如果由于内存装入控制而暂挂进程,那么阻塞列 (b) 在 vmstat 报告中,指示线程数而不是运行队列数增加。
- p
对于 vmstat -I,是每秒等待原始设备 I/O 的线程数目。 等待文件系统 I/O 的线程不包含在其中。
- R
- Faults
关于进程控制的信息,如陷阱和中断率。 该faults列如下所示:
- in
在某一时间间隔中观测到的每秒设备中断数。 可以在 使用 vmstat 命令评估磁盘性能中找到其他信息。
- sy
在某一时间间隔中观测到的每秒系统调用次数。 通过明确的系统调用,用户进程可以使用资源。 这些调用指示内核执行调用线程的操作,并在内核和该进程之间交换数据。 因为工作负载和应用程序变化很大,不同的调用执行不同的功能,所以不可能定义每秒钟有多少系统调用才算太多。 但通常情况下,当sy列在单处理器上每秒发出超过 10000 个调用,需要进一步调查 (在 SMP 系统上,每个处理器每秒的调用数为 10000 个)。 一个原因可能是“轮询”子例程,像 select() 子例程。 对于此列,最好有一个基线测量,给出一个正常的计数sy值。
- cs
在某一时间间隔中观测到的每秒钟上下文切换次数。 物理 CPU 资源细分为每个 10 毫秒的逻辑时间片。 假设一个线程被调度运行,它将一直运行直到它的时间片用完、直到被抢先或直到它自愿放弃 CPU 控制权。 当给予另一个线程 CPU 控制权时,必须保存前一个线程的上下文或工作环境,并且必须装入当前线程的上下文。 操作系统有一个很有效的上下文切换过程,所以每次切换并不耗费资源。 上下文切换的任何显着增加,例如,cs比磁盘 I/O 和网络包速率高很多,应该引起进一步的调查。
- in