我遇到了一个问题，我只能猜测哪个进程正在消耗CPU。
我的 psensor 所有核心的 CPU 使用率约为 80%。
我尝试过htop，top并且ps -A -o pcpu,pid,cmd --sort +pcpu（最后一个我什至尝试使用 sudo 无济于事）。
所有这些都表明罪魁祸首 pid（据我所知）仅使用了大约 7%...
当我对该 pid 发出 SIGKILL 信号时，一切都会恢复正常。
为了测试，我在终端上做了一个无限循环while true;do echo -n;done，但我可以在 htop 清楚地看到；所以我猜造成麻烦的原因与此不相似......
所以我想知道是否有其他方法可以找到罪魁祸首而无需猜测？
再想一想，我想我想知道什么计算psensor和“系统负载指示器小程序”使用了能够显示该值但其他人无法显示的值？
答案1
我对细节不够熟悉，无法给出准确的提示，但我猜想实际引起的负载和显示的 CPU 使用率之间有两个差异来源：
该进程可能由多个线程组成，并且
top可能无法将它们总结起来。您可以通过以下方式查看线程数：ps -eo pid,nlwp,%cpu,user,args您
top可以使用 切换线程处理H。每个线程的CPU使用率通常相当低。该进程可能会导致大量 I/O。 I/O 等待时间是总体 CPU 负载的一部分，但可能不是进程 CPU 使用值的一部分。因此检查
wait中的值top。它不会告诉您哪些过程会导致其达到何种程度，但如果该值较低，则它无法解释效果。
答案2
在 UNIX 系统上执行的代码分为内核代码或用户态代码。用户态代码始终附加到进程，因此如果 CPU 正忙于执行用户态代码，它会显示在top.内核代码通常附加到进程：如果内核正在执行系统调用，则内核内处理被视为属于该进程。内核时间是实用程序报告的“系统时间” time。
内核所做的一些事情不能直接针对一个进程进行计算。特别是，硬件中断本质上并不属于特定进程。例如，假设中断是由网卡触发的。内核执行代码读取并解析网络数据包；到目前为止，还没有涉及任何流程。该数据包可能会通过防火墙规则被拒绝，在这种情况下，没有进程可以要求该处理时间。如果某个进程最终接收到该数据包，则部分接收时间将显示在该进程的选项卡上，但不会显示早期阶段。
所以有可能拥有不属于任何进程的CPU时间。但有时 CPU 时间是由某些进程间接引起的。例如，如果有一个进程将数据包发送到另一台机器并导致另一台机器进行回复，但防火墙阻止了回复数据包，那么解析和丢弃回复数据包所花费的时间将不会追溯到该发送进程；但如果发送过程停止，导致远程计算机停止回复，那么内核将不再花时间拒绝数据包。当然，网络只是一个例子，内核还有很多其他方式可以做一些无法直接追踪到某个进程的事情。
您没有提供足够的信息来确定这就是正在发生的事情（如果没有内核调试器，可能很难弄清楚），但这是一个合理的解释。
答案3
如果不想使用 htop、ps、top，您可以使用 systemtap，获取更多底层详细信息