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 能动、哪些不能？

renice 只能调整用户自己启动的进程（且目标 UID == 当前 UID），root 可调任意进程。但即使你是 root，也不能把系统关键进程（如 kthreadd、rcu_gp）的 nice 设得太低——它们本就运行在最高静态优先级（static_prio = 2），再设 renice -20 也无效，内核会 clamp 到合法范围。

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

• 查看当前 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 才算真的看清了。