Linux “top”命令：us、sy、ni、id、wa、hi、si 和 st（CPU 使用率）是什么？

Question

当我top在 Linux 中发出时，我得到类似这样的结果：

其中一行具有 CPU 使用率信息，如下所示：

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 时间百分比”）。

但它实际上意味着什么？有人可以更清楚吗？

我列出的所有的us，sy，ni，等，因为它可以帮助别人寻找相同。此信息不在手册页中。

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

Answer 1

hi是处理硬件中断所花费的时间。硬件中断由硬件设备（网卡、键盘控制器、外部定时器、硬件传感器等）在需要向 CPU 发送信号（例如，数据已到达）时产生。

由于这些可能非常频繁地发生，并且由于它们在运行时本质上会阻塞当前 CPU，因此内核硬件中断处理程序被编写为尽可能快速和简单。

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

_{硬 IRQ 阻塞当前 CPU 的部分和softirqs能够在任何地方运行的部分并不完全正确，可能存在限制，并且一些硬 IRQ 可以中断其他。}

例如，来自网卡的“数据接收”硬件中断可以简单地将“卡 ethX 需要服务”的信息存储在某处并安排一个softirq. 这softirq将是触发实际数据包路由的事情。

si代表在这些中花费的时间softirqs。

softirqMatthew Wilcox 的I'll Do It Later：Softirqs、Tasklets、Bottom Haves、Task Queues、Work Queues 和 Timers（PDF，64k）是关于该机制的一个很好的读物（也有一些历史）。

st，“窃取时间”，仅在虚拟化环境中相关。它代表当前虚拟机无法使用真实 CPU 的时间——它被虚拟机管理程序从该虚拟机“窃取”（运行另一个虚拟机，或为了它自己的需要）。

IBM的CPU 时间统计文档提供了有关窃取时间和虚拟化环境中 CPU 统计的更多信息。（它针对 zSeries 类型的硬件，但对于大多数平台，总体思路是相同的。）

Answer 2

• us - 在用户空间花费的时间
• sy - 在内核空间中花费的时间
• ni - 运行 niced 用户进程所花费的时间（用户定义的优先级）
• id - 在空闲操作中花费的时间
• wa - 等待 IO 外围设备（例如磁盘）所花费的时间
• 嗨 - 处理硬件中断例程所花费的时间。（每当外围单元需要 CPU 关注时，它都会拉一条线，以通知 CPU 为其提供服务）
• si - 处理软件中断例程所花费的时间。（一段代码，调用一个中断例程...）
• st - 虚拟机管理程序为另一个处理器提供服务时虚拟 cpu 非自愿等待所花费的时间（从虚拟机中窃取）

Answer 3

“st”值可以通过使用来自 AWS 的 T2.micro EC2 实例来简单解释。

在AWS 文档中，您可以看到每个 VCPU 只能获得 10% 的基准性能。这意味着如果您有一个会消耗大量 CPU 时间的进程，“st”值将保持在 90 左右，因为您只能使用 10% 的 VCPU。其他值的总和将保持在 10 左右。

所以 AWS 使用虚拟机管理程序只允许您访问一定数量的计算能力。由于您仅使用低层类型的实例，因此它有意减慢了您的速度。

我希望这能让事情变得更容易理解。