当我跑步时
top -b -n1 -o +%CPU
myasterisk很少出现在最前面的进程中，而 thetop通常是第一个。但是当我top以交互方式运行时asterisk，它通常是第一位的。
这是为什么？批处理和交互式设置有什么区别吗？
答案1
top突发工作
通常
top是第一个
运行time top -b -n1 -o +%CPU。您将看到它花费的时间很少（例如 0.2 秒），在此期间工具相对繁忙。如果您使用-b -n2，您将看到第一次和第二次迭代之间的差异。除第一次迭代之外的任何迭代在更新间隔（例如 3 秒）过去之前几乎什么都不做。
交互式top工作方式类似。您可能没有注意到，第一次迭代显示的值比后续迭代显示的值top更高。%CPU
如果你运行，top -b -n2 -d0 -o +%CPU那么第二次迭代将显示top非常高的%CPU值。对于 interactive 来说也是如此top -d0。这里top不会自行等待，因此它处于最大繁忙状态。
您的问题之所以出现，是因为除第一次迭代之外的所有迭代都取决于延迟间隔（由-d中的 或指定~/.toprc，或默认的）。对于除top本身之外的稳定过程，这可能无关紧要。对于top则不同，因为无论迭代需要多长时间，工具每次迭代都需要完成基本相同的工作量。每次迭代都会发生一次突发事件。迭代花费的时间越长，%CPU得到的值就越低top。较低的值反映了较长时间内平均的相同工作量。
您应该比较不同运行的第一次迭代；或者比较同一次运行或间隔相同的不同运行的非第一次迭代。
如果您想要获得一次依赖于指定间隔的非交互式迭代，请使用-b -n2并丢弃第一次迭代。
asterisk可能会突发事件
asterisk很少出现在顶级进程中 […]。但当你top以交互方式运行时，asterisk它通常是第一位的。
我承认我没有实际测试过asterisk。它处理数据包，因此可能会突发工作。我并不是说它在此期间完全空闲，我的意思是 CPU 使用率可能会达到峰值asterisk。
总体来说，asterisk以一个示例程序为例。当 CPU 使用率达到峰值时会发生什么？
的第一次迭代top可能会也可能不会达到峰值。因此%CPU， 的asterisk可能比其他（可能稳定的）过程大得多或小得多%CPU。实际上，有时asterisk是 1，通常不是。非第一次迭代将显示 的平均值%CPU。峰值可能不那么频繁，因此在 的第一次迭代中top“很少作为顶级过程之一出现”；但它们可能足够高，可以提高的asterisk平均值，因此非第一次迭代显示“通常是 1”。%CPUasteriskasterisk
其他进程可能会突发
我不知道你的情况是否也是如此，但这确实是有可能的。
想象有几个与问题不同的进程asterisk，它们每个都会不时地对 CPU 造成压力，但只是片刻；否则它们大部分时间都处于空闲状态。想象一下，几乎每次运行top -b -n1 +%CPU都会有两三个进程占据主导地位asterisk（不管它们asterisk实际上是以突发、峰值还是稳定方式工作）。它们占主导地位不是因为你很幸运在它们爆发时抓住它们，而是因为如果此类进程的数量足够大，这种情况发生的概率就更大。我的意思是，如果有许多这样的进程，那么你必须很幸运才没有抓住任何一个进程爆发。想象一下，占主导地位的进程集每次都不同；它不是可以主导平均 CPU 使用率的同一组。这样的进程可能会死亡，也可能会产生新的进程。
那么，asterisk就“瞬时”而言，它很少是第一%CPU，但就平均值而言，它总是第一%CPU。
概括
当您编写非交互式 时top，您会考虑每次运行的第一次（在 的情况下-n1：唯一一次）迭代。这种情况发生得相对较快，并促使进程（包括其top本身）的 CPU 使用率较高眼下。
当你写到交互式时top，你显然指的是非第一次迭代。它们依赖于延迟间隔，默认情况下，延迟间隔远大于任何第一次迭代所需的时间。实际上，它们促进了具有高平均的CPU使用率。