在桌面环境中使用和了解与系统调度有关的选项

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

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

这是熟悉的不错的水平。由于最近的Linux内核具有“自动分组”功能，因此其效果似乎已“被颠覆”。因此，以下选项可能是我真正想要设置的选项，以使进程保持良好的桌面体验。

CPUSchedulingPolicy 设置已执行进程的CPU调度策略。采用其他，批处理，空闲，fifo或rr中的一种。有关详细信息，请参见sched_setscheduler（2）。

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

CPUSchedulingResetOnFork 采用布尔参数。如果为true，则将在执行的进程派生时重置提升的CPU调度优先级和策略，因此不会泄漏到子进程中。有关详细信息，请参见sched_setscheduler（2）。默认为false。

我了解最后的选择。从前两个方面的解释中可以得出，我可以选择一个调度策略，然后根据该策略确定优先级。对我来说，尚不清楚我应该为哪种任务选择什么。例如，为备份任务选择“空闲”是否安全（因为要进行重复数据删除，因此占用大量CPU，还是比较安全）？

总的来说，我想要的是对每个策略都有一个易于理解的概述，以及每个策略的优先级和针对特定目的的适用性。同样，与尼斯水平的相互作用也是令人感兴趣的。

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

IOSchedulingClass 设置已执行进程的I / O调度类。取0到3之间的整数，或者取值为none，实时，最大努力或空闲字符串之一。有关详细信息，请参见ioprio_set（2）。

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

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

对于所有的“计划”选项，所指的手册页对我来说还不够清楚，主要是在将内容翻译成某种程度上具有技术倾向的台式机用户的观点。

CPUScheduling {Policy | Priority}

该链接告诉您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中-请参阅下一节。

例如，级别10可以将Linux CPU调度程序中每个线程的权重降低到大约10％。等级14低于5％。（链接：完整公式）

附录：尼斯级别是否被systemd cgroup“颠覆”？

当前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，如果增加此数字，则将为服务分配的CPU数量要比未更改的1024多，如果减少，则分配的CPU数量将更少。

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

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

不必担心一般建议，而是从您关心的改进的特定案例开始，并针对特定的性能问题进行基准测试。让数据让您对正确的指令进行调整。有了数据，就可以很清楚地知道您的进程是否遭受了错误的优先级，正在占用CPU或存在其他问题。

现代台式机通常无需任何调整即可快速运行。