为什么apt-get不使用100％（CPU或磁盘或网络）？

21

为什么不使用100％的cpu，磁盘或网络，甚至apt-get 不使用它？即使在较慢的系统（Raspberry Pi 2+）上，我最多也只能获得30％的CPU负载。我只是想，无论它是被人为扼杀，或者它应该最大程度的发挥的东西，而它的工作...或者它应该是能够做到的事情比它更快。

编辑：我只是通过面板中的cpu / disk / net监视器以及Ubuntu MATE的System Monitor应用程序进行粗略的测量。

请解释为什么我错了。:-)

更新：我知道apt-get需要获取其更新（并且可能受上游/提供商带宽的限制）。但是一旦“解包”等等，CPU使用率至少应该上升（如果不是最大）。在我相当不错的家庭工作站上，它不是这样，而是将SSD用作主驱动器，并将ramdisk用于/ tmp。

或者，也许我需要仔细看看。

apt cpu-usage

— 克莱门DK
source

您如何测量磁盘和网络负载？

— JigglyNaga

1

磁盘IO就像网络IO一样。它仍然会阻止该应用程序，从而阻止其使用CPU。las，apt-get不是特别擅长对此进行优化。我想它可以在下载时安装，这样，在下载完成时，大多数有效负载就可以安装了，但是不幸的是，它还没有安装。无论如何，独立安装大多只是将数据提取到磁盘。这些操作本质上是受IO约束的，除了要等待磁盘驱动器完成读取或写入操作之外，没有其他事情要做。

— PSkocik's

您是如何获得30％CPU负载数的？

— AL

1

@PSkocik“我想它可以在下载时安装” apt-get只需下载，dpkg即可安装。dpkg比apt-get聪明，因为应该安装一堆软件包，而apt-get可能与下载它们不同。

— Braiam '16

请注意，一个应用程序被CPU绑定了100％的时间是一个勾号，然后是100％IO绑定的另一半的应用程序既不会出现CPU绑定，也不会出现IO绑定。

— MSalters

28

仅当应用程序受CPU限制时，应用程序才会使CPU占用最大内存。如果一个应用可以快速获取所有数据，并且等待处理器处理数据，则该应用受CPU限制。

apt-get另一方面，是IO绑定的。这意味着它可以相当快地处理其数据，但是（从磁盘或从网络）加载数据需要花费时间，在此期间，处理器可以执行其他工作，或者在不需要其他进程的情况下使其处于空闲状态。

通常，所有IO请求（磁盘，网络）都很慢，并且每当应用程序线程创建一个IO请求时，内核就会将其从处理器中删除，直到将数据加载到内核中为止（这些IO请求称为阻塞请求）。

— PSkocik
source

6

使用apt命令会使许多文件以同步模式打开，或者频繁请求对磁盘进行显式刷新以确保磁盘上的数据保持一致状态，从而使系统崩溃可能导致严重后果，这一事实使情况更加恶化。运行apt与命令eatmydata通常会显着改善的可靠性降低为代价的性能（更不用提服务开始作为安装包的一部分，将继承eatmydata设置）

— 斯特凡Chazelas

大声笑在最后一点:)。自2010年提交bugs.debian.org/cgi-bin/bugreport.cgi以来，没有人有eatmydata的编号吗？bug = 578635？我不知道“戏剧性地”是否仍然是正确的词。

— sourcejedi

嗯，也许是（至少在某些云提供商上）bugs.launchpad.net/cloud-init/+bug/1236531/comments/6

— sourcejedi

1

@sourcejedi在具有相对高端SD卡（但仍然是SD卡，而不是高端SSD）的Raspberry Pi2上，我认为“戏剧性地”有点轻描淡写。dpkg在闪存介质上的性能确实很差。

— 吉尔（Gilles）'所以

1

如果它是受磁盘IO约束的，那么为什么不使用100％磁盘带宽？

— user253751 '16

15

即使在较慢的系统（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％。

这是我在运行Ubuntu的8核（带有Hyper-Threading的 4核）计算机上的示例，我使用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%列中的值为，这是因为该命令是相对于一个内核而不是相对于所有内核的。

— 铝
source

+1，接近％（100 / nCores）倍数的使用率应始终触发进一步检查。可以使用能够显示每个内核使用情况的监视器来检查-并且实际上是排除了这一点，其中0 <=％％<= 100 * nCores

— underscore_d

/dev/zero > /dev/null因为urandom会耗尽熵池，这不是更好的例子吗？

— 菲利普·哈格隆德

@FilipHaglund cat /dev/zero > /dev/null给出了相同的结果，我不知道该设备，谢谢。urandom会耗尽熵池我不知道熵池，这怎么可能是个问题？

— AL

1

当程序使用加密时，它们需要真正随机的数据来生成安全的加密密钥。计算机通过观察鼠标的移动来产生熵。有硬件随机数生成器，但是大多数计算机没有。如果熵全部用完，则需要安全熵的代码必须等待生成更多信息。如果可用，Urandom将使用真正的随机位，否则将返回安全性较低的随机位。

— 菲利普·哈格隆德

当程序使用加密时即使我认为没有人会在生成随机密钥的同时执行CPU基准测试，但为了预防起见，我已经更新了答案。

— AL

2

我认为您实际上不是在测量IO％。我还没有看到Linux IO％小部件。（我非常羡慕Windows 10任务管理器:)。使用iotop命令检查，您将看到100％IO。

top应该在user+ system+上显示100％iowait，对于100％的值除以AL所述的核心数量，我并不是说top100％有帮助，但是它可以是一个非常有用的全方位学习工具。

吞吐量将低于最大值，因为您要解压缩许多小文件，也就是“随机IO”。还有一些磁盘同步/缓存刷新，尽管自2010年以来在Linux上，每个安装的软件包只有少数几个。（以前是每个文件一个）。

— Sourcejedi
source

使用时iotop --only，该--only选项仅显示实际执行I / O的进程或线程。

— AL

4

iostat，dstat，atop ...将显示每个磁盘的磁盘利用率，而无需特权。这对每个任务使用，你需要的权限

— 斯特凡Chazelas

@StéphaneChazelas绝对正确。我试图说明的内容（忍者编辑）是OP提到了几个GUI工具。我见过的特定GUI工具（例如Gnome System Monitor）显示了吞吐量，但没有IO％。

— sourcejedi

2

实际上，与CPU操作相比，IO /网络请求确实很慢。这意味着，当您的网卡正在获取数据或磁盘正在写入此数据时，CPU绝对不会执行任何操作（无论如何，对于此过程）。

如果您的硬盘驱动器比网络连接要快（这可能是正确的），那么它所写入的内容不会超过收到的内容。

最后，网络百分比对应于最大可能的网卡使用量，而不是连接数。因此，您可能有一个1Gb / s的网络适配器，您实际上不太可能拥有达到此带宽的Internet连接。

— Aymeric R.
source