Linux CFS 的 sleep_avg：睡眠任务的平均等待时间

一、前言为什么关注睡眠任务的统计在Linux内核的进程调度子系统中CFSCompletely Fair Scheduler自2.6.23版本引入以来一直是桌面和服务器系统的核心调度器。与早期的O(1)调度器依赖复杂的启发式算法如sleep_avg、interactive_credit等字段来判断任务类型不同CFS采用了更加数学化的公平调度模型。然而睡眠任务的平均等待时间这一概念在CFS中并未消失而是以更精细的方式存在于sched_statistics结构中。理解这些统计字段对于以下场景至关重要性能调优通过分析任务的睡眠模式识别I/O密集型与CPU密集型负载调度延迟分析诊断交互式应用的响应延迟问题系统监控构建自定义的调度行为监控工具内核开发调试调度器相关的问题或开发新的调度策略本文将从源码层面深入解析CFS中睡眠任务的统计机制并通过实际案例展示如何利用这些统计信息进行系统分析和优化。二、核心概念CFS中的调度统计框架2.1 调度实体与统计结构CFS为每个任务维护一个sched_entity结构其中包含了调度所需的核心信息。在启用了CONFIG_SCHEDSTATS配置时该结构内嵌了sched_statistics字段用于收集详细的调度统计信息// include/linux/sched.h struct sched_entity { struct load_weight load; // 任务权重由nice值决定 struct rb_node run_node; // 红黑树节点 unsigned int on_rq; // 是否在运行队列上 u64 exec_start; // 本次执行开始时间 u64 sum_exec_runtime; // 总执行时间 u64 vruntime; // 虚拟运行时间 #ifdef CONFIG_SCHEDSTATS struct sched_statistics statistics; // 调度统计信息 #endif // ... 其他字段 };sched_statistics结构定义了多个与睡眠和等待相关的统计字段// include/linux/sched.h struct sched_statistics { u64 wait_start; // 开始等待CPU的时间戳 u64 wait_max; // 单次最大等待时间 u64 wait_count; // 等待次数统计 u64 wait_sum; // 总等待时间 u64 sleep_start; // 开始睡眠可中断的时间戳 u64 sleep_max; // 单次最大睡眠时间 s64 sum_sleep_runtime; // 总睡眠时间可中断 u64 block_start; // 开始阻塞不可中断的时间戳 u64 block_max; // 单次最大阻塞时间 s64 sum_block_runtime; // 总阻塞时间 u64 iowait_count; // I/O等待次数 u64 iowait_sum; // I/O等待总时间 // 唤醒相关统计 u64 nr_wakeups; // 总唤醒次数 u64 nr_wakeups_sync; // 同步唤醒次数 u64 nr_wakeups_migrate; // 跨CPU迁移唤醒次数 // ... 更多字段 };2.2 睡眠时间的分类在Linux内核中睡眠并非单一概念CFS区分了三种不同的等待状态可中断睡眠TASK_INTERRUPTIBLE任务等待某事件可被信号唤醒不可中断睡眠TASK_UNINTERRUPTIBLE任务等待I/O完成不可被信号中断运行队列等待任务处于就绪状态等待CPU调度这三种状态分别对应sleep_start、block_start和wait_start三个时间戳字段。三、环境准备3.1 硬件与软件环境进行本文的实践需要以下环境组件最低要求推荐配置CPUx86_64架构支持2核以上4核以上支持性能监控单元(PMU)内存4GB8GB以上操作系统Linux 4.15Linux 5.10 或 6.x内核源码对应版本建议下载完整源码树3.2 启用调度统计默认情况下CONFIG_SCHEDSTATS可能未启用。需要检查并启用该选项# 检查当前内核是否启用了调度统计 grep CONFIG_SCHEDSTATS /boot/config-$(uname -r) # 如果输出为 # CONFIG_SCHEDSTATS is not set则需要重新编译内核 # 在源码目录中 cd /usr/src/linux-$(uname -r) make menuconfig # 导航至: Kernel hacking - Scheduler Debugging - Collect scheduler statistics # 启用 CONFIG_SCHEDSTATS 和 CONFIG_SCHED_DEBUG make -j$(nproc) make modules_install make install3.3 安装调试工具# Ubuntu/Debian sudo apt-get install linux-tools-common linux-tools-generic \ trace-cmd kernelshark bpfcc-tools # RHEL/CentOS/Fedora sudo yum install perf trace-cmd kernel-tools # 验证perf安装 perf stat -e sched:sched_switch sleep 1四、应用场景为什么需要分析睡眠统计在实际生产环境中分析任务的睡眠模式具有重要价值。以下是一个典型的数据库服务器场景某在线交易系统出现间歇性延迟 spikes业务团队怀疑是CPU调度问题。通过分析关键数据库进程的调度统计我们发现前台查询线程sum_sleep_runtime高但wait_sum低说明线程大部分时间等待I/O网络/磁盘属于典型的I/O密集型交互式任务后台批量导入线程sum_sleep_runtime低但sum_exec_runtime高说明持续占用CPU属于CPU密集型批处理任务异常发现某监控代理进程的wait_max达到100ms说明它经常与其他高优先级任务竞争CPU基于这些数据我们采取了以下优化措施将批量导入任务设置为SCHED_BATCH策略调整监控代理的nice值降低其优先级启用CPU亲和性将前台线程绑定到特定核心优化后P99延迟从45ms降至12ms。五、实战案例深入分析睡眠统计5.1 查看进程的调度统计每个进程在/proc/PID/sched文件中暴露了其调度统计信息# 查看sshd进程的调度统计 cat /proc/$(pidof sshd)/sched # 典型输出示例 sshd (1234, #threads: 1) ------------------------------------------------------------------- se.exec_start : 1234567890.123456 se.vruntime : 12345.678901 se.sum_exec_runtime : 1234.567890 se.statistics.wait_start : 0.000000 se.statistics.sleep_start : 1234567890.123456 se.statistics.block_start : 0.000000 se.statistics.sleep_max : 5000.123456 se.statistics.block_max : 0.000000 se.statistics.exec_max : 0.002345 se.statistics.slice_max : 0.001234 se.statistics.wait_max : 0.000123 se.statistics.wait_sum : 0.456789 se.statistics.wait_count : 12345 se.statistics.iowait_sum : 8000.000000 se.statistics.iowait_count : 2345 se.statistics.sum_sleep_runtime : 50000.000000 se.statistics.sum_block_runtime : 0.000000 se.statistics.nr_wakeups : 10000 se.statistics.nr_wakeups_sync : 8000 se.statistics.nr_wakeups_migrate : 50 avg_atom : 0.000100 avg_per_cpu : 0.010000 nr_switches : 50000 nr_voluntary_switches : 45000 nr_involuntary_switches : 5000 se.load.weight : 1048576 policy : 0 prio : 1205.2 编写分析脚本以下Bash脚本用于收集和分析指定进程的睡眠统计#!/bin/bash # analyze_sleep_stats.sh - 分析进程睡眠统计信息 # 用法: ./analyze_sleep_stats.sh PID [采样间隔(秒)] [采样次数] PID$1 INTERVAL${2:-5} COUNT${3:-12} if [ -z $PID ] || ! [ -d /proc/$PID ]; then echo 错误: 请提供有效的PID exit 1 fi echo 进程 $PID 调度统计分析 echo 开始时间: $(date) echo 采样间隔: ${INTERVAL}秒, 采样次数: $COUNT echo # 获取进程名 COMM$(cat /proc/$PID/comm 2/dev/null || echo unknown) # 初始化数组 declare -A prev_stats declare -A curr_stats declare -A delta_stats # 读取统计数据的函数 read_sched_stats() { local pid$1 local file/proc/$pid/sched if [ ! -r $file ]; then echo 无法读取 $file可能需要root权限 return 1 fi # 提取关键字段 grep -E (sum_sleep_runtime|sum_block_runtime|wait_sum|iowait_sum|nr_wakeups|sum_exec_runtime) $file | \ while read line; do key$(echo $line | awk -F: {print $1} | tr -d ) val$(echo $line | awk -F: {print $2} | tr -d ) echo $key$val done } # 首次采样 echo 进程名: $COMM echo 首次采样中... while IFS read -r key val; do prev_stats[$key]$val done (read_sched_stats $PID) echo 字段: ${!prev_stats[]} echo # 循环采样 for i in $(seq 1 $COUNT); do sleep $INTERVAL # 读取当前统计 while IFS read -r key val; do curr_stats[$key]$val done (read_sched_stats $PID) echo --- 采样 $i (经过 ${INTERVAL}秒) --- # 计算差值并输出 for key in ${!curr_stats[]}; do prev${prev_stats[$key]:-0} curr${curr_stats[$key]} # 处理浮点数运算 delta$(echo $curr - $prev | bc 2/dev/null || echo 0) # 计算速率每秒 rate$(echo scale6; $delta / $INTERVAL | bc 2/dev/null || echo 0) printf %-25s: 当前%12s, 增量%10s, 速率%10s/秒\n \ $key $curr $delta $rate # 更新前值 prev_stats[$key]$curr done # 计算睡眠比例 sleep_time${curr_stats[se.statistics.sum_sleep_runtime]:-0} exec_time${curr_stats[se.sum_exec_runtime]:-0} if (( $(echo $exec_time 0 | bc -l) )); then sleep_ratio$(echo scale4; $sleep_time / ($sleep_time $exec_time) * 100 | bc) echo echo 睡眠占比: ${sleep_ratio}% (越高说明I/O等待越多) fi echo done echo 分析完成: $(date)5.3 使用perf进行深度分析perf工具可以捕获调度事件并分析任务的睡眠模式# 1. 记录调度事件包括睡眠和唤醒 sudo perf record -e sched:sched_switch,sched:sched_wakeup \ -a -g -- sleep 30 # 2. 生成报告 sudo perf report --sortcomm,dso --show-total-period # 3. 分析特定进程的调度延迟 sudo perf sched record -- sleep 10 sudo perf sched latency --sort max # 4. 查看唤醒关系 sudo perf sched map5.4 使用trace-cmd进行实时跟踪# 安装trace-cmd sudo apt-get install trace-cmd # 跟踪特定进程的睡眠和唤醒事件 sudo trace-cmd record -e sched_switch -e sched_wakeup \ -P $(pidof your_application) # 分析跟踪结果 trace-cmd report | head -100 # 可视化调度时间线 kernelshark trace.dat六、CFS睡眠统计的源码解析6.1 睡眠开始时的记录当任务进入睡眠状态时CFS在dequeue_entity函数中记录睡眠开始时间// kernel/sched/fair.c static void dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags) { update_curr(cfs_rq); if (flags DEQUEUE_SLEEP) { #ifdef CONFIG_SCHEDSTATS if (entity_is_task(se)) { struct task_struct *tsk task_of(se); // 记录可中断睡眠开始时间 if (tsk-state TASK_INTERRUPTIBLE) se-statistics.sleep_start rq_clock(rq_of(cfs_rq)); // 记录不可中断睡眠阻塞开始时间 if (tsk-state TASK_UNINTERRUPTIBLE) se-statistics.block_start rq_clock(rq_of(cfs_rq)); } #endif } // ... 其他处理 }6.2 睡眠结束时的统计更新当任务被唤醒并入队时__update_stats_enqueue_sleeper函数计算并更新睡眠统计// kernel/sched/stats.c void __update_stats_enqueue_sleeper(struct rq *rq, struct task_struct *p, struct sched_statistics *stats) { u64 sleep_start, block_start; sleep_start schedstat_val(stats-sleep_start); block_start schedstat_val(stats-block_start); // 处理可中断睡眠 if (sleep_start) { u64 delta rq_clock(rq) - sleep_start; if ((s64)delta 0) delta 0; // 更新最大睡眠时间 if (unlikely(delta schedstat_val(stats-sleep_max))) __schedstat_set(stats-sleep_max, delta); // 清零开始时间戳 __schedstat_set(stats-sleep_start, 0); // 累加总睡眠时间 __schedstat_add(stats-sum_sleep_runtime, delta); // 如果任务处于I/O等待状态更新I/O统计 if (p) { if (p-in_iowait) { __schedstat_add(stats-iowait_sum, delta); __schedstat_inc(stats-iowait_count); } } } // 类似处理不可中断睡眠... if (block_start) { u64 delta rq_clock(rq) - block_start; // ... 更新block_max和sum_block_runtime } }6.3 Sleeper Fairness机制CFS通过place_entity函数实现Sleeper Fairness睡眠者公平性这是CFS识别交互式任务的核心机制// kernel/sched/fair.c static void place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial) { u64 vruntime cfs_rq-min_vruntime; // 新创建任务的初始惩罚 if (initial sched_feat(START_DEBIT)) vruntime sched_vslice(cfs_rq, se); // 对于唤醒的任务非初始入队给予vruntime补偿 if (!initial) { unsigned long thresh sysctl_sched_latency; // GENTLE_FAIR_SLEEPERS特性减半睡眠补偿的影响 if (sched_feat(GENTLE_FAIR_SLEEPERS)) thresh 1; // 除以2 // 减去补偿值使睡眠任务获得vruntime优势 vruntime - thresh; } // 确保vruntime不会倒退不会获得超过实际睡眠时间的补偿 se-vruntime max_vruntime(se-vruntime, vruntime); }关键逻辑解析补偿上限无论任务睡眠多久其vruntime补偿上限为sched_latency_ns默认6ms的一半如果启用了GENTLE_FAIR_SLEEPERS防止滥用通过max_vruntime确保vruntime不会倒退防止任务通过频繁睡眠获取不公平的CPU份额交互式识别经常睡眠的任务如I/O密集型会保持较低的vruntime从而获得更频繁的调度机会七、常见问题与解答Q1: 为什么我的进程sum_sleep_runtime很高但响应仍然慢A:sum_sleep_runtime只统计可中断睡眠时间。如果进程大部分时间处于TASK_UNINTERRUPTIBLE状态如等待磁盘I/O应该查看sum_block_runtime字段。使用以下命令确认# 查看进程状态分布 cat /proc/$(pidof your_app)/stat | awk {print $3} # 第3字段是状态 # R运行, S可中断睡眠, D不可中断睡眠, Z僵尸, T停止 # 实时监控状态变化 watch -n 1 cat /proc/$(pidof your_app)/stat | awk {print \$3}Q2: 如何区分I/O等待和主动睡眠A: 通过iowait_sum和iowait_count字段可以识别I/O等待。计算I/O等待比例#!/bin/bash PID$1 SCHED_FILE/proc/$PID/sched if [ -f $SCHED_FILE ]; then SLEEP_SUM$(grep sum_sleep_runtime $SCHED_FILE | awk {print $2}) IOWAIT_SUM$(grep iowait_sum $SCHED_FILE | awk {print $2}) if (( $(echo $SLEEP_SUM 0 | bc -l) )); then RATIO$(echo scale2; $IOWAIT_SUM / $SLEEP_SUM * 100 | bc) echo I/O等待占睡眠时间的比例: ${RATIO}% if (( $(echo $RATIO 80 | bc -l) )); then echo 结论: 主要是I/O密集型任务 elif (( $(echo $RATIO 20 | bc -l) )); then echo 结论: 主要是主动睡眠如timer_sleep else echo 结论: I/O和主动睡眠混合 fi fi fiQ3: CFS如何判断一个任务是交互式的A: CFS不像O(1)调度器那样显式计算交互性分数而是通过以下隐式机制vruntime增长率I/O密集型任务经常睡眠vruntime增长慢唤醒补偿睡眠后vruntime被设置为min_vruntime - thresh使其更容易被选中抢占粒度sched_wakeup_granularity_ns控制唤醒任务抢占当前任务的阈值Q4: 如何调试调度延迟问题A: 使用以下综合调试流程# 1. 检查调度策略和优先级 chrt -p $(pidof your_app) # 2. 查看调度统计 cat /proc/$(pidof your_app)/sched | grep -E (wait_max|sleep_max|nr_involuntary_switches) # 3. 使用perf分析调度延迟 sudo perf sched record -- sleep 10 sudo perf sched latency --sort max | head -20 # 4. 检查是否被实时任务抢占 ps -eo pid,comm,rtprio,class | grep -E (FF|RR) | head -10 # 5. 分析CPU负载均衡 cat /proc/schedstat | head -20八、实践建议与最佳实践8.1 性能调优建议识别任务类型交互式任务高sleep_sum/exec_ratio保持默认SCHED_NORMAL考虑降低nice值批处理任务低sleep_sum/exec_ratio使用SCHED_BATCH策略后台任务考虑SCHED_IDLE或nice 19避免调度抖动# 对于已知的工作负载调整调度粒度 # 服务器工作负载增加粒度减少上下文切换 echo 4000000 /proc/sys/kernel/sched_min_granularity_ns # 4ms echo 20000000 /proc/sys/kernel/sched_latency_ns # 20msCPU亲和性设置// 将交互式任务绑定到特定核心减少缓存失效 #define _GNU_SOURCE #include sched.h void bind_to_cpu(int cpu) { cpu_set_t cpuset; CPU_ZERO(cpuset); CPU_SET(cpu, cpuset); sched_setaffinity(0, sizeof(cpuset), cpuset); }8.2 监控脚本示例以下脚本可用于生产环境监控关键进程的调度健康度#!/bin/bash # sched_health_check.sh - 调度健康度检查 THRESHOLD_WAIT_MAX10000000 # 10ms单位纳秒 THRESHOLD_INVOL_RATIO10 # 非自愿切换占比阈值(%) check_process() { local pid$1 local name$2 if [ ! -d /proc/$pid ]; then return fi local sched_file/proc/$pid/sched local wait_max$(grep wait_max $sched_file | awk {print $2} | cut -d. -f1) local nr_invol$(grep nr_involuntary_switches $sched_file | awk {print $2}) local nr_vol$(grep nr_voluntary_switches $sched_file | awk {print $2}) local total_switches$((nr_invol nr_vol)) if [ $total_switches -gt 0 ]; then local invol_ratio$((nr_invol * 100 / total_switches)) echo 进程: $name (PID: $pid) echo 最大等待时间: ${wait_max}ns echo 非自愿切换占比: ${invol_ratio}% if [ $wait_max -gt $THRESHOLD_WAIT_MAX ]; then echo [警告] 调度延迟过高可能存在CPU竞争 fi if [ $invol_ratio -gt $THRESHOLD_INVOL_RATIO ]; then echo [警告] 频繁被抢占考虑提升优先级或使用SCHED_FIFO fi echo fi } # 检查关键进程 echo 调度健康度检查 $(date) check_process $(pidof mysqld 2/dev/null) MySQL check_process $(pidof nginx 2/dev/null) Nginx check_process $(pidof redis-server 2/dev/null) Redis # 系统级检查 echo 系统级调度统计 cat /proc/schedstat | head -5九、总结CFS调度器通过sched_statistics结构提供了丰富的睡眠和等待统计信息包括sleep_start、sleep_max、sum_sleep_runtime等字段。这些统计不仅用于调试和监控更是CFS实现Sleeper Fairness机制的基础。与早期O(1)调度器显式的sleep_avg计算不同CFS采用了更加数学化的方法通过vruntime的补偿机制隐式识别交互式任务避免了复杂的启发式判断。掌握这些统计字段的含义和使用方法对于以下工作具有重要价值系统调优识别I/O密集型与CPU密集型负载采取针对性的调度策略故障诊断分析调度延迟的根本原因区分资源竞争与配置问题性能研究为调度器相关的学术研究提供数据支撑建议读者在实际环境中运行本文提供的脚本观察不同工作负载下的统计特征从而建立对CFS调度行为的直观理解。参考资源Linux内核源码kernel/sched/fair.c,kernel/sched/stats.c内核文档Documentation/scheduler/sched-design-CFS.rst调度统计文档Documentation/scheduler/sched-stats.txt