在systemd服务文件中，可以设置以下与调度相关的选项（来自systemd.exec手册页， 如我错了请纠正我）：
好的 设置执行进程的默认良好级别（调度优先级）。采用 -20（最高优先级）和 19（最低优先级）之间的整数。看设置优先级(2)了解详情。
这是熟悉的好级别。由于最近 Linux 内核的“自动分组”功能，它的效果似乎在某种程度上被“颠覆”了。因此，下面的选项可能是我真正想要设置的选项，以保持进程在我的桌面体验中表现良好。
CPU调度策略 设置执行进程的CPU调度策略。采用其他之一：batch、idle、fifo 或 rr。看sched_setscheduler(2)了解详情。
CPU调度优先级 设置已执行进程的 CPU 调度优先级。可用的优先级范围取决于所选的CPU调度策略（见上文）。对于实时调度策略，可以使用 1（最低优先级）和 99（最高优先级）之间的整数。看sched_setscheduler(2)了解详情。
CPUSchedulingResetOnFork 采用布尔参数。如果为 true，则当执行的进程分叉时，提升的 CPU 调度优先级和策略将被重置，因此不会泄漏到子进程中。看sched_setscheduler(2)了解详情。默认为 false。
我理解最后一个选项。我从前两个的解释中得知，我可以选择一个调度策略，然后根据该策略选择一个优先级。我并不完全清楚我应该为哪种任务选择什么。例如，为备份任务选择“空闲”是否安全（相对 CPU 密集型，因为重复数据删除），还是另一种更适合？
总的来说，我所寻求的是对每项政策、每项优先事项以及对特定目的的适用性有一个可理解的概述。与漂亮关卡的互动也很有趣。
除了CPU调度之外，还有IO调度。我想这对应于ionice（如果我错了请纠正我）。
IOS调度类 设置已执行进程的 I/O 调度类。采用 0 到 3 之间的整数或 none、realtime、best-effort 或idle 字符串之一。看ioprio_set(2)了解详情。
IOS调度优先级 设置已执行进程的 I/O 调度优先级。采用 0（最高优先级）和 7（最低优先级）之间的整数。可用优先级取决于所选的 I/O 调度类别（见上文）。看ioprio_set(2)了解详情。
我们在这里看到与 CPU 调度相同的结构。我也在寻找同样类型的信息。
对于所有“调度”选项，所引用的手册页对我来说不够清晰，主要是将内容转换为有点技术倾向的桌面用户的观点。
答案1
CPUScheduling{策略|优先级}
该链接告诉您应该只为或（“实时”）任务CPUSchedulingPriority设置。您不想强制对服务进行实时调度。fiforr
CPUSchedulingPolicy=other是默认值。
那留下batch和idle。仅当您有多个空闲优先级任务同时消耗 CPU 时，它们之间的差异才有意义。理论上batch可以提供更高的吞吐量（以换取更长的延迟）。但这并不是一个大胜利，因此在这种情况下它并不真正相关。
idle如果还有其他东西想要CPU，那么它就会挨饿。对于具有单核的旧 UNIX 系统，CPU 优先级的重要性已不如以前。nice在诉诸 之前，我会更高兴从 开始，例如不错的 10 级或 14 级idle。请参阅下一节。
然而，大多数台式机在大多数时间都相对空闲。当您确实有一个 CPU 占用者会抢占后台任务时，该占用者通常只使用您的一个 CPU。考虑到这一点，我不会觉得idle在普通台式机或笔记本电脑上使用有太大风险。除非它具有 Atom / Celeron / ARM CPU 额定值等于或低于约 15 瓦;那么我想更仔细地看待事情。
内核“自动组”功能是否“颠覆”了nice级别？
是的。
自动分组有点奇怪。作者systemd不喜欢启发式，即使对于桌面也是如此。如果你想测试禁用自动分组，你可以设置系统控制 kernel.sched_autogroup_enabled到0。我想最好通过将 sysctl 设置为永久配置并重新启动来进行测试，以确保摆脱所有自动组。
那么您应该能够毫无问题地提供良好的服务水平。至少在当前版本的 systemd 中 - 请参阅下一节。
例如，nice level 10 会将 Linux CPU 调度程序中每个线程的权重减少到大约 10%。尼斯14级低于5%。 （关联：完整配方）
附录：nice 级别是否被 systemd cgroups “颠覆”了？
目前的DefaultCPUAccounting= 环境默认为关闭，除非可以在不启用每个服务的 CPU 控制的情况下启用它。所以应该没问题。您可以在当前文档中检查这一点：man systemd-system.conf
请注意，每服务 CPU 控制也将在以下情况下启用：任何服务集 CPUAccounting / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUShares。
以下博客摘录已过时（但仍然在线）。此后默认行为已更改，参考文档也已相应更新。
作为一个不错的默认设置，如果在内核中启用了 cpu 控制器，systemd 会在启动时为每个服务创建一个 cgroup。无需任何进一步的配置，这已经产生了一个很好的效果：在 systemd 系统上，每个系统服务都将获得均匀数量的 CPU，无论它包含多少个进程。或者换句话说：在您的 Web 服务器上，MySQL 将获得与 Apache 大致相同数量的 CPU，即使后者包含 1000 个 CGI 脚本进程，但前者只包含几个工作任务。 （可以关闭此行为，请参阅 /etc/systemd/system.conf 中的 DefaultControllers=。）
除了此默认值之外，还可以使用 CPUShares= 设置显式配置服务获取的 CPU 份额。默认值为 1024，如果增加此数字，您将比未更改的 1024 为服务分配更多的 CPU，如果减少该数字，则会更少。
答案2
经典的性能调整建议是“不要优化，基准测试”。
不要关心一般建议，而是从您关心的改进并已进行基准测试的具体案例开始具体的性能问题。让数据让你按照正确的指令进行调整。通过数据，可以清楚地看出您的进程是否遇到优先级较低、占用 CPU 或存在其他问题的情况。
现代台式机通常运行速度很快，无需任何调整。