Linux核心调度器参数配置指南

谈到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 flush次数大幅增加。迁移频繁时，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观察实际任务分布，避免盲目照搬文档中的数值。