在桌面环境中使用和理解与 systemd 调度相关的选项

Question

在 systemd 服务文件中，可以设置以下与调度相关的选项（来自systemd.exec手册页，如果我错了，请纠正我）：

Nice 为执行的进程设置默认的 nice 级别（调度优先级）。取一个介于 -20（最高优先级）和 19（最低优先级）之间的整数。有关详细信息，请参阅setpriority(2)。

这是熟悉的nice级别。由于最近的 linux 内核的“自动分组”功能，它的效果似乎在某种程度上被“颠覆”了。所以下面的选项可能是我真正想要设置的，以保持进程在我的桌面体验中表现良好。

CPUSchedulingPolicy 为执行的进程设置 CPU 调度策略。采用其他、批处理、空闲、fifo 或 rr 之一。有关详细信息，请参阅sched_setscheduler(2)。

CPUSchedulingPriority 设置已执行进程的 CPU 调度优先级。可用的优先级范围取决于所选的 CPU 调度策略（见上文）。对于实时调度策略，可以使用 1（最低优先级）和 99（最高优先级）之间的整数。有关详细信息，请参阅sched_setscheduler(2)。

CPUSchedulingResetOnFork 采用布尔参数。如果为 true，当执行的进程分叉时，提升的 CPU 调度优先级和策略将被重置，因此不会泄漏到子进程中。有关详细信息，请参阅sched_setscheduler(2)。默认为假。

我理解最后一个选项。我从前两个的解释中了解到，我可以选择一个调度策略，然后根据该策略，选择一个优先级。我并不完全清楚我应该为哪种任务选择什么。例如，为备份任务选择“空闲”是否安全（相对 CPU 密集型，因为重复数据删除），还是另一种更适合？

总的来说，我正在寻找对每项政策、每项优先事项和针对特定目的的适用性的易于理解的概述。与nice级别的交互也很有趣。

除了 CPU 调度，还有 IO 调度。我想这对应于ionice（如果我错了，请纠正我）。

IOSchedulingClass 为执行的进程设置 I/O 调度类。采用 0 到 3 之间的整数或字符串 none、realtime、best-effort 或 idle 之一。有关详细信息，请参阅ioprio_set(2)。

IOSchedulingPriority 设置已执行进程的 I/O 调度优先级。取一个介于 0（最高优先级）和 7（最低优先级）之间的整数。可用的优先级取决于所选的 I/O 调度类（见上文）。有关详细信息，请参阅ioprio_set(2)。

我们在这里看到与 CPU 调度相同的结构。我也在寻找同样的信息。

对于所有“调度”选项，所引用的手册页对我来说还不够清楚，主要是将事情翻译成有点技术倾向的桌面用户的观点。

Answer 1

CPU调度{策略|优先级}

该链接告诉您CPUSchedulingPriority应该只为fifo或rr（“实时”）任务设置。您不想强制对服务进行实时调度。

CPUSchedulingPolicy=other 是默认值。

那离开batch和idle。只有当您有多个空闲优先级任务同时消耗 CPU 时，它们之间的区别才有意义。理论上batch提供更高的吞吐量（以换取更长的延迟）。但这不是一个大胜利，所以在这种情况下它并不重要。

idle如果其他任何东西想要 CPU，它实际上会饿死。对于具有单核的旧 UNIX 系统，CPU 优先级的重要性不如以前重要。我会更开心开头nice，如漂亮10级或14，诉诸之前idle。见下一节。

然而，大多数桌面在大部分时间都相对空闲。当你确实有一个 CPU 猪可以抢占后台任务时，猪只使用你的一个 CPU 是很常见的。考虑到这一点，我不会觉得idle在普通台式机或笔记本电脑的环境中使用风险太大。除非它的 Atom/Celeron/ARM CPU 额定功率等于或低于 15 瓦；那么我会想更仔细地看待事情。

内核“自动分组”功能是否“颠覆”了不错的级别？

是的。

自动分组有点奇怪。systemd即使对于台式机，作者也不喜欢启发式方法。如果要测试禁用自动分组，可以将sysctl 设置kernel.sched_autogroup_enabled为0. 我想最好通过在永久配置中设置 sysctl 并重新启动来进行测试，以确保您摆脱所有自动组。

然后，您应该能够毫无问题地为您的服务提供良好的水平。至少在当前版本的 systemd 中 - 请参阅下一节。

例如，nice level 10 会将每个线程在 Linux CPU 调度程序中的权重减少到大约 10%。Nice 14 级低于 5%。（链接：完整公式）

附录：systemd cgroups 是否“颠覆”了不错的级别？

当前DefaultCPUAccounting= 设置默认为关闭，除非可以在不启用每个服务的 CPU 控制的情况下启用它。所以应该没问题。您可以在当前文档中查看：man systemd-system.conf

请注意，当任何服务设置 CPUAccounting / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUShares时，也会启用每个服务的 CPU 控制。

以下博客摘录已过时（但仍处于在线状态）。此后默认行为已更改，并且参考文档已相应更新。

作为一个很好的默认设置，如果在内核中启用了 cpu 控制器，systemd 将在启动时为每个服务创建一个 cgroup。没有任何进一步的配置，这已经有一个很好的效果：在 systemd 系统上，每个系统服务都将获得相等数量的 CPU，无论它由多少个进程组成。或者换句话说：在您的 Web 服务器上，MySQL 将获得与 Apache 大致相同数量的 CPU，即使后者包含 1000 个 CGI 脚本进程，但前者仅包含几个工作任务。（可以关闭此行为，请参阅 /etc/systemd/system.conf 中的 DefaultControllers=。）

除了此默认设置之外，还可以使用 CPUShares= 设置显式配置服务获取的 CPU 份额。默认值是 1024，如果你增加这个数字，你会比未改变的 1024 分配更多的 CPU 给服务，如果你减少它，更少。

http://0pointer.de/blog/projects/resources.html

Answer 2

经典的性能调整建议是“不要优化，基准测试”。

不要关心一般建议，而是从您关心的改进的特定案例开始，并且已经过基准测试以了解特定的性能问题。让数据让你按照正确的指令进行调整。通过数据，可以清楚地看出您的进程是否遇到优先级较低、占用 CPU 或存在其他问题的情况。

现代台式机通常运行速度很快，无需任何调整。