谈及Linux调度器性能调优，许多运维人员首先想到的是nice和renice命令——它们确实能调整普通进程的优先级权重，但实际上这只是冰山一角。真正决定CFS调度器行为、负载均衡策略以及唤醒延迟等底层机制的核心，是/sys/kernel/debug/sched/和/proc/sys/kernel/目录下的内核运行时参数。若修改位置错误或操作顺序不当，轻则参数无法生效，重则引发调度抖动甚至软锁死。那么，到底应该调整哪些参数？如何正确操作？下面逐步解析。
CFS调度器依靠vruntime（虚拟运行时间）实现公平调度，关键参数如sched_min_granularity_ns、sched_latency_ns和sched_migration_cost_ns必须通过sysctl工具安全调整，禁止直接写入/proc路径。默认值应根据实际负载进行实测调优，错误配置可能导致调度抖动甚至系统软锁死。
如何安全修改sched_*参数（如sched_min_granularity_ns）
这些参数位于/proc/sys/kernel/目录下，最稳妥的方法是使用sysctl命令，切勿直接通过echo写入/proc。为什么？因为有些参数在写入前需要校验范围，直接写入可能被静默忽略或返回Invalid argument错误，调试起来非常麻烦。
- 第一步，查看当前参数值：
sysctl kernel.sched_min_granularity_ns - 临时调整（重启后失效）：
sysctl -w kernel.sched_min_granularity_ns=1000000 - 永久生效方法：将配置写入
/etc/sysctl.conf或/etc/sysctl.d/99-scheduler.conf，然后执行sysctl -p - 禁止直接执行
echo 1000000 > /proc/sys/kernel/sched_min_granularity_ns
典型参考值：默认值为2250000ns（2.25ms）。如果你的服务属于I/O密集型，可以尝试降低到1000000ns。但需要注意，若低于500000ns则必须进行实际测试——任务切换过于频繁反而会增加调度开销，得不偿失。
sched_migration_cost_ns调低后CPU使用率反而飙升？
这个参数定义了“进程迁移成本阈值”，调度器据此判断是否将任务从一个CPU迁移到另一个。数值设得越小，迁移行为越激进——但代价是跨CPU缓存失效和TLB刷新次数大幅增加。一旦迁移过于频繁，你会看到vmstat输出中的cs（上下文切换次数）急剧上升，mpstat -P ALL显示各CPU利用率严重不均衡。此时不妨适当调高该参数：
- 默认值为500000ns（0.5ms），适用于通用负载
- 若观察到迁移过于频繁，可调整至1000000或2000000，能有效抑制不必要的迁移，尤其在NUMA架构下效果显著
- 特别注意：此参数与
sched_feat中的ASSISTED_MIGRATION开关联动——如果后者被关闭，调整该参数将毫无效果
为什么/sys/kernel/debug/sched_features里的开关不能随便关
这个目录下存放的是CFS调度器的编译时特性开关，例如WAKEUP_PREEMPT、NO_NEW_FAIR_SLEEPERS等，每个开关都对应一段关键的调度逻辑。启用或禁用它们会直接改变调度器的行为：
- 例如关闭
WAKEUP_PREEMPT后，高优先级任务唤醒后无法立即抢占当前运行任务，延迟会显著增加 - 关闭
GROUP_SCHED会禁用cgroup的CPU带宽限制，导致容器隔离直接失效 - 修改方式仅能通过
echo "NO_WAKEUP_PREEMPT" > /sys/kernel/debug/sched_features（添加NO_前缀表示关闭），但前提是内核编译时启用了CONFIG_SCHED_DEBUG - 多数场景下保持默认配置是最安全的选择；仅在perf trace明确显示某个特性导致调度路径过长时，才值得针对性关闭
最后再提醒一点：所有上述参数的效果都高度依赖实际负载特征。例如，sched_latency_ns在4核机器上默认值为6000000ns，但如果你的机器运行的是单线程计算任务，增大该值毫无意义——因为CFS根本不会触发多任务分时逻辑。在调整参数之前，建议先使用pidstat -t -r 1命令观察实际的任务分布情况，切勿盲目照搬文档中的数值。
