为什么apt-get 不是使用 100% 的 CPU、磁盘或网络——甚至接近 100%？即使在速度较慢的系统（Raspberry Pi 2+）上，我最多也只能获得 30% 的 CPU 负载。我只是在想，要么它被人为限制，要么它应该最大化某物当它正在工作时......或者它应该能够比它更快地完成它的事情。
编辑：我只是通过面板中的 cpu/磁盘/网络监视器以及 Ubuntu MATE 的系统监视器应用程序进行粗略测量。
请解释一下我为什么错了。 :-)
更新：我知道apt-get需要获取其更新（并且可能受到上游/提供商带宽的限制）。但一旦进行“拆包”等操作，CPU占用率至少应该是上（如果不是最大）。在我相当不错的家庭工作站上，它使用 SSD 作为主驱动器，使用 ramdisk 作为 /tmp，但情况并非如此。
或者也许我需要仔细看看。
答案1
仅当应用程序满足以下条件时，才会最大化 CPUCPU 限制。一个应用程序是CPU 限制如果它能够快速获取所有数据，那么它等待的就是处理器来处理数据。
apt-get，另一方面，是IO 绑定。这意味着它可以相当快地处理数据，但是加载数据（从磁盘或网络）需要时间，在此期间处理器可以执行其他操作，或者如果没有其他进程需要则处于空闲状态。
通常，所有 IO 请求（磁盘、网络）都很慢，每当应用程序线程发出请求时，内核都会将其从处理器中删除，直到数据加载到内核中（=这些 IO 请求称为阻止请求）。
答案2
即使在速度较慢的系统（Raspberry Pi 2+）上，我最多也只能获得 30% 的 CPU 负载。
Raspberry Pi 2+ 有 4 个核心。对于某些监控工具，100% 使用率对应于所有核心都以 100% 使用。如果四代码处理器中仅使用一个核心，则 CPU 负载为 25%。您提到的 30% CPU 负载大约是一个核心使用 100%，而某些进程正在其他核心上运行：
(100% on one core out of 4 = 100 / 4 = 25%) + some processes ≃ 30%
由于apt-get不是多线程，因此它永远不会使用超过一个处理器，即所有 CPU 资源的 25%。
这是我的 8 核的示例（4 核，超线程）运行 Ubuntu 的机器上，我使用该cat /dev/zero > /dev/null命令启动了一个线程，以便创建一个完全利用一个核心的无限进程。
现在，如果我们看一下图表htop，我们可以看到平均负载（Avgbar）为12.7%，对应于一个核心使用率为 100%，也是所有 CPU 资源的 1/8：
(100% = 100 / 8 = 12.5%) + some background processes ≃ 12.7%.
还可以注意到，该命令100%在该CPU%列中有一个值，这是因为它是相对于一个核心而不是所有核心。
答案3
我认为你实际上没有测量 IO %。我还没有见过 Linux IO% 小部件。 （我很羡慕Windows 10的任务管理器:)。使用命令检查iotop，你会看到100% IO。
top应该显示 100% across user+ system+ iowait，对于 100% 除以 AL 所描述的核心数量的值，我并不是说top100% 有帮助，但它可能是一个非常有用的全能学习工具。
吞吐量将低于最大值，因为您正在解压大量小文件，也称为“随机 IO”。还有一些磁盘同步/缓存刷新，尽管自 2010 年以来，Linux 上每个安装的软件包只有少数几个。 (以前每个文件一个）。
答案4
实际上，与 CPU 操作相比，IO/网络请求确实很慢。这意味着当你的网卡正在获取数据，或者你的磁盘正在写入这些数据时，你的CPU绝对不会做任何事情（无论如何对于这个过程）。
如果您的硬盘驱动器比您的网络连接速度更快（这可能是真的），它写入的内容不会多于它接收的内容。
最后，网络百分比对应于最大可能的网络卡片使用，而不是连接。因此，您可能拥有 1Gb/s 网络适配器，但您实际上不太可能拥有达到此带宽的互联网连接。