在我们的服务器上查看 top 的输出时，我的一位同事告诉我，某些进程的“%CPU”低于 100 是因为我运行了太多进程。他补充说，根据他的经验，如果我运行的进程少于 6 个，那么可能所有进程都有 100“%CPU”。
我不想成为其他用户的烦恼，但我怀疑他所说的是否正确。服务器有 16 个核心，当前平均负载在 10 到 11 之间。据我了解，它并没有过载。但我不知道为什么有些进程只得到少于 100“%CPU”？真的是因为我吗？
谢谢并恭祝安康！
这是top的输出：
top - 16:34:13 up 32 days, 1:36, 12 users, load average: 10.61, 10.39, 10.22
Tasks: 380 total, 10 running, 370 sleeping, 0 stopped, 0 zombie
Cpu(s): 55.0%us, 1.7%sy, 0.0%ni, 42.2%id, 0.5%wa, 0.1%hi, 0.4%si, 0.0%st
Mem: 130766620k total, 39859784k used, 90906836k free, 849412k buffers
Swap: 47351548k total, 279456k used, 47072092k free, 19792956k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17197 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4510:11 MLtest
28762 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4633:01 MLtest
29249 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4623:03 MLtest
29560 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4626:59 MLtest
4904 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4757:12 MLtest
5143 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4759:40 MLtest
29389 tim 18 -2 1315m 1.3g 1504 R 99 1.0 4622:11 MLtest
5285 tim 18 -2 1315m 1.3g 1504 R 97 1.0 4758:49 MLtest
4763 tim 18 -2 1315m 1.3g 1504 R 93 1.0 4754:22 MLtest
9456 zma 18 -2 206m 85m 11m S 48 0.1 60:46.78 dropbox
7527 vals 18 -2 1266m 436m 42m S 4 0.3 613:57.10 MATLAB
2903 root 15 -5 0 0 0 S 1 0.0 19:00.01 rpciod/0
19133 vals 18 -2 1380m 503m 42m S 1 0.4 798:47.99 MATLAB
12454 tim 18 -2 19248 1588 1024 R 1 0.0 0:48.88 top
12 root RT -5 0 0 0 S 1 0.0 35:01.05 migration/3
2924 root 15 -5 0 0 0 S 1 0.0 27:20.92 nfsiod
12690 jun 18 -2 913m 84m 2684 S 1 0.1 121:55.65 MATLAB
19650 jun 18 -2 19244 1600 1028 S 1 0.0 6:58.41 top
6 root RT -5 0 0 0 S 0 0.0 129:49.45 migration/1
9 root RT -5 0 0 0 S 0 0.0 104:34.66 migration/2
2870 daemon 20 0 8180 404 308 S 0 0.0 5:18.91 portmap
8985 root 20 0 28484 344 264 S 0 0.0 6:24.77 hald-addon-stor
9293 root 20 0 369m 4208 2316 S 0 0.0 83:36.35 kdm_greet
24028 tim 18 -2 871m 140m 45m S 0 0.1 7:50.56 MATLAB
1 root 20 0 4104 304 224 S 0 0.0 0:03.59 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.26 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:00.31 migration/0
4 root 15 -5 0 0 0 S 0 0.0 1:08.91 ksoftirqd/0
不知道你的朋友在说什么，但这听起来很武断，而且……嗯，大错特错。
CPU 度量的百分比有些误导。事实上，任何当前“开启”CPU 的进程都在那个时刻获得了 100% 的 CPU。百分比是指这些进程在上次采样期间收到的 CPU 时间。
因此，它们显示的 CPU 使用率低于 100% 并不表示存在问题。
在你的最高输出中一个更相关的度量是这一行：Cpu(s): 55.0%us, 1.7%sy, 0.0%ni, 42.2%id, 0.5%wa, 0.1%hi, 0.4%si, 0.0%st
它显示了 42% 的 CPU 空闲时间。因此，您的其他进程，无论它们是什么，都不受 CPU 限制。
您可以按“1”（一个），然后
top会在顶部显示每个 CPU 的 CPU 统计信息。你可能会发现这些信息。程序不仅仅是在 CPU 上等待。他们在磁盘上等待网络 I/O；他们等待用户输入。并非每个运行的程序都会使用 100% 的 CPU 来进行 top 的刷新量。例如，当什么都没有运行时，您是否看到
init消耗了 100% 的 CPU？不。你的朋友不仅错了，而且如果你按照他说的去做，很可能会适得其反。如果您有 16 个内核和 10 个负载，那么您可能应该增加您正在运行的 MLTest 进程的数量，如果它目前仅限于 9 个并且可以以某种方式配置。为什么？
好吧，一个进程通常只能在 1 个 cpu 上运行。如果进程使用 100% 的 cpu，则它是 cpu bound。因此，如果您限制并说您只能使用 9 个进程来执行 MLTest 所做的任何事情，那么您只能使用这 16 个处理器中的 9 个。
负载是指等待运行的进程数。您显然有 10 个进程需要在 CPU 上运行。谁知道他们需要做什么。但是，如果您只让您的 MLTest 进程在几个 CPU 上运行（请记住，每个 CPU 1 个进程），那么您（可能）会有高负载，因为所有这些进程总是在运行或等待运行。但是，通过让更多进程，您可以更快地完成更多工作，然后您不必等待运行这么多时间。
然而，这只是一种理论上的情况。具体解决问题，需要回答：
1）什么（进程）正在等待运行（导致负载）？2）您是否限制了可以运行的 MLTest 进程的数量？3）如果你让更多的 MLTest 进程运行，它会更快地“完成”你的问题/程序吗？
很多事情都可能导致这种情况，我首先要说的是，这不是惊慌或担忧的原因。
除了你所包含的进程列表之外，我不知道更多关于你正在做的事情，并且对Matlab一无所知，我将建议一些可能正在发生的事情，这些事情是完全正常的，并且可能导致你正在看。
不过，首先，我想指出 top 显示的是一段时间内的平均值，而且可能是一个非常短的时间——大约几秒钟。您的一个进程仅以 93% 的速度运行几秒钟（而不是 100%）并不是一件大事。在下一个时间间隔内，它可能会恢复到 100%（不同的过程会下降到 93%）。
回到为什么：
如果一个进程执行任何需要系统调用的操作，尤其是磁盘 I/O，它可能会空闲一段时间以等待该操作完成。这将导致小于 100% 的 CPU 使用率，这是它在 I/O 上阻塞的时间的一部分。其他用户的进程肯定会在这里产生影响。可能有足够多的内核，但如果你们都在争夺同一个硬盘的带宽，那么没有人会看到 100% 的 CPU 利用率。
您的应用程序似乎一次使用多个进程甚至多个线程。这可以加快速度（这直接取决于应用程序以及它如何划分工作）。但是，当涉及到进程之间的通信时，这也可能会产生相关成本。例如，如果每个子进程（或线程）必须与其他进程通信，那么通信通道的数量会随着进程数量的增加而显着增长。即使每个进程只与一个主进程通信，当父进程与不同的子进程交谈时，子进程也可以阻止与父进程的通信。这与阻塞磁盘 I/O 并没有什么不同。
最后，即使有无限数量的内核，您可能会看到用于工作的每个额外进程的回报都会递减。正如您的同事所建议的那样，某处可能有一个甜蜜点，也许是 6 个。但我不会使用他的分析（寻找<100% 的利用率）来确定最佳位置在哪里。