Date

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

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秒时的输出示例:

image

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

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

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

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

image

从上面输出,我们可以得出以下推论:

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

4.3 案例分析:调度器过载

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

image

从上面的输出,我们可以得出以下推论:

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

4.4 mpstat工具的使用

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

image

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

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

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

image

image

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

image

4.6 结论

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

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