【译】Linux系统和性能监控(4)

原文Linux System and Performance Monitoring，作者Darren Hoch。

 转载自：http://www.708luo.com/?p=43

4.0 CPU性能监控

CPU性能表现如何一般从三个方面来衡量：运行队列、利用率和上下文切换。正如前文所提及的，性能表现的好坏和基线数据（或预期）是密不可分的。对大部分系统而言，一些基本的性能预期如下：

• 运行队列——每个处理器运行队列中不应该超过1-3个线程。例如，一个双核的系统中，运行队列长度不应该超过6。（译注：即一个系统的load average值不应该大于核数的4倍。）
• CPU利用率——假如CPU被充分利用了，那么必须达到以下的占比划分：
• User Time占65%-70%
• System Time占30%-35%
• Idle占0%-5%
• 上下文切换——上下文切换的次数和CPU利用率相关。假设CPU利用率达到了上述的占比划分，大量的上下文切换也是可以接受的。

Linux系统有很多工具可以用来统计这些指标。我们将首先来看vmstat和top。

 

4.1 vmstat工具的使用

vmstat带来的额外性能开销很小，因此，在一个高负载系统上一直运行该工具是可行的，即使你并不想长久地统计它的性能数据。该工具有两种运行模式：统计模式和采样模式。采样模式每隔一个指定的时间间隔会统计和输出一个结果。这种模式在统计一个持久负载下的性能数据时非常有用。下面是一个vmstat在指定时间间隔为1秒时的输出示例：

上面输出中CPU相关各列的意义如下：

列名	含义
r	运行队列的长度，即等待执行的线程数目
b	处于阻塞状态或者等待IO完成状态的线程数目
in	系统中断的数目
cs	上下文切换的数目
us	CPU执行用户态线程的时间占比
sys	CPU执行系统态线程占用的时间占比，包含内核和中断两部分
wa	CPU处于等待状态的时间占比（CPU等待状态即所有线程都处于被阻塞或者等待IO完成状态）
id	CPU处于完全空闲状态的时间占比

 

4.2 案例分析：CPU的持续耗用

在下面的案例中，系统CPU已经被完全用尽。

从上面输出，我们可以得出以下推论：

• 系统中有大量的中断和少数的上下文切换，看起来是某个进程正在请求访问硬件设备。
• CPU用户态耗用占了85%以上，同时只有少量的上下文切换，进一步证明了有一个进程一直在占用CPU。
• 运行队列长度达到可以接受的上限，甚至在几个瞬间已经超过了这个上限。

4.3 案例分析：调度器过载

在下面的案例中，内核调度器一直忙于上下文切换。

从上面的输出，我们可以得出以下推论：

• 上下文切换的次数远大于中断的次数。内核必须消耗大量的时间用于上下文切换。
• 大量的上下文切换导致了CPU利用率的不平衡。从用户态CPU占用极低和Wait IO态CPU占用极高可以明显看出来。
• 因为CPU处于等待IO状态，运行队列开始堆积，等待IO的线程数也开始堆积。

4.4 mpstat工具的使用

如果系统有多个处理器内核，你可以使用mpstat命令来监控各个核。Linux内核把双核处理器看作为两个处理器。因此，一个双核双处理器系统会被认为有4个处理器。mpstat提供了vmstat类似的CPU统计功能，不过mpstat还按CPU核的粒度提供了统计数据。

 

4.5 案例分析：未充分使用的处理器负载

在下面的案例中，系统有4个CPU内核，有两个CPU耗用型的进程将其中两个核（CPU0和CPU1）充分利用，第三个核正在执行内核和系统调用（CPU3），第四个核（CPU2）处于空闲状态。

Top命令显示了有3个进程（nobody、mysql、apache）几乎各自占用了其中的一整个CPU内核：

你可以通过ps命令的PSR字段判断哪一个进程占用了哪一个CPU内核。

 

4.6 结论

CPU的性能监控包含如下要点：

• 检查运行队列，保证每个处理器的运行队列长度不超过3。
• 保证CPU的利用率在用户态和系统态的比例在70/30和65/35之间。
• 如果CPU在系统态所花的时间更多，可能不仅仅是过载的原因，尝试重新设置一下进程的优先级
• 运行IO型的进程比运行CPU型的进程更有收益（译注：是指在CPU利用率较高时？）