nice值是内核调度中对static_prio的偏移量（-20~+19），值越小优先级越高；它仅影响CFS权重计算，不改变实时策略，且普通用户只能调高（降低优先级）。
什么是 nice 值，它真能“让出 CPU”吗？
nice 值不是优先级数字本身，而是对内核调度器中 static_prio 的偏移量（范围 -20 到 +19），值越小，进程实际获得的 CPU 时间越多。但要注意：nice 仅影响 CFS（Completely Fair Scheduler）下的权重计算，不改变实时调度策略（SCHED_FIFO/SCHED_RR）；普通用户只能调高 nice 值（即降低优先级），不能调低（除非有 CAP_SYS_NICE 权限或在 /proc/sys/kernel/nice 允许范围内）。
-
nice值为 0 是默认基准，nice -n 10 cmd启动的进程会比同批其他普通进程更“谦让” - 内核真正使用的是
weight = 1024 / (1.25 ^ nice)这类指数映射，所以 nice 差 5，权重差约 3 倍 - 不要指望
nice 19让进程“几乎不跑”——它仍能抢到时间片，只是概率极低；阻塞、IO 等待仍是主要耗时来源
用 nice 启动进程时最常踩的三个坑
- 直接写
nice 15 myscript.sh：这会让 shell 自身以 nice=15 运行，而子进程继承的是 shell 的 nice（通常是 0），正确写法是 nice -n 15 ./myscript.sh
- 忘记 shell 内建命令不受 nice 影响：比如
nice -n 15 for i in {1..100}; do echo $i; done 中的 echo 仍是默认优先级，因为 for 是 bash 内建，echo 由当前 shell 派生，未被 nice 包裹
- 在 systemd 服务里硬写
ExecStart=nice -n 12 /usr/bin/myapp：可行，但更推荐用 IOSchedulingPriority= 或 Nice= 单独配置项，避免解析歧义
renice 修改运行中进程，哪些 PID 能动、哪些不能？
nice 15 myscript.sh：这会让 shell 自身以 nice=15 运行，而子进程继承的是 shell 的 nice（通常是 0），正确写法是 nice -n 15 ./myscript.sh
nice -n 15 for i in {1..100}; do echo $i; done 中的 echo 仍是默认优先级，因为 for 是 bash 内建，echo 由当前 shell 派生，未被 nice 包裹ExecStart=nice -n 12 /usr/bin/myapp：可行，但更推荐用 IOSchedulingPriority= 或 Nice= 单独配置项，避免解析歧义renice 只能调整用户自己启动的进程（且目标 UID == 当前 UID），root 可调任意进程。但即使你是 root，也不能把系统关键进程（如 kthreadd、rcu_gp）的 nice 设得太低——它们本就运行在最高静态优先级（static_prio = 2），再设 renice -20 也无效，内核会 clamp 到合法范围。
- 查看当前 nice：
ps -o pid,ni,comm -p $(pgrep myproc) - 批量调高 5 级（更谦让）：
renice +5 $(pgrep -f "python data_loader.py") - 给整个进程组（含子进程）设 nice：
renice -n -10 -g $(pgrep -f "ffmpeg -i input.mp4")，注意-g后跟的是进程组 ID（PGID），不是 PID - 如果
renice报错Permission denied，不是权限不够，而是目标进程已进入不可中断状态（D状态），此时修改会被忽略，需等其恢复运行态
和 ionice、cpulimit 混用时谁起主导作用？
nice 只管 CPU 时间片分配权重，不控制 IO 或 CPU 使用率上限。三者关系如下：
-
ionice控制块设备 IO 调度队列优先级（best-effort类下也有 classdata 类似 nice），与nice正交，可同时生效 -
cpulimit是用户态轮询杀时间片的粗粒度限制，会干扰 CFS 调度逻辑；若已用nice让出 CPU，再加cpulimit可能导致频繁休眠唤醒，反而增加上下文切换开销 - 真正想压低资源占用，优先顺序应是：先用
nice调度权重 → 再用cgroups v2（如cpu.weight）做硬性配额 → 最后才考虑cpulimit这种补丁方案
nice 和 renice 看似简单，但它的效果高度依赖负载类型和内核版本——CFS 在 4.16+ 引入 util_est 后，短时突发进程可能被临时提权，导致你设的 nice 值在几秒内“失效”。别只盯着数值，用 pidstat -r -u 1 实时观察 %CPU 和 majflt/minflt 才算真的看清了。
