nice和renice用于调整进程优先级，niceness值从-20到19，值越低优先级越高，影响CPU时间分配，普通用户只能调高自身进程优先级，root可任意调整，通过ps、top或/proc查看，renice修改运行中进程优先级，需谨慎操作避免系统不稳定。
Linux系统里，
nice和
renice命令是用来调整进程运行优先级的，说白了，就是告诉操作系统，哪些任务更重要，可以多给点CPU时间，哪些不那么急，可以放慢点跑。
nice用来启动一个新进程时设定其优先级，而
renice则是针对已经在运行的进程进行优先级调整。这对于管理系统资源，确保关键服务流畅运行，同时又不至于让后台任务把系统拖垮，简直是必备技能。
解决方案
在我看来，掌握
nice和
renice，核心在于理解“niceness”这个概念。它不是直接指定CPU占用百分比，而是一个相对的优先级值，范围从 -20（最高优先级，最“不nice”）到 19（最低优先级，最“nice”）。默认情况下，大多数进程的niceness值是 0。这个值越大，进程就越“nice”，意味着它会更礼貌地让出CPU时间给其他进程；值越小，就越“不nice”，它会更积极地抢占CPU。
nice
命令的使用
当你需要启动一个耗时但非紧急的任务时，比如一个大数据分析脚本或者文件备份，就可以用
nice来降低它的优先级。这样它就不会霸占所有CPU资源，影响你正在使用的交互式应用。
基本语法：
nice -n<要执行的命令>
举个例子，我要备份一个大目录，但不想让它拖慢我的开发环境：
nice -n 15 tar -zcvf /backup/my_data.tar.gz /home/user/data
这里，
tar命令会以 niceness 值 15 运行，这意味着它会比默认优先级的进程获得更少的CPU时间。如果你不指定
-n参数，
nice默认会以 niceness 值 10 启动命令。
需要注意的是，普通用户只能将 niceness 值调高（即降低优先级，让进程更“nice”）。如果你想把 niceness 值调低（提高优先级，让进程更“不nice”），那就需要
root权限。这是为了防止普通用户恶意地启动高优先级进程，从而导致系统资源被滥用。
renice
命令的使用
有时候，一个进程已经跑起来了，你才发现它太占用资源，或者它突然变得很重要，需要更高的优先级。这时
renice就派上用场了。
基本语法：
renice或者针对某个用户的所有进程：-p <进程ID>
renice或者针对某个组的所有进程：-u <用户名>
renice-g <组名>
比如，我发现一个名为
data_processor的程序（PID是 12345）正在疯狂消耗CPU，我想把它优先级调低一点：
renice 10 -p 12345
同样地，
renice的权限规则和
nice类似：普通用户只能调高自己进程的 niceness 值，
root用户可以调整任何进程的 niceness 值，包括调低。
在我日常工作中，这俩命令简直是救星。比如，跑一个大型的
make -jN编译任务，如果直接跑，我的桌面环境可能就卡死了。但如果
nice -n 10 make -jN，那感觉就完全不一样了，编译照常进行，我还能流畅地写代码、查文档。
Linux进程优先级如何影响系统性能？
进程优先级，或者说我们这里的niceness值，它直接影响的是Linux内核调度器（scheduler）如何分配CPU时间片。你可以把CPU想象成一个非常忙碌的医生，而进程就是排队看病的病人。优先级高的病人，医生会优先看他，或者给他更长的诊疗时间。
当系统中有多个CPU密集型进程同时运行时，调度器会根据它们的优先级来决定谁获得CPU的使用权，以及获得多长时间。一个低niceness值（高优先级）的进程，会比高niceness值（低优先级）的进程获得更多的CPU时间片，或者更频繁地被调度执行。这意味着它能够更快地完成计算任务。
这种机制对系统性能的影响是显而易见的。如果你有一个交互式的桌面环境或者一个对外提供服务的Web服务器，它们的响应速度对用户体验至关重要。如果此时一个后台数据分析任务以默认甚至更高的优先级运行，它可能会抢占大量CPU资源，导致你的桌面卡顿，或者Web服务器响应变慢，用户会明显感觉到延迟。
反之，如果我们将这些后台任务的优先级调低（提高niceness值），它们就会“礼让”给前端应用和服务，从而保证了交互式体验和服务的可用性。这并不是说低优先级的进程就完全不运行了，而是它会在高优先级进程不那么忙碌的时候，或者在它被调度器“轮到”的时候，获得CPU时间。整个系统的吞吐量可能不会有太大变化，但用户感知的响应速度会截然不同。所以，这更多是一种“公平”的调度策略，确保关键任务能及时响应，非关键任务也能有序推进。
nice
值与实际CPU使用率有何关联？
这里有个常见的误解，就是认为
nice值直接限制了进程的CPU使用率，比如 niceness 19 的进程就只能用 5% 的CPU。但事实并非如此。
nice值影响的不是进程能用的CPU百分比上限，而是当多个进程竞争CPU资源时，调度器如何分配这些资源。它是一种相对的优先级，而不是绝对的资源限制。
举个例子，如果你的系统上只有一个CPU密集型进程在运行，即使它的 niceness 值是最高的 19，它仍然会占用几乎 100% 的CPU。因为没有其他进程来和它竞争，调度器自然就会把所有可用的CPU时间都给它。
但是，一旦有另一个进程（比如一个 niceness 值为 0 的进程）也开始竞争CPU，那么 niceness 值为 0 的进程就会获得更多的CPU时间片，而 niceness 值为 19 的进程获得的CPU时间就会相应减少。你可以想象成一个蛋糕，高优先级的进程能分到更大块，低优先级的进程只能分到小块。但如果只有一个人吃蛋糕，无论他优先级高低，他都能吃掉整个蛋糕。
所以，
nice值与实际CPU使用率的关联是间接的、相对的。它在多任务并发的场景下才真正体现出其价值。在
top或
htop这样的工具里，你可能会看到一个高 niceness 值的进程CPU使用率较低，那通常是因为有其他更高优先级的进程正在活跃地使用CPU。如果那些高优先级进程进入等待状态（比如等待I/O），那么低优先级的进程就有机会获得更多的CPU时间，其CPU使用率也可能暂时飙升。这正是调度器在动态平衡的结果。
如何查看和修改运行中进程的nice
值？
要查看一个正在运行进程的
nice值，有几种常用的方法，都非常直观：
1. 使用 ps
命令：
ps -l可以列出当前终端下所有进程的详细信息，其中
NI列就是 niceness 值。
ps -eo pid,ni,cmd这种方式更简洁，只显示进程ID、niceness值和命令。 例如：
ps -eo pid,ni,cmd | grep "my_process"
2. 使用 top
或 htop
命令：
这是我最常用的方法，实时性强。
直接在终端输入
top或
htop，你会看到一个动态更新的进程列表。在
top的输出中，
NI列就显示了每个进程的 niceness 值。
htop同样有
NI列，而且界面更友好，支持鼠标操作。
3. 查看 /proc
文件系统：
每个运行中的进程在
/proc目录下都有一个对应的子目录，以进程ID命名。进程的详细信息存储在这些目录下的文件中。 要查看特定进程（例如PID为 12345）的 niceness 值，可以查看
/proc/12345/stat文件。这个文件包含了大量进程状态信息，niceness 值通常在第 18 个字段。
cat /proc/12345/stat | awk '{print $18}'
修改运行中进程的nice
值：
修改运行中进程的
nice值，就得用到前面提到的
renice命令。
针对单个进程：
renice <新的niceness_值> -p <进程ID>例如，我发现我的
nginx进程（PID 54321）偶尔会响应慢，我想稍微提高它的优先级（降低 niceness 值），让它更“不nice”一点：
sudo renice -5 -p 54321这里我用了
sudo，因为我将 niceness 值从默认的 0 降到了 -5，这需要
root权限。
针对某个用户的所有进程：
renice <新的niceness_值> -u <用户名>比如，我发现用户
devuser启动了太多高CPU占用的进程，我想把他的所有进程优先级都调低一点：
sudo renice 10 -u devuser
针对某个组的所有进程：
renice <新的niceness_值> -g <组名>这个不常用，但当某个组的用户共享资源，需要统一管理时会有用。
在使用
renice时，我个人会特别小心。如果你不清楚一个进程的重要性，随意调低它的 niceness 值（提高优先级）可能会导致系统不稳定，甚至卡死。比如，不小心把系统关键进程（如
systemd或
kworker）的 niceness 值调得过低，可能会让它们过度抢占资源，导致其他服务无法正常运行。反之，如果把一个关键服务的 niceness 值调得过高（降低优先级），服务响应会变慢，甚至超时。所以，在生产环境中操作，一定要慎之又慎，最好先在测试环境验证。
