如何使用vmstat命令监视 CPU 的使用情况(from ibm)

墨蓝 2022-08-12 05:58 189阅读 0赞

原贴:http://www-01.ibm.com/support/docview.wss?uid=csc19f9b92dab5a7454748256e0400072664

<table style="width: 610px;"> 
 <tbody> 
 <tr> 
 <td>&nbsp;</td> 
 <td> 
 <table style="width: 443px;"> 
 <tbody> 
 <tr> 
 <td><img src="http://www.ibm.com/i/c.gif" alt="" width="1" height="6"> <h1>如何使用vmstat命令监视 CPU 的使用情况</h1> <img src="http://www.ibm.com/i/c.gif" alt="" width="1" height="6"> </td> 
 </tr> 
 </tbody> 
 </table> 
 <table style="width: 443px;"> 
 <tbody> 
 <tr> 
 <td> Document #: 2811993L22000 Body: [标题] 如何使用vmstat命令监视 CPU 的使用情况 内容提要: CPU 处理单元是系统中最快的组件。在某一时间对单个程序来说，相对很少保持 100% 的 CPU 占用率（也就是说， 空闲 0% ，等待 0% ）超过几秒钟。甚至在高负载的多用户系统中，偶尔会出现一些 10 毫秒（ms ）的时期，在其结 束时所有线程处于等待状态。如果一个监视器显示在一段延长的时期内 CPU 占用率为 100% ，很有可能是陷入了死 循环。甚至如果该程序“仅仅”是占用较多资源，而不是崩溃了，也需要将它识别出来并进行处理。 说明: CPU 处理单元是系统中最快的组件。在某一时间对单个程序来说，相对很少保持 100% 的 CPU 占用率（也就是说， 空闲 0% ，等待 0% ）超过几秒钟。甚至在高负载的多用户系统中，偶尔会出现一些 10 毫秒（ms ）的时期，在其结 束时所有线程处于等待状态。如果一个监视器显示在一段延长的时期内 CPU 占用率为 100% ，很有可能是陷入了死 循环。甚至如果该程序“仅仅”是占用较多资源，而不是崩溃了，也需要将它识别出来并进行处理。 在这里，要使用的工具是 vmstat 命令，该命令可提供关于各种系统资源和各种与之相关的性能问题的简明信息。 vmstat 命令报告了关于内核线程的统计信息，包括处于运行和等待队列中的、内存中的、页面调度中的、磁盘中的、 中断、系统调用、上下文切换和 CPU 活动的内核线程。所报告的 CPU 活动是用户模式、系统模式、空闲时间和等待 磁盘 I/O 的百分比细分类目。 注：如果使用 vmstat 命令时不带任何选项，或者只带有间隔和任意的计数参数，例如 vmstat 2 10 ，那么第一行数 字为自系统重新引导以来的平均值。 作为一个 CPU 监视器，vmstat 命令比 iostat 命令优先级要高，因为 vmstat 命令是滚动的，使得它的每报告一行的输 出更容易扫描，并且如果有很多磁盘连接到系统中，由此所引起的开销更少。 下面的例子会帮助您识别一个程序失控时或过度占用 CPU 以至于不能在一个多用户环境中运行的情况。 
 <ul> 
 <li># 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 </li> 
 </ul> 这个输出结果显示了在一个繁忙的多用户系统中引入一个有死循环的程序所带来的效果。最开始的三个报告（摘要已 被删除）表明系统稳定在用户模式 50 —55% 、系统模式 30 —35% 和 I/O 等待 10 —15% 。当循环程序开始运行，所有的 CPU 周期被占用。因为循环程序不进行 I/O ，所以它可以占有前面因为 I/O 等待而未用的所有周期。更糟糕的是这意味 着，当一个有用进程放弃 CPU 的使用权时，这个进程总是准备占用 CPU 。因为死循环程序的优先级与所有其它前台进 程一样，所以当另一个进程变得可调度时它也没必要让出 CPU 的使用权。该程序运行大约 10 秒钟（五个报告），然后 由 vmstat 命令报告的活动恢复到较正常的模式。 CPU 统计信息在设备中断负载很高的系统上会有一定程度的失真。这种情况是因为该工具是对定时器中断采样。定时 器是优先级最低的设备，所以它很容易被其它中断抢先。为了消除失真，当操作系统版本晚于 AIX 4.3.3 时, 采用了一 种不同的方法来对定时器进行采样。 注：对对称多处理系统 us、sy、id 和 wa 几列只是对各处理器求平均值（sar 命令可以报告每个处理器的统计信息）。 一个 I/O 等待和空闲时间 只能从未决 I/O 的状态来区分。如果有一个未决磁盘 I/O，并且处理器不忙，那么这 是一个 I/O 等待时间。AIX 4.3.3 和其后的系统中用一个增强的方法来计算花费在磁盘 I/O 上的 CPU 时间 （wio 时间）所占的百分比。 在最佳使用时，CPU 在 100% 的时间中都在工作。在单用户系统中更是这样，这里不需要共享 CPU。总的来说，如果 us + sy 时间低于 90%，则不认为该单用户系统 CPU 受限制。但是，如果在一个多用户系统中 us + sy时间超过 80%, 其中的进程将要花时间在运行队列中等待。响应时间和吞吐量会受损害。 要检查 CPU 是否是瓶颈，考虑 vmstat 报告中的四个 cpu 列和两个 kthr （内核线程）列，也应该查看 faults 列。 cpu列 在该时间间隔内使用 CPU 时间的百分比细分。cpu 列如下： us 参数 us 列显示了用户模式所消耗的 CPU 时间。一个 UNIX 进程可以在用户模式下执行，也可以在系统（内核）模式下执 行。当在用户模式下执行时，进程在它自己的应用程序代码中之行，不需要内核资源来进行计算、管理内存或设置变 量。 sy 参数 sy 列详细显示了 CPU 在系统模式下执行一个线程所花时间的百分比。包括内核进程(kprocs )和其它需要访问内核资 源的进程所消耗的 CPU 资源。如果一个进程需要内核资源，它必须执行一个系统调用，并因此被切换到系统模式从 而可以使用该资源。例如，对一个文件的读或写操作需要内核资源来打开文件、寻找指定的位置和读写数据，除非使 用内存映射文件。 id 参数 id 列显示了没有未决本地磁盘 I/O 时 CPU 空闲或等待时间的百分比。如果没有线程可以执行（运行队列为空）系 统调度一个叫做 wait 的线程，也就是 idlekproc 。在一个对称多处理系统中，每个处理器都有一个 wait 线程可调 度。由 ps 命令（带有 -k 或 -g 0 选项）将它确定为 kproc 或 wait。如果报告中 ps 显示这个线程的总计时间高， 这表明存在显著的时期，没有其它线程在这个 CPU 上准备运行或等待执行。系统因此大部分时间或任务空闲和等待 新任务。 如果没有未决 I/O，所有用于等待的时间归入空闲时间中。在4.3.2版或更早的操作系统中，访问远程磁盘（安装 NFS 磁盘）被当作空闲时间（有少量 sy 时间来执行 NFS 请求），因为没有对本地磁盘的未决 I/O 请求。在 AIX 4.3.3 和 以后的系统中，NFS 通过缓冲区高速缓存，在这些例程中的等待被放入 wa 中统计。 wa 参数 wa 列详细显示了有未决本地磁盘 I/O 时 CPU 空闲的时间百分比（在 AIX 4.3.3 和以后版本的系统中，对安装了 NFS 的磁盘也是这样）。如果当等待正在运行时至少有一个未完成的磁盘 I/O，该时间归入等待 I/O 的时间。除非 该进程使用异步 I/O，否则对磁盘的 I/O 请求使调用线程被阻塞（或睡眠）直到请求被完成。一旦进程的 I/O 请求 完成，该进程被放入运行队列中。如果 I/O 很快完成，该进程可以使用更多的 CPU 时间。 wa 的值如果超过 25%,就表明磁盘子系统可能没有被正确平衡，或者这也可能是磁盘工作负荷很重的结果。 Kthr 列 每秒钟在采样间隔上对各种队列中的内核线程数求得的平均值。kthr 列如下： r 参数 可运行的内核线程平均数目，包括正在运行的线程和等待 CPU 的线程。如果这个数字大于 CPU 的数目，至少有一个 线程要等待 CPU，等待 CPU 的线程越多，越有可能对性能产生影响。 b 参数 每秒 VMM 等待队列中的内核线程平均数。包括正在等待文件系统 I/O 的线程，或由于内存装入控制而被挂起的线程。 如果进程由于内存装入控制而被挂起，在 vmstat 报告中的阻塞列（b）表明线程数目增加，而不是运行队列中线程 数目增加。 p 参数 对与 vmstat -I ，是每秒等待原始设备 I/O 的线程数目。等待文件系统 I/O 的线程不包括在这里。 faults 列 关于进程控制的信息，如陷阱和中断率。faults 列如下： in 参数 在该时间间隔中观测到的每秒设备中断数。额外信息可见用 vmstat 命令评估磁盘性能。 sy 参数 在该时间间隔中观测到的每秒系统调用次数。通过明确的系统调用，用户进程可以使用资源。这些调用命令内核为调 用线程执行操作，并在内核和该进程之间交换数据。因为，工作负荷和应用程序变化很大，不同的调用执行不同的功 能，所以不可能定义每秒钟有多少系统调用才算太多。但是通常来讲，在一个单处理器系统上当 sy 列增大到超过每 秒钟 10000 个调用， 应进行进一步的调查（在一个对称多处理系统上，这个数字为每个处理器每秒钟 10000 个调 用）。其中一个原因可能是“轮询”子例程，象 select() 子例程。对这列，建议进行一个基准评估，给出正常 sy 值 的一个计数。 cs 参数 在该时间间隔中观测到的每秒钟上下文切换次数。物理上的 CPU 资源被分为每个 10 毫秒的逻辑时间片。假设一个 线程被调度运行，它将一直运行直到它的时间片用完、直到被抢先或直到它自己主动放弃 CPU 控制权。当另一个线 程被赋予 CPU 控制权时，必须保存前一个线程的上下文或工作环境，并载入当前线程的上下文。操作系统有一个很 有效的上下文切换过程，所以每次切换并不耗费资源。任何上下文切换的显著增加，如当 cs 比磁盘 I/O 和网络包 速率高的多，都应进行进一步调查。 参考资料: </td> 
 </tr> 
 </tbody> 
 </table> </td> 
 </tr> 
 </tbody> 
</table>