调整linux内核调度延迟的核心是优化cfs的sched_latency_ns参数，它定义调度周期长度，默认24ms，需按业务类型设为10–15ms（web）、保持24ms（数据库）或1–5ms（实时），但不低于6ms；须通过/etc/sysctl.d/99-sched-tuning.conf配置并用sysctl --system加载，且需结合绑核、numa亲和性及业务特征调优。
调整 Linux 系统内核进程调度延迟，核心是优化 CFS（完全公平调度器）的 sched_latency_ns 参数——它定义了调度周期长度，直接影响任务响应速度和上下文切换频率。调得过小会抬高开销，过大则增加延迟，必须结合负载特征和硬件配置谨慎设置。
确认当前调度器和参数值
先验证你用的是默认 CFS 调度器：
- 运行
cat /sys/kernel/debug/sched_features | grep -o "CFS"，有输出说明启用 CFS；没输出可能被chrt强制覆盖或启用了实时调度类 - 查当前值：
sysctl kernel.sched_latency_ns或cat /proc/sys/kernel/sched_latency_ns（默认通常是 24000000 ns，即 24ms）
合理设置 sched_latency_ns 的范围
该参数不是越小越好，需按业务类型匹配：
- 高并发 Web/API 服务（如 Node.js、Go 后端）：推荐 10000000–15000000（10–15ms），平衡响应与切换开销
- 数据库类 IO 密集型（如 PostgreSQL、MySQL）：建议保持默认 24000000，或微调至 20000000；大幅降低易引发缓存失效和抖动
-
实时音视频/工业控制：可下探至 1000000–5000000（1–5ms），但必须同步调大
sched_wakeup_granularity_ns防止任务饥饿 -
绝对底线：不建议低于 6000000（6ms），否则小核 CPU 容易过载，
r值（运行队列长度）可能飙升
安全修改并持久生效
不能直接 echo 写 /proc，也不能只改 /etc/sysctl.conf —— 新系统（Ubuntu 22.04+、RHEL 8+、Rocky 9）会优先加载 /etc/sysctl.d/ 下的文件，旧配置易被静默覆盖：
- 新建配置文件：
sudo tee /etc/sysctl.d/99-sched-tuning.conf kernel.sched_latency_ns = 10000000<br>kernel.sched_min_granularity_ns = 1000000<br>kernel.sched_migration_cost_ns = 200000<br>EOF
- 加载全部配置：
sudo sysctl --system（注意：不是sysctl -p） - 验证是否生效：
sysctl kernel.sched_latency_ns并比对/proc/sys/kernel/sched_latency_ns值是否一致
调完没变化？检查这几点
参数生效 ≠ 性能立竿见影，常见无效原因：
- 业务本身是单线程阻塞型（如 Python 同步 HTTP 服务），再细的调度粒度也无意义
- CPU 已被
%us占满，降低 latency 只会让争抢更激烈，反而加剧抖动 - 没配合绑核（
taskset）或 NUMA 亲和性设置，跨核迁移抵消了调度优化 - 透明大页（THP）未关闭，后台合并操作引入不可控延迟
不复杂但容易忽略
