ulimit -e 仅限制实时调度优先级（0–99），与 nice 值（-20 至 19）完全无关；它不影响 cfs 下普通进程的调度，也不能保护关键任务；真正控制 nice 需依赖 cap_sys_nice 权限、/etc/security/limits.conf 中 priority 设置或 cgroups 等机制。
ulimit -e 并不能调整进程的 nice 权重限制，也不能用于“保护关键任务”。这是一个常见误解。
-e 选项在 ulimit 中代表的是“最大调度优先级（scheduling priority）”，但它只对实时进程（real-time scheduling policies，如 SCHED_FIFO 或 SCHED_RR）生效，与 nice 值完全无关。
✅ 正确理解 ulimit -e
-
ulimit -e N设置的是用户可设置的 最大实时优先级（rtprio），范围通常是0–99（0 表示无实时权限，99 是最高实时优先级）。 - 它影响的是
chrt -f 50 cmd这类实时调度命令，不影响nice、renice或 CFS（完全公平调度器）下的普通进程。 - 普通进程的调度优先级由
nice值（-20 到 19）决定，而ulimit -e对其 没有任何约束或保护作用。
❗ 所以：
ulimit -e无法限制或提升nice行为，也不能“防止别人用 high nice 值抢占关键任务”——它管不到nice。
? 真正能限制普通用户修改 nice 值的方式
Linux 通过内核权限机制控制 nice 调整：
- 普通用户默认只能 提高 nice 值（即降低优先级），比如
nice -n 10 cmd或renice 15 -p PID。 - 普通用户 无法设置负 nice 值（如
-5），执行会报Permission denied。 - root 或拥有
CAP_SYS_NICE能力的进程才能 降低 nice 值（提升优先级）。
系统层面的控制点包括：
-
/proc/sys/kernel/nice_min和/proc/sys/kernel/nice_max（只读，通常固定为 -20 和 19） -
/etc/security/limits.conf中可配置：username soft priority 10 username hard priority 10
这表示该用户启动的进程 默认最大允许 nice 值为 10（即最不谦让是
nice=10），但注意：- 这限制的是
nice值上限（即“最多能多谦让”），不是下限； - 它 不能阻止 root 提权运行高优先级任务；
- 修改后需重新登录才生效，且不推荐在生产环境随意放宽。
- 这限制的是
? 如何真正“保护关键任务”？
若目标是确保关键服务不被低优先级任务拖慢，应组合使用以下机制：
-
用
nice启动关键服务时设较低值（需 root）sudo nice -n -10 /usr/local/bin/critical-monitor
-
用
renice动态提权已有进程（需 root）sudo renice -15 -p $(pgrep critical-monitor)
-
配合
ionice控制 I/O 争抢（尤其对磁盘敏感服务）sudo ionice -c 1 -n 0 nice -n -10 ./db-backup
-
用 cgroups（v2 推荐）做硬性 CPU 配额隔离
例如限制某组进程最多用 20% CPU，比 nice 更可靠：# 创建 slice 并限频 sudo systemd-run --scope -p CPUQuota=20% -- bash -c 'sleep 300'
避免依赖 nice 做“保护”——它只是调度建议，非强制保障
在高负载下，nice= -20的普通进程仍会被SCHED_FIFO实时进程、内核线程、中断处理等抢占。
⚠️ 小结：ulimit -e 不适用于 nice 场景
-
ulimit -e→ 管实时调度策略（chrt），和nice无交集； - 想控
nice行为 → 依赖权限模型（root/CAP_SYS_NICE）+ limits.conf（软限制）； - 想保关键任务稳定 → 组合
nice/renice+ionice+cgroups+ 资源预留（如 CPU affinitytaskset）。
不复杂但容易忽略。
