我编写了一个测试程序，它只包含一个内部有一些计算的无限循环，并且不执行任何I / O操作。我尝试启动程序的两个实例，一个具有高漂亮度值，另一个具有低漂亮度值：
sudo nice -n 19 taskset 1 ./test
sudo nice -n -20 taskset 1 ./test
taskset命令确保两个程序在同一核心上执行。与我的预期相反，顶级报告称两个程序都获得了大约50％的计算时间。这是为什么？ nice命令是否有效？
您看到的行为几乎可以肯定是因为Linux 2.6.38（2010年）中添加了自动组功能。据推测，当您描述运行这两个命令时，它们在不同的终端窗口中运行。如果你在同一个终端窗口中运行它们，那么你应该看到nice值有效。这个答案的其余部分详细阐述了这个故事。
内核提供了一种称为自动分组的功能，可以在多进程，CPU密集型工作负载（如构建具有大量并行构建过程的Linux内核（即make(1) -j标志））的情况下提高交互式桌面性能。
通过setsid(2)创建新会话时，会创建一个新的自动组;例如，当启动新的终端窗口时会发生这种情况。由fork(2)创建的新进程继承其父级的自动组成员资格。因此，会话中的所有进程都是同一自动组的成员。
启用自动分组时，自动组的所有成员都放在同一个内核调度程序“任务组”中。 Linux内核调度程序采用一种算法来均衡跨任务组的CPU周期分布。可以通过以下示例描述此对交互式桌面性能的好处。
假设有两个自动组竞争相同的CPU（即，假定单个CPU系统或使用taskset(1)将所有进程限制在SMP系统上的同一CPU）。第一组包含来自使用make -j10开始的内核构建的十个CPU绑定进程。另一个包含一个CPU绑定的进程：一个视频播放器。自动分组的效果是两组将分别接收一半的CPU周期。也就是说，视频播放器将获得50％的CPU周期，而不仅仅是9％的周期，这可能会导致视频播放质量下降。 SMP系统上的情况更复杂，但总体效果是相同的：调度程序在任务组之间分配CPU周期，这样包含大量CPU绑定进程的自动组不会以牺牲费用为代价来占用CPU周期系统上的其他工作。
漂亮的价值和团队安排
当调度非实时进程（例如，在默认SCHED_OTHER策略下调度的进程）时，调度器采用称为“组调度”的技术，在该技术下线程被调度在“任务组”中。任务组是在各种情况下形成的，相关案例在这里是自动分组。
如果启用了自动分组，则（隐式）放置在自动组中的所有线程（即，由setsid(2)创建的相同会话）形成任务组。因此，每个新的自动组都是一个单独的任务组。
在组调度下，线程的nice值仅对相对于同一任务组中的其他线程的调度决策有影响。就UNIX系统上的良好价值的传统语义而言，这会产生一些令人惊讶的后果。特别是，如果启用了自动分组（这是各种Linux发行版中的默认设置），则在进程上使用nice(1)仅对相对于在同一会话中执行的其他进程（通常：相同的终端窗口）进行调度有效。
相反，对于两个进程（例如）不同会话中唯一的CPU绑定进程（例如，不同的终端窗口，其每个作业都绑定到不同的自动组），在其中一个会话中修改进程的nice值对调度程序相对于其他会话中的进程的决策没有影响。这可能是您看到的情景，但您没有明确提到使用两个终端窗口。
如果您想阻止自动分组干扰此处所述的传统nice行为，您可以禁用该功能
echo 0 > /proc/sys/kernel/sched_autogroup_enabled
请注意，这也会导致禁用自动组功能旨在提供的桌面交互性的好处（参见上文）。
自动组很好的价值
可以通过文件/proc/[pid]/autogroup查看进程的自动组成员资格：
$ cat /proc/1/autogroup
/autogroup-1 nice 0
此文件还可用于修改分配给自动组的CPU带宽。这是通过在文件的“nice”范围内写入数字来设置autogroup的nice值来完成的。允许的范围是从+19（低优先级）到-20（高优先级）。
autogroup nice设置与process nice值具有相同的含义，但适用于根据其他autogroup的相对漂亮值将CPU周期分配给整个autogroup。对于自动组内的进程，它接收的CPU周期将是自动组的nice值（与其他自动组相比）和进程的nice值（与同一自动组中的其他进程相比）的乘积。
我把test.c放在一起，这样做：
for(;;)
{
}
然后和你的好人一起跑吧。我没有为每个sudo运行不同的sudo，而是sudo一个交互式shell并从那里运行它们。我用了两个。
我有一个./test很难击中我的CPU，而且几乎没有触及它。
当然，该系统仍然感觉非常敏感;在现代处理器上需要大量的CPU占用过程才能获得如此多的负载，您可以“感受”它。
这与I / O占用过程和内存占用过程形成对比;在这些情况下，单个贪婪的过程会使系统使用起来很痛苦。
我猜你的系统有一个相对独特的优先级相关的错误（或微妙），或者你的方法有一些东西。
我在Ubuntu 11.04系统上运行测试。
我假设在命令行的末尾有一个&缺失。否则，第二行将在第一行完成之前运行。
当两个进程都在运行时，使用类似top的东西并确保它们各自具有您分配的好值。
如果仅使用taskset启动进程，然后在运行后使用renice调整优先级，会发生什么？
处理好处（优先级）设置对Linux有影响！ （在实践中，但只有你给它足够的工作！）
在我的系统上，只要所有核心都满载，那么确实会产生影响。在ubuntu 14.04上，使用nice -N运行的进程通过0.807 ** N个操作，而不是在不改变nice值的情况下运行的进程（假设你为每个不错的级别运行每个核心一个实例）。
在我的情况下，我有四核i7超线程关闭，所以如果我运行四个或更少的进程，那么它们的好值是什么并不重要 - 它们每个都得到一个完整的核心。如果我在好的等级12和好的等级12上运行4个过程，那么12等级的过程会通过0.807 ^ 12，即大约7％的工作得到好的等级0。该比率似乎是一个合理的预测器，从好的0到14级，之后它会波动（例如，一些运行的18级处理比16级更好） - 运行测试更长时间可以平滑结果。
（使用ruby 2.1.2）
，cl文件：
uptime
nices='-0 -6 -12 -18'
nices='-0 -18'
nices='-0 -2 -4 -6 -8 -10 -12 -14 -16 -18'
rm -f ,n-*
for i in 1 2 3 4
do
for n in $nices
do
nice $n ruby ,count_loops.rb > ,n${n}-$i &
done
done
ps -l
uptime
wait
uptime
ps -l
c=`cat ,n-0-[1234] | total`
last=$c
for n in $nices
do
echo
c2=`cat ,n${n}-[1234] | total`
echo total of `cat ,n${n}-[1234]` is $c2
echo -n "nice $n count $2, percentage: "
echo "3 k $c2 100 * $c / p" | dc
echo -n " percent of last: "
echo "3 k $c2 100 * $last / p" | dc
last=$c2
done
uptime
echo total count: `cat ,n-*-[1234] | total`
，count_loops.rb文件
#!/usr/bin/env ruby
limit = Time.new + 70
i=0
while Time.new < limit
i += 1
j = 0
while (j += 1) < 10000
t = j
end
end
puts i
sh ,cl的结果 - 初步诊断输出：
19:16:25 up 20:55, 2 users, load average: 3.58, 3.59, 2.88
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 S 1000 4987 4977 0 80 0 - 7297 wait pts/3 00:00:00 bash
0 S 1000 11743 2936 0 80 0 - 2515 wait pts/3 00:00:00 rubymine.sh
0 S 1000 11808 11743 6 80 0 - 834604 futex_ pts/3 00:18:10 java
0 S 1000 11846 11808 0 80 0 - 4061 poll_s pts/3 00:00:02 fsnotifier64
0 S 1000 19613 4987 0 80 0 - 2515 wait pts/3 00:00:00 sh
0 R 1000 19616 19613 0 80 0 - 7582 - pts/3 00:00:00 ruby
0 R 1000 19617 19613 0 82 2 - 7582 - pts/3 00:00:00 ruby
0 R 1000 19618 19613 0 84 4 - 7582 - pts/3 00:00:00 ruby
0 R 1000 19619 19613 0 86 6 - 7416 - pts/3 00:00:00 ruby
0 R 1000 19620 19613 0 88 8 - 6795 - pts/3 00:00:00 ruby
0 R 1000 19621 19613 0 90 10 - 6247 - pts/3 00:00:00 ruby
0 R 1000 19622 19613 0 92 12 - 6247 - pts/3 00:00:00 ruby
0 R 1000 19623 19613 0 94 14 - 6247 - pts/3 00:00:00 ruby
0 R 1000 19624 19613 0 96 16 - 6078 - pts/3 00:00:00 ruby
0 R 1000 19625 19613 0 98 18 - 6012 - pts/3 00:00:00 ruby
0 R 1000 19626 19613 0 80 0 - 7582 - pts/3 00:00:00 ruby
0 R 1000 19627 19613 0 82 2 - 7582 - pts/3 00:00:00 ruby
0 R 1000 19628 19613 0 84 4 - 7582 - pts/3 00:00:00 ruby
0 R 1000 19629 19613 0 86 6 - 7582 - pts/3 00:00:00 ruby
0 R 1000 19630 19613 0 88 8 - 6247 - pts/3 00:00:00 ruby
0 R 1000 19631 19613 0 90 10 - 6247 - pts/3 00:00:00 ruby
0 R 1000 19632 19613 0 92 12 - 6247 - pts/3 00:00:00 ruby
0 R 1000 19633 19613 0 94 14 - 6144 - pts/3 00:00:00 ruby
0 R 1000 19634 19613 0 96 16 - 4971 - pts/3 00:00:00 ruby
0 R 1000 19635 19613 0 98 18 - 4971 - pts/3 00:00:00 ruby
0 R 1000 19636 19613 0 80 0 - 7582 - pts/3 00:00:00 ruby
0 R 1000 19637 19613 0 82 2 - 7449 - pts/3 00:00:00 ruby
0 R 1000 19638 19613 0 84 4 - 7344 - pts/3 00:00:00 ruby
0 R 1000 19639 19613 0 86 6 - 7582 - pts/3 00:00:00 ruby
0 R 1000 19640 19613 0 88 8 - 7416 - pts/3 00:00:00 ruby
0 R 1000 19641 19613 0 90 10 - 6210 - pts/3 00:00:00 ruby
0 R 1000 19642 19613 0 92 12 - 6247 - pts/3 00:00:00 ruby
0 R 1000 19643 19613 0 94 14 - 5976 - pts/3 00:00:00 ruby
0 R 1000 19644 19613 0 96 16 - 6111 - pts/3 00:00:00 ruby
0 R 1000 19645 19613 0 98 18 - 4971 - pts/3 00:00:00 ruby
0 R 1000 19646 19613 0 80 0 - 7582 - pts/3 00:00:00 ruby
0 R 1000 19647 19613 0 82 2 - 7516 - pts/3 00:00:00 ruby
0 R 1000 19648 19613 0 84 4 - 7416 - pts/3 00:00:00 ruby
0 R 1000 19649 19613 0 86 6 - 6247 - pts/3 00:00:00 ruby
0 R 1000 19650 19613 0 88 8 - 6177 - pts/3 00:00:00 ruby
0 R 1000 19651 19613 0 90 10 - 6247 - pts/3 00:00:00 ruby
0 R 1000 19652 19613 0 92 12 - 6078 - pts/3 00:00:00 ruby
0 R 1000 19653 19613 0 94 14 - 6247 - pts/3 00:00:00 ruby
0 R 1000 19654 19613 0 96 16 - 4971 - pts/3 00:00:00 ruby
0 R 1000 19655 19613 0 98 18 - 4971 - pts/3 00:00:00 ruby
0 R 1000 19656 19613 0 80 0 - 3908 - pts/3 00:00:00 ps
19:16:26 up 20:55, 2 users, load average: 3.58, 3.59, 2.88
19:17:37 up 20:56, 3 users, load average: 28.92, 11.25, 5.59
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 S 1000 4987 4977 0 80 0 - 7297 wait pts/3 00:00:00 bash
0 S 1000 11743 2936 0 80 0 - 2515 wait pts/3 00:00:00 rubymine.sh
0 S 1000 11808 11743 6 80 0 - 834604 futex_ pts/3 00:18:10 java
0 S 1000 11846 11808 0 80 0 - 4061 poll_s pts/3 00:00:02 fsnotifier64
0 S 1000 19613 4987 0 80 0 - 2515 wait pts/3 00:00:00 sh
0 R 1000 19794 19613 0 80 0 - 3908 - pts/3 00:00:00 ps
sh ,cl的结果 - 统计数据:(最后一个百分比是该总数的百分比与最后一组进程的计数比较）
total of 99951 101725 100681 104046 is 406403
nice -0 count , percentage: 100.000
percent of last: 100.000
total of 64554 62971 64006 63462 is 254993
nice -2 count , percentage: 62.743
percent of last: 62.743
total of 42997 43041 43197 42717 is 171952
nice -4 count , percentage: 42.310
percent of last: 67.434
total of 26882 28250 27151 27244 is 109527
nice -6 count , percentage: 26.950
percent of last: 63.696
total of 17228 17189 17427 17769 is 69613
nice -8 count , percentage: 17.129
percent of last: 63.557
total of 10815 10792 11021 11307 is 43935
nice -10 count , percentage: 10.810
percent of last: 63.113
total of 7023 6923 7885 7323 is 29154
nice -12 count , percentage: 7.173
percent of last: 66.357
total of 5005 4881 4938 5159 is 19983
nice -14 count , percentage: 4.917
percent of last: 68.542
total of 3517 5537 3555 4092 is 16701
nice -16 count , percentage: 4.109
percent of last: 83.576
total of 4372 4307 5552 4527 is 18758
nice -18 count , percentage: 4.615
percent of last: 112.316
19:17:37 up 20:56, 3 users, load average: 28.92, 11.25, 5.59
total count: 1141019
（纯粹主义者会注意到我正在混合红宝石，贝壳和直流 - 他们将不得不原谅我上世纪的旧习惯;））
我从APUE运行一个示例程序，nice确实有效果。
示例程序主要是fork一个孩子，父母和孩子在给定时间（10s）执行i++增量操作。通过给孩子不同的nice值，结果显示nice是否有所作为。
这本书警告我应该使用单处理器PC运行程序，我尝试使用自己的PC，i5-7500 CPU @ 3.40GHz × 4（4核），给出不同的nice值，几乎没有区别。
然后我登录到我的远程服务器1 processor 1 GB，并获得预期的差异。
1 core processor 1 GB测试结果：
./a.out
NZERO = 20
current nice value in parent is 0
current nice value in child is 0, adjusting by 0
now child nice value is 0
parent count = 13347219
child count = 13357561
./a.out 20 //child nice set to 20
NZERO = 20
current nice value in parent is 0
current nice value in child is 0, adjusting by 20
now child nice value is 19
parent count = 29770491
ubuntu@VM-0-2-ubuntu:~$ child count = 441330
测试程序（我做了一点修改），来自第8.16节，APUE：
apue.h只是一个标题包装器
err_sys()也是一个错误处理程序包装器，你可以暂时使用printf。
#include "apue.h"
#include <errno.h>
#include <sys/time.h>
#if defined(MACOS)
#include <sys/syslimits.h>
#elif defined(SOLARIS)
#include <limits.h>
#elif defined(BSD)
#include <sys/param.h>
#endif
unsigned long long count;
struct timeval end;
void
checktime(char *str)
{
struct timeval tv;
gettimeofday(&tv, NULL);
if (tv.tv_sec >= end.tv_sec && tv.tv_usec >= end.tv_usec) {
printf("%s count = %lld\n", str, count);
exit(0);
}
}
int
main(int argc, char *argv[])
{
pid_t pid;
char *s;
int nzero, ret;
int adj = 0;
setbuf(stdout, NULL);
#if defined(NZERO)
nzero = NZERO;
#elif defined(_SC_NZERO)
nzero = sysconf(_SC_NZERO);
#else
#error NZERO undefined
#endif
printf("NZERO = %d\n", nzero);
if (argc == 2)
adj = strtol(argv[1], NULL, 10);
gettimeofday(&end, NULL);
end.tv_sec += 10; /* run for 10 seconds */
if ((pid = fork()) < 0) {
err_sys("fork failed");
} else if (pid == 0) { /* child */
s = "child";
printf("current nice value in child is %d, adjusting by %d\n",
nice(0), adj);
errno = 0;
if ((ret = nice(adj)) == -1 && errno != 0)
err_sys("child set scheduling priority");
printf("now child nice value is %d\n", ret);
} else { /* parent */
s = "parent";
printf("current nice value in parent is %d\n", nice(0));
}
for(;;) {
if (++count == 0)
err_quit("%s counter wrap", s);
checktime(s);
}
}