当我在Linux中发布top时,得到的结果与此类似: />
Cpu(s): 87.3%us,  1.2%sy,  0.0%ni, 27.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st


虽然我知道它们每个的定义(在下面),但我不理解这些任务的确切含义。



hi-服务硬件中断是什么意思?

si-服务软件中断是什么意思?

st-他们说这是“ CPU时间中非自愿等待虚拟机管理程序正在为另一个处理器(或)从虚拟机偷来的CPU时间提供服务的同时使用虚拟CPU”。

但这实际上是什么意思?有人可以说得更清楚吗?

我列出了ussyni等所有内容,因为它可以帮助其他人搜索相同的内容。此信息不在手册页中。

us: user cpu time (or) % CPU time spent in user space
sy: system cpu time (or) % CPU time spent in kernel space
ni: user nice cpu time (or) % CPU time spent on low priority processes
id: idle cpu time (or) % CPU time spent idle
wa: io wait cpu time (or) % CPU time spent in wait (on disk)
hi: hardware irq (or) % CPU time spent servicing/handling hardware interrupts
si: software irq (or) % CPU time spent servicing/handling software interrupts
st: steal time - - % CPU time in involuntary wait by virtual cpu while hypervisor is servicing another processor (or) % CPU time stolen from a virtual machine


#1 楼

hi是处理硬件中断所花费的时间。当硬件设备(网卡,键盘控制器,外部计时器,硬件传感器等)需要向CPU发出信号时(例如,数据已到达),就会产生硬件中断。

由于这些事件可能会非常频繁地发生,并且由于它们在运行时实际上会阻塞当前的CPU,因此编写内核硬件中断处理程序应尽可能快,简单。

如果需要长时间或复杂的处理,完成后,这些任务将使用机制softirqs推迟。它们是独立调度的,可以在任何CPU上运行,甚至可以同时运行(硬件中断处理程序都不是这样)。

关于硬IRQ阻止当前CPU的部分,以及关于softirqs的部分不能在任何地方运行都不能完全正确,存在局限性,某些硬性IRQ可能会中断其他中断。例如,网卡的“数据接收”硬件中断可以简单地将“卡ethX需要维修”信息存储在某处,并安排softirqsoftirq会触发实际的数据包路由。

si表示花费在这些softirqs上的时间。

深入了解softirq机制(有点历史)也是Matthew Wilcox的“我以后再做:Softirqs,Tasklet,下半部分,任务队列,工作队列和计时器(PDF,64k)”。

st,“窃取时间”仅与虚拟化环境相关。它表示真正的CPU对当前虚拟机不可用的时间,它是虚拟机管理程序从该VM“偷走”的(用于运行另一个VM,或用于其自身的需求)。

IBM的CPU时间计费文档提供了有关盗用时间以及虚拟化环境中CPU计费的更多信息。 (它针对zSeries类型的硬件,但是对于大多数平台来说,总体思路是相同的。)

评论


非常清楚。因此,如果我连接了新的音响系统,耳机等(与此相关的任何硬件),也会导致硬件中断,对吗?

–its_me
2011年8月17日19:14



是的,这可能是您的声音芯片组发出“某事已发生”的信号的一种方式。但是插入耳机可能完全由声音芯片本身处理(例如,将声音输出从主机路由到耳机),因此它可能不会对主CPU产生中断。但是,在键盘上键入一个键会产生中断(如果有USB键盘,则会从USB集线器设备产生中断)。另请参见cat / proc / interrupts(有关该文件的文档的man man proc)。

–垫子
2011年8月17日19:22

#2 楼


我们-在用户空间上花费的时间
sy-在内核空间上花费的时间
ni-运行良好的用户进程所花费的时间(用户定义的优先级)
id-空闲操作所花费的时间
wa-等待IO外设(例如磁盘)所花费的时间
hi-处理硬件中断例程所花费的时间。 (每当外围单元要引起CPU的注意时,它实际上就会拉一条线,向CPU发出信号以为其服务)。
si-处理软件中断例程所花费的时间。 (一段代码,调用一个中断例程...)
st-虚拟机管理程序为另一个处理器(从虚拟机中窃取)服务时,虚拟cpu非自愿等待所花费的时间


#3 楼

通过使用AWS的T2.micro EC2实例,可以简单地解释“ st”值。在AWS文档中,您可以读到每个VCPU的基准性能只有10%。这意味着,如果您有一个将消耗大量cpu时间的进程,则“ st”值将保持在90左右,因为只允许使用10%的VCPU。其他值的总和将保持在10左右。

因此,AWS使用虚拟机管理程序仅允许您访问一定量的计算能力。因为您仅使用低层类型的实例,所以它会故意使您放慢速度。

我希望这会使事情更容易理解。