2.2.2. 案例学习:持续的CPU 利用率
在这个例子中,这个系统被充分利用
根据观察值,我们可以得到以下结论:
1.有大量的中断(in) 和较少的上下文切换(cs).这意味着一个单一的进程在产生对硬件设备的请求.
2.进一步显示某单个应用,user time(us)经常在85%或者更多.考虑到较少的上下文切换,这个应用应该还在处理器中被处理.
3.运行队列还在可接受的性能范围内,其中有2个地方,是超出了允许限制.
2.2.3. 案例学习:超负荷调度
在这个例子中,内核调度中的上下文切换处于饱和
根据观察值,我们可以得到以下结论:
1.上下文切换数目高于中断数目,说明kernel中相当数量的时间都开销在上下文切换线程.
2.大量的上下文切换将导致CPU 利用率分类不均衡.很明显实际上等待io 请求的百分比(wa)非常高,以及user time百分比非常低(us).
3.因为CPU 都阻塞在IO请求上,所以运行队列里也有相当数目的可运行状态线程在等待执行.
2.2.4. mpstat 工具的使用
如果你的系统运行在多处理器芯片上,你可以使用 mpstat 命令来监控每个独立的芯片.Linux 内核视双核处理器为2 CPU’s,因此一个双核处理器的双内核就报告有4 CPU’s 可用.
mpstat 命令给出的CPU 利用率统计值大致和 vmstat 一致,但是 mpstat 可以给出基于单个处理器的统计值.
2.2.5. 案例学习: 未充分使用的处理量
在这个例子中,为4 CPU核心可用.其中2个CPU 主要处理进程运行(CPU 0 和1).第3个核心处理所有内核和其他系统功能(CPU 3).第4个核心处于idle(CPU 2).
使用 top 命令可以看到有3个进程差不多完全占用了整个CPU 核心.
你也可以使用 ps 命令通过查看 PSR 这列,检查哪个进程在占用了哪个CPU.
2.3. 结论
监控 CPU 性能由以下几个部分组成:
1. 检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.
2. 确定CPU 利用率中user/system比例维持在70/30
3. 当CPU 开销更多的时间在system mode,那就说明已经超负荷并且应该尝试重新调度优先级
4. 当I/O 处理得到增长,CPU 范畴的应用处理将受到影响