linux cpu调度调优需结合应用类型、负载特征和硬件拓扑：cfs默认适用交互任务，数据库宜保持默认sched_latency_ns（24ms），高并发web可设为10ms，实时音视频应使用chrt -f配合绑核；须通过sysctl配置参数并压测验证。
直接调 CPU 调度器参数不是“改个数字就变快”，而是要结合应用类型、负载特征和硬件拓扑做针对性调整。重点不在“调什么”，而在“为什么这么调”——比如数据库、实时音视频、高并发 Web 服务，各自需要的调度行为完全不同。
CPU 进程优先级与调度策略
Linux 默认用 CFS（完全公平调度器），对普通交互任务友好，但对吞吐敏感型任务可能不够激进。关键操作有三类：
-
nice/renice 控制相对权重：nice 值越小（最低 -20），进程获得 CPU 时间越多。例如让核心计算进程抢占更多资源：
renice -n -15 -p 12345 -
chrt 设置实时策略：对延迟敏感或必须独占 CPU 的任务（如媒体编码、工业控制），可用 FIFO 或 RR 策略：
chrt -f 98 ./encoder（98 是实时优先级，0–99，越高越优先） - 避免误用实时策略：SCHED_FIFO 进程若不主动让出 CPU，会饿死其他进程；务必确保代码有 yield 或 sleep，否则系统可能无响应
CPU 亲和性与中断绑定
多核环境下，频繁在核心间迁移线程会导致缓存失效、增加延迟。把关键进程“钉”在固定核心上，能显著提升局部性与吞吐：
-
taskset 绑定进程：启动时绑定到 CPU 1 和 3：
taskset -c 1,3 ./worker；运行中查看绑定：taskset -cp 12345 -
网络中断绑定：网卡中断默认分散在所有核，易造成某核过载。用
mpstat -P ALL 1查看各核软中断分布，再将对应 IRQ 绑定到专用核：echo 2 > /proc/irq/42/smp_affinity_list（表示绑定到 CPU 2） - 配合 cgroup v2 隔离：对关键服务，建议用 CPU controller 限制其可用核心与配额，比 taskset 更稳定可控
CFS 内部参数微调（慎用）
多数场景无需动底层参数，但若遇到大量短任务导致调度开销上升，可小幅优化：
-
缩短最小调度粒度：降低
/proc/sys/kernel/sched_min_granularity_ns（默认 1ms），让小任务更快轮转，适合高并发短请求场景 -
关闭非必要调度特性：如确认无交互需求，可临时关闭自动组调度：
echo 0 > /sys/kernel/debug/sched_autogroup_enabled -
监控上下文切换：用
vmstat 1看cs列，持续 >8 万/秒需警惕；再用perf top -e sched:sched_switch定位高频切换进程
配套监控与验证
调参前必须采集基线，调完必须压测验证。不能只看 CPU 使用率，要看实际吞吐、P99 延迟、上下文切换数：
-
快速诊断命令：
top -H（看线程级 CPU）、pidstat -t 1（线程调度统计）、sar -u 1 10（CPU 各态占比） -
识别瓶颈信号：若
sy（系统态）占比高，说明内核开销大（如锁竞争、频繁 syscalls）；若wa高，说明 CPU 在等 I/O，调度调优无效 - 避免“调参幻觉”：单次调优后性能没提升，大概率是瓶颈不在 CPU 调度层——先确认是不是内存带宽、磁盘 IOPS 或网络丢包限制了上限
