CPU 和 IO 具有不同进程优先级的用例？

Question

Linux 进程可以有不同的 CPU 和 IO 优先级（nice 和 ionice）。

为什么需要有不同的 CPU 和 IO 优先级？

让它们不同是否有任何现实世界的用法？

您发现哪些实际用例需要不同的 CPU 和 IO 优先级？例如高于正常 CPU 优先级但低于正常 IO 优先级，反之亦然。

Answer 1

'nice' 的默认行为是在 niceness 发生变化时也调整应用程序的 'io' 优先级。

当然，一切都取决于您的工作负载，但任何操作系统的关键方面之一是它如何分配资源以及如何处理争用。

了解 niceness 的作用实际上很重要，因为当来自竞争进程的负载不足时，操作系统的行为方式可能会对您的其余工作负载产生影响。

竞争是衡量不同应用程序如何竞争相同资源（如 CPU）的度量。

搬运负载

自从引入了完全公平的调度程序以来，nice 只是每个进程的“权重”子句的前端。可以在proc中查看。

$ cat /proc/self/sched
---------------------------------------------------------
...
se.load.weight                     :                 1024
...

改变niceness只会改变权重：

$ nice -n 5 cat /proc/self/sched 
---------------------------------------------------------
...
se.load.weight                     :                 335
...

CPU争用的测量是由完全公平的调度算法完成的。每个应用程序都分配了一个“权重”值，在竞争 CPU 时间的情况下，通过合计所有竞争 CPU 时间的处理并根据它们的权重值为它们分配最低通用面额 CPU 时间，从而在进程之间分配时间。

如果我有 3 个应用程序都想使用 CPU 时间，默认情况下它们会收到 1024 作为正常权重。如果我有一个像上面一样 +5 的进程，那么所有三个权重的总和为 2383，如果所有 3 个进程在那一秒都要求 CPU，那么在给定的一秒内，niced 进程将获得大约 15% 的 CPU 时间.

为什么需要有不同的 CPU 和 IO 优先级？

Niceness 真的只是在系统负载不足时玩什么，也就是说 - 操作系统如何根据任何必要因素的定义在竞争进程之间分配时间。

这如何影响您或与您相关取决于不同应用程序彼此之间的交付优先级以及交付每个应用程序应具有的时间。

美好的事物真的只有做东西时，你的系统负载下（还有更多的东西想关注的莫过于CPU或者硬盘可以处理）。它只是指示内核在这些情况下如何分配资源。

让它们不同是否有任何现实世界的用法？

如果您有许多相互竞争的进程或要完成的工作，而 CPU 无法完成，那么 niceness 可以为您提供一些相对稳定的保证，即哪些工作最先完成。如果您说生成的报告应该在另一份报告完成之前交付，这对您来说可能很重要。

在桌面系统上，友好性甚至更为重要。某些应用程序具有实时行为，即在加载期间更频繁地唤醒它们以防止数据过时。例如，Pulseaudio 就属于这一类。

可能需要其他应用程序来为相关应用程序分配工作。例如，很多 apache 请求说像 MySQL 这样的 SQL 服务器可能会阻塞很长时间，因为 SQL 的服务速度不够快，因为 - 说其他一些报告正在争夺 CPU 时间。因此，不仅 SQL 停滞不前，Apache 也停滞不前。SQL 有时会在这里受到伤害，因为工作线程通常比作为一个组竞争的 apache 线程少得多，调度程序更有利地权衡，因此为 SQL 提供更多的 CPU 时间可以使事情变得更加平衡。

UpdateDB（一个为文件编制索引的程序）在深夜运行并且占用大量磁盘空间。降低其 IO 调度优先级可能很有用，以便当时的其他应用程序优先于在事物顺序中不那么重要的事物。

您发现哪些实际用例需要不同的 CPU 和 IO 优先级？

很少。善良是一种尽力而为的方法。作为一个经验法则，我不太关心应用的表现如何，以及 更多关于他们如何严重可能执行。乍一听这可能是倒退，但我有服务交付保证要满足，这对我来说更重要。

我希望有信心说“即使在糟糕的一天，您的工作也会在 X 时间段内完成”。如果它走得更快，那只是一个奖励。

我通常会从生成商定的规范开始，例如：

• 所有 Web 应用程序都保证在 0.3 秒内完成请求。
• 系统上的所有 SQL 请求都保证在 0.1 秒内完成。
• Web 应用程序应处理不超过 50 IOPS 并交付 1k 文件。
• Web 应用程序内存占用总量不超过 250Mb。

并提出满足以下要求的要求：

• 所有 Web 请求应在 0.05 秒内完成。
• 所有 SQL 请求应在 0.02 秒内完成。
• 应该有足够的内存来处理所有请求。
• 应满足 IO 要求。

如果规范是真实的，我就可以在不进行虚拟化的情况下使用更有效的控制组方法来实现这些目标。

如果应用程序在指定的边界内运行，控制组让我可以为资源分配做出非常可靠的服务级别保证。这意味着即使在负载下的系统上，我也可以保证相关应用程序的资源可用性，并保证同一台机器上其他应用程序的空间！

如果我们以您的 CPU 和 IO 为例。我设置了满足这些要求的限制：

# cd /sys/fs/cgroup/blkio/apache
# echo "253:0 100" >blkio.throttle.read_iops_device 
# echo "253:0 50" >blkio.throttle.write_iops_device 
# echo "253:0 102400" >blkio.throttle.read_bps_device

所以 100k 字节读取 100 iops。

# cd /sys/fs/cgroup/cpu/apache
# echo 1000000 >cpu.cfs_period_us
# echo 60000 >cpu.cfs_quota_us 

在 1 秒的时间段中，提供 0.06 秒的 CPU。

# cd /sys/fs/cgroup/cpu/sql
# echo 1000000 >cpu.cfs_period_us
# echo 20000 >cpu.cfs_quota_us

在 1 秒的时间段中，提供 0.02 秒的 CPU。

提供其他竞争的 cgroup 不会做任何愚蠢的事情，负载不足对我的服务交付来说不是一个因素，因为我知道每个应用程序的 CPU 是如何被抛出的。

这种性质的控制组仍然是尽力而为，但他们对这种努力提供的控制远远超过友善和离子化。