模板
教程
环境
性能
功能
管理
Linux系统的性能测试与性能分析(2)
每秒钟处理的中断数
Hi%
服务于IRQs的时间占比
Si%
服务于Soft IRQs的时间占比
St%
关于st的解释，在IBM的一份文档里，有一段描述：
IBM’s definition of steal time is actually pretty good:
Steal time is the percentage of time a virtual CPU waits for a real CPU while the hypervisor is servicing another virtual processor.
3.3 工作原理
为了更好地理解CPU的性能参数，需要了解如下一些概念
3.3.1 进程及进程调度算法
什么是线程
图3：进程和线程的数据结构
2. 进程的状态
可运行状态(TASK_RUNNING)
不可中断的等待状态(TASK_UNINTERRUPTIBLE)
暂停状态(TASK_STOPPED)
跟踪状态(TASK_TRACED)
僵死状态(EXIT_ZOMBIE)
问题 Wait io%包含在idle%当中吗?
从下面top实例可以看出，wait io%不属于idle%,等IO的过程被叫做uninterruptible sleep
Cpu1 : 2.7%us, 3.0%sy, 0.0%ni, 3.7%id, 89.7%wa, 0.0%hi, 1.0%si, 0.0%st
从性能测试角度来看，我倾向于这样理解线程：
1. 线程和进程的确不同，因为他们可以共享进程的资源，如地址空间等。因此在上下文切换的过程中可能会产生较小的性能损耗。
2. 站在调度器(scheduler)的角度来说，线程就是一个进程，或者说是一个轻量级的进程(Light Weight Process)。Kernel实际上就是通过轻量级的进程来支持多线程应用程序的。我们经常用的线程开发库pthread就是通过将轻量级进程和线程关联起来，来实现的。这样既可以实现资源的共享，又可以让每个线程被调度器独立调度。
2. 进程的状态
可运行状态(TASK_RUNNING)
不可中断的等待状态(TASK_UNINTERRUPTIBLE)
暂停状态(TASK_STOPPED)
跟踪状态(TASK_TRACED)
僵死状态(EXIT_ZOMBIE)
问题 Wait io%包含在idle%当中吗?
从下面top实例可以看出，wait io%不属于idle%,等IO的过程被叫做uninterruptible sleep
Cpu1 : 2.7%us, 3.0%sy, 0.0%ni, 3.7%id, 89.7%wa, 0.0%hi, 1.0%si, 0.0%st
3.3.4 硬中断
性能测试中关注的中断，主要由自于IO设备所产生，如键盘的一次按键，网卡的收报等等。
IRQ
IO设备所发出的IRQ(Interrupt ReQuest)请求叫做中断请求(可屏蔽中断)
每个能够发出中断的IO设备都有一个IRQ输出线(部分高级前兆网卡，和大部分万兆网卡都多条IRQ输出线)。每条IRQ输出线和可编程中断控制器(Programmable Interrupt Controller)引脚相关联。
每个IRQ输出线的中断信号，只能被一个CPU core处理，IRQ线从0开始编号。
如何观察IRQ的状态：
问题3：大量的中断，是否会使CPU响应中断成为瓶颈呢?
答案是一般不会，中断享有最高的优先级，有硬件中断发生时，CPU会立即停下手中的工作，响应中断，并调用相应中断处理程序。瓶颈一般发生在中断处理程序。
IRQ硬件中断是否意味着不会出现瓶颈呢?瓶颈有可能出现在中断的服务例程中，看下面的流程图：
IRQ在多处理器上的分发：
遵循对称多处理模型，每个IO中断的处理时间片是相同的，均匀分配。Kernel通过中断向量表来将中断信号发送到特定的CPU上去。
在必要的时候，Linux 2.6利用kirqd的内核线程来纠正IRQ在CPU上的分配。kirqd线程周期性的执行扫描每个CPU处理的中断个数，发现不均衡时重新调整CPU的负载。
下面的案例表明，IRQ在CPU上的分配不够均衡，因为8个CPU，只有4个CPU有负载：
性能测试中关注的中断，主要由自于IO设备所产生，如键盘的一次按键，网卡的收报等等。
IRQ
IO设备所发出的IRQ(Interrupt ReQuest)请求叫做中断请求(可屏蔽中断)
每个能够发出中断的IO设备都有一个IRQ输出线(部分高级前兆网卡，和大部分万兆网卡都多条IRQ输出线)。每条IRQ输出线和可编程中断控制器(Programmable Interrupt Controller)引脚相关联。
每个IRQ输出线的中断信号，只能被一个CPU core处理，IRQ线从0开始编号。
问题3：大量的中断，是否会使CPU响应中断成为瓶颈呢?
答案是一般不会，中断享有最高的优先级，有硬件中断发生时，CPU会立即停下手中的工作，响应中断，并调用相应中断处理程序。瓶颈一般发生在中断处理程序。
IRQ硬件中断是否意味着不会出现瓶颈呢?瓶颈有可能出现在中断的服务例程中，看下面的流程图：
IRQ在多处理器上的分发：
遵循对称多处理模型，每个IO中断的处理时间片是相同的，均匀分配。Kernel通过中断向量表来将中断信号发送到特定的CPU上去。
在必要的时候，Linux 2.6利用kirqd的内核线程来纠正IRQ在CPU上的分配。kirqd线程周期性的执行扫描每个CPU处理的中断个数，发现不均衡时重新调整CPU的负载。
下面的案例表明，IRQ在CPU上的分配不够均衡，因为8个CPU，只有4个CPU有负载：
原文链接：http://testing.etao.com/
