CPU超载，但没有进程正在使用超过1％

在Linux上，被阻塞的进程也会影响负载平均值。 命令ps -Al列出所有进程。 在其输出的第二列（S表示状态）中，您将find过程状态。 大多数情况下，我都有等待磁盘“D”的进程，这些进程会计入负载平均值。

从ps手册页的状态完整列表是

  D Uninterruptible sleep (usually IO) R Running or runnable (on run queue) S Interruptible sleep (waiting for an event to complete) T Stopped, either by a job control signal or because it is being traced. W paging (not valid since the 2.6.xx kernel) X dead (should never be seen) Z Defunct ("zombie") process, terminated but not reaped by its parent. 

示例输出

 FS UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
 4 S 0 1 0 0 80 0  -  4906 poll_s？  00:00:23 init
 1 S 0 2 0 0 80 0 0 0 kthrea？  00:00:02 kthreadd
 1 R 0 3 0 99 80 0  -  0？  01:00:02亚军
 1 D 0 4 0 1 80 0  -  0？ 装载机01:00:02

如果这些是你唯一的进程，你可以看到CPU负载大约为2,1，而另外一个负载等待磁盘的负载。

非常精确的是在维基百科提供的信息

一个空闲的计算机的加载数为0.每个使用或等待CPU的进程（就绪队列或运行队列）将加载数量递增1.大多数UNIX系统只计算正在运行（在CPU上）或可运行的进程（等待CPU）状态。 但是，Linux还包括处于不间断睡眠状态（通常等待磁盘活动）的进程，如果由于I / O系统繁忙或停顿导致许多进程在I / O中被阻塞，则可能会导致明显不同的结果。 1例如，这包括由于NFS服务器故障或缓慢介质（例如，USB 1.x存储设备）而导致的进程阻塞。 这样的情况可能导致平均负载的提高，这并不反映CPU使用的实际增加（但仍然给出用户需要等待多长时间的想法）。

您提供的顶部信息并不一定意味着超载：

• CPU空闲35％
• 负载平均值不一定太大（取决于服务器的预期用途）
• RAM和交换信息丢失

或者更确切地说，如果超载，意味着有一些限制，那么可能会有很多方面：CPU限制，networking和/或磁盘I / O限制，内存使用限制等。

你不应该尝试去匹配不同的CPU负载/使用视图 – 它们通常意味着不同的事情，视图也是在不同的时间戳上收集的（统计信息收集不是primefaces的）：

• 加载平均值意味着运行队列中的作业数量，而不是CPU使用率： https ： //stackoverflow.com/questions/21617500/understanding-load-average-vs-cpu-usage
• 由于各种原因，过程上下文中的CPU使用率数字不必总计为100％，这里只是一些：
  • CPU不会把所有的周期都用在进程空间中
  • 在整个CPU使用率线上，不同周期花费在进程上下文中的不同周期（同一个进程在计算间隔期间可能在运行或等待I / O状态，因此贡献了％us和％wa数整个CPU使用率线）
  • CPU可能花费周期处理较长时间的运行，这些将在整个CPU使用率线中计数，但不会出现在任何处理线上

彼得是对的。 但是这并没有回答你的问题。 给它12个逻辑CPU，使负载降到CPU数量以下。 这样，任何进程或线程都不得不等待额外的CPU周期来获得执行时间。

在顶部也打开线程视图。

我怀疑你有一些multithreading的过程。

11％系统时间可能表示networking瓶颈。