此文谈到的很多东西都值得我在性能测试改进方面参考，特此摘录，看来在读源码时需要对page和cpu调度的策略予以特别关注。现在最希望的就是能看到一些国外的性能监控解决方案。

　　ps：刚刚发现设置了<FONT>标签后会覆盖掉<DIV>的样式，bug，好大的bug。

　　处理单元是系统中最快的组件之一。在某一时间对单个程序来说保持 100% 的 CPU 占用率（也就是说，空闲 0%，等待 0%）超过几秒钟是相对少见的。甚至在重负载的多用户系统中，偶尔会出现一些 10 毫秒（ms）的时间段，在其结束时所有线程处于等待状态。如果监视器长时间地显示 CPU 占用率为 100%，则很有可能是某个程序陷入了死循环。即使程序“仅仅”是占用较多资源而不是崩溃了，也需要将它识别出来并进行处理。

r-->在运行队列中等待的进程数
b-->在等待io的进程数
w-->可以进入运行队列但被替换的进程
memoy
swap-->现时可用的交换内存（k表示）
free-->空闲的内存（k表示）
pages
re－－》回收的页面
mf－－》非严重错误的页面
pi－－》进入页面数（k表示）
po－－》出页面数（k表示）
fr－－》空余的页面数（k表示）
de－－》提前读入的页面中的未命中数
sr－－》通过时钟算法扫描的页面
disk 显示每秒的磁盘操作。 s表示scsi盘，0表示盘号
fault 显示每秒的中断数
in－－》设备中断
sy－－》系统中断
cy－－》cpu交换
cpu 表示cpu的使用状态
cs－－》用户进程使用的时间
sy－－》系统进程使用的时间
id－－》cpu空闲的时间
如果 r经常大于 4 ，且id经常少于40，表示cpu的负荷很重。
如果pi，po 长期不等于0，表示内存不足。
如果disk 经常不等于0， 且在 b中的队列 大于3， 表示 io性能不好。

vmstat 命令（CPU）

第一个要使用的工具是 vmstat 命令，该命令可迅速提供关于各种系统资源和与之相关的性能问题的简要信息。vmstat 命令报告关于内核线程的统计信息，包括处于运行和等待队列中的、内存中的、页面调度中的、磁盘中的、中断、系统调用、上下文切换和 CPU 活动的内核线程。所报告的 CPU 活动是用户方式、系统方式、空闲时间和等待磁盘 I/O 的百分比细目分类。

作为一个 CPU 监视器，vmstat 命令优于 iostat 命令，因为 vmstat 命令是滚动的，使得它的每报告一行的输出更容易扫描，并且如果有很多磁盘连接到系统中，由此所涉及的开销更少。下面的示例可以帮助您识别一个程序失控时或 CPU 过度密集以至于不能在一个多用户环境中运行时的情况。

# 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 是否是瓶颈，考虑 vmstat 报告中的四个 cpu 列和两个 kthr（内核线程）列。查看故障列也是值得的：

• cpu

  在该时间间隔内使用 CPU 时间的百分比细分。cpu 列如下：

  • us

    us 列显示了用户方式下所花费 CPU 时间的百分比。一个 UNIX 进程可以在用户方式下执行，也可以在系统（内核）方式下执行。当在用户方式下时，进程在它自己的应用程序代码中执行，不需要内核资源来进行计算、管理内存或设置变量。

  • sy

    sy 列详述了 CPU 在系统方式下执行一个进程所花时间的百分比。这包括内核进程（kprocs）和其它需要访问内核资源的进程所消耗的 CPU 资源。如果一个进程需要内核资源，它必须执行一个系统调用，并由此切换到系统方式从而使该资源可用。例如，对一个文件的读或写操作需要内核资源来打开文件、寻找特定的位置，以及读或写数据，除非使用内存映射文件。

  • id

    id 列显示了没有未决本地磁盘 I/O 时 CPU 空闲或等待的时间百分比。如果没有线程可以执行（运行队列为空），系统分派一个叫做 wait 的线程，也称为 idle kproc。在一个 SMP 系统中，每个处理器都有一个 wait 线程可分派。由 ps 命令（带有 -k 或 -g 0选项）生成的报告将它确定为 kproc 或 wait。如果 ps 报告显示这个线程的总计时间较高，这表明存在重要的时间段，其中没有其它线程准备在 CPU 上运行或等待执行。系统因此大部分时间空闲和等待新任务。

  • wa

    wa 列详细显示了暂挂本地磁盘 I/O 和 NFS 加载的磁盘的 CPU 空闲百分比。如果在 wait 运行时至少有一个未完成的磁盘 I/O，该时间就归为 I/O 等待时间。除非进程使用异常 I/O，否则对磁盘的 I/O 请求会导致调用的进程阻塞（或睡眠），直到请求完成为止。一旦进程的 I/O 请求完成，该进程就放入运行队列中。如果 I/O 很快完成，该进程可以使用更多的 CPU 时间。

    超过 25% 的 wa 的值可以表示磁盘子系统可能没有被正确平衡，或者这也可能是磁盘密集工作负载的结果。

• kthr

  每秒钟在采样间隔时间上对各种队列中的内核线程数求得的平均值。kthr 列如下：

  • r

    可运行的内核线程平均数，包括正在运行的线程和正在等待 CPU 的线程。如果这个数字大于 CPU 的数目，至少有一个线程要等待 CPU，等待 CPU 的线程越多，越有可能对性能产生影响。

  • b

    每秒 VMM 等待队列中的内核线程平均数。这包括正在等待文件系统 I/O 的线程，或由于内存装入控制而暂挂的线程。

    如果进程由于内存装入控制而暂挂，在 vmstat 报告中的阻塞列（b）表明线程数目增加，而不是运行队列数目增加。

  • p

    对于 vmstat -I，是每秒等待原始设备 I/O 的线程数目。等待文件系统 I/O的线程不包括在这里。

• 故障

  关于进程控制的信息，如陷阱和中断率。故障列如下：

  • in

    在某一时间间隔中观测到的每秒设备中断数。

  • sy

    在某一时间间隔中观测到的每秒系统调用次数。通过明确的系统调用，用户进程可以使用资源。这些调用指示内核执行调用线程的操作，并在内核和该进程之间交换数据。因为工作负载和应用程序变化很大，不同的调用执行不同的功能，所以不可能定义每秒钟有多少系统调用才算太多。但是通常来讲，在一个单处理器系统上当 sy 列增大到超过每秒钟 10000 个调用时，则要求进行进一步调查（在一个 SMP 系统上，这个数字为每个处理器每秒钟 10000 个调用）。一个原因可能是“轮询”子例程，像 select() 子例程。对这一列，建议进行一个基准评估，给出正常 sy 值的计数。

  • cs

    在某一时间间隔中观测到的每秒钟上下文切换次数。物理 CPU 资源细分为每个 10 毫秒的逻辑时间片。假设一个线程被调度运行，它将一直运行直到它的时间片用完、直到被抢先或直到它自愿放弃 CPU 控制权。当给予另一个线程 CPU 控制权时，必须保存前一个线程的上下文或工作环境，并且必须装入当前线程的上下文。操作系统有一个很有效的上下文切换过程，所以每次切换并不耗费资源。任何上下文切换的显著增加，如当 cs 比磁盘 I/O 和网络信息包速率高得多，都应进行进一步调查。