Linux内核调度延迟敏感参数主要影响CFS对任务响应速度的控制，需先确认使用CFS调度器并核查当前参数值，再按高并发Web、实时任务或IO密集型等场景设置合理范围，通过/etc/sysctl.d/99-sched-tuning.conf持久化配置并执行sysctl --system加载，同时结合CPU绑核与NUMA亲和性优化方能生效。
Linux 内核调度延迟敏感参数主要影响 CFS（完全公平调度器）对任务响应速度的控制能力，核心是让关键进程更快获得 CPU 时间，减少不可预测的停顿。调整不是简单改几个数字，而是要匹配负载特征、硬件架构和业务类型。
确认当前调度器和参数状态
先看系统是否在用 CFS：
cat /sys/kernel/debug/sched_features | grep -o "CFS"
没输出说明可能被 chrt 强制设为实时策略，或内核未启用 CFS。
再查关键参数当前值：
sysctl kernel.sched_latency_ns kernel.sched_min_granularity_ns kernel.sched_wakeup_granularity_ns
默认值通常是：
-
sched_latency_ns = 24000000（24ms） -
sched_min_granularity_ns = 2250000（2.25ms） -
sched_wakeup_granularity_ns = 1000000（1ms）
按场景设置合理参数范围
高并发 Web/API 服务（如 Nginx、Node.js）
-
sched_latency_ns = 10000000（10ms） -
sched_min_granularity_ns = 1000000（1ms） -
sched_wakeup_granularity_ns = 1（最小值，加速唤醒抢占）
适合活跃进程数 30–80 的中高负载，能降低 P99 延迟，避免小任务被“挤扁”。
低延迟实时任务（音视频编码、工业控制）
-
sched_latency_ns = 4000000（4ms）或5000000（5ms） -
sched_min_granularity_ns = 500000（0.5ms） -
sched_migration_cost_ns = 200000（抑制跨核迁移）
注意：必须配合 CPU 绑核（taskset或 cgroup），否则频繁迁移反而抬高延迟。
数据库类 IO 密集型（MySQL、PostgreSQL）
- 保持
sched_latency_ns默认值（24ms）或略调高至30000000 -
sched_min_granularity_ns = 1000000（1ms） - 关闭
numa_balancing（echo 0 > /proc/sys/kernel/numa_balancing）
理由：IO 等待时间长，不需要高频调度；大时间片更利于批量处理，减少切换开销。
安全持久化配置方法
不能直接写 /proc/sys/kernel/...，也不能只改 /etc/sysctl.conf——新系统（Ubuntu 22.04+、RHEL 8+、Rocky 9）会优先加载 /etc/sysctl.d/*.conf，覆盖 /etc/sysctl.conf。
正确做法：
- 创建文件
/etc/sysctl.d/99-sched-tuning.conf - 写入内容（示例）：
kernel.sched_latency_ns = 10000000 kernel.sched_min_granularity_ns = 1000000 kernel.sched_wakeup_granularity_ns = 1 kernel.numa_balancing = 0
- 执行：
sudo sysctl --system
这条命令才会完整扫描并加载所有
.d/下的配置。
验证是否生效：
sysctl kernel.sched_latency_ns cat /proc/sys/kernel/sched_latency_ns
两个输出值必须一致。
调完仍没变化？检查这几个点
- 业务本身是单线程阻塞型（比如 Python 同步服务），再细的调度粒度也无意义
- CPU 使用率已长期 >90%，参数再优也无法缓解资源争抢
- 没做 CPU 绑核或 NUMA 亲和性设置，任务在多核间跳来跳去，缓存失效严重
-
perf sched latency显示平均延迟高，但r值（运行队列长度）持续 > CPU 核心数 × 2，说明根本是过载，不是调度问题
不复杂但容易忽略
