Linux系统和性能监控
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利用率较高时?)
转载至:http://www.cnblogs.com/wujianlundao/archive/2013/01/03/2843072.html
已有 0 人发表留言,猛击->> 这里<<-参与讨论
ITeye推荐