Linux 内核中的调度模型从磁盘 IO 调度算法到系统级资源瓶颈分析引言Linux 的调度并不只有 CPU 调度。很多线上问题表面上看是“CPU 慢了”实际根因却是磁盘 IO 排队、文件系统提交、页缓存回收或者块设备队列被打满。真正有价值的性能分析不是盯着一个指标看而是把“谁在排队、为什么排队、排在哪一层”讲清楚。本文从磁盘 IO 调度器讲起向上连接到系统级资源瓶颈分析最后落到可执行的诊断方法。重点不是背算法名而是理解不同调度策略背后的取舍以及这些取舍会在生产环境里表现成什么现象。一、Linux 调度模型的整体视角Linux 内核里的“调度”可以分成两层看CPU 调度决定哪个任务先拿到 CPUIO 调度决定哪个 IO 请求先进入设备队列这两层彼此影响。一个进程如果因为磁盘 IO 阻塞就会睡眠并让出 CPU反过来CPU 忙不过来时IO 完成中断和提交路径也会被拖慢。很多系统瓶颈并不是单点故障而是 CPU、内存、文件系统和块设备之间的连锁反应。1.1 CPU 调度只解决“谁跑”IO 调度解决“谁先写盘”CPU 调度关注的是 runnable task也就是“已经准备好运行”的任务。IO 调度关注的是 block layer 上等待下发给设备的请求。二者属于不同队列优化手段也不同。一个常见误区是看到 iowait 高就以为只要换更快的磁盘就行。实际上iowait 高可能是真正的存储慢队列太长延迟被放大文件系统同步写太多内存不足频繁回写和回收上层应用一次性发了太多并发请求二、进程调度CFS 为什么适合通用负载Linux 默认的进程调度器是 CFS核心目标不是简单轮转而是尽量让任务获得“公平”的 CPU 时间。2.1 CFS 的核心思想CFS 维护的是虚拟运行时间vruntime。任务真正执行得越多vruntime增长越快权重更高的任务增长得更慢。调度器总是优先挑选vruntime最小的任务运行。这样设计的结果有两个CPU 资源更均衡权重大的任务可以获得更长的有效运行时间struct sched_entity { struct load_weight load; u64 vruntime; u64 sum_exec_runtime; struct rb_node run_node; };2.2 CFS 的实际意义在生产系统里CFS 的价值不是“看起来公平”而是让不同类型任务能在同一台机器上共存。比如后台批处理不会轻易饿死前台请求高优先级业务可以通过权重获得更稳定的响应任务切换的整体开销比较可控但要注意CPU 调度再公平也无法解决磁盘慢的问题。一个进程可能是因为 IO 阻塞而“看起来不占 CPU”这时真正的瓶颈在别处。三、磁盘 IO 调度不是越复杂越好IO 调度器的任务是在块设备发出请求之前对请求进行排序、合并和节流。它的目标通常有三个减少寻道和访问抖动控制延迟避免某类请求长期排队在吞吐量和公平性之间做平衡3.1 机械盘和 SSD 的差异决定了调度策略传统机械硬盘有明显的物理寻道成本所以“顺序访问”非常重要。把相近位置的请求合并在一起可以显著减少磁头移动。SSD 没有机械寻道但仍然存在设备内部并行度限制写放大队列拥塞读写延迟不对称所以SSD 时代并不是“不需要调度”而是“调度目标变了”。重点从减少寻道逐渐转向控制延迟、保护关键请求和减少队列抖动。3.2 常见调度思路noop / none最简单的策略尽量少做事情更多把排序交给下层设备或硬件队列。适合场景存储设备自己有较强的内部调度能力虚拟化环境中底层已经做了充分整形对 CPU 开销敏感且不希望内核层再做额外排序deadline核心思想是给每个请求设置截止时间避免某类请求长期饥饿。它通常会维护读写队列并优先处理快要超时的请求。适合场景读延迟敏感需要抑制写请求长期占队列业务对尾延迟比较敏感BFQ更强调按进程或 cgroup 维度的公平性适合交互型负载较多的系统。适合场景桌面环境多租户公平性要求高希望限制某些任务过度抢占 IOmq-deadline / kyber / none现代 Linux 的多队列块层更强调并行提交和设备特性匹配。实际选型时往往不是追求“最强调度”而是选一个与底层存储最匹配、最少额外开销的策略。3.3 典型对比策略核心目标优点代价适用场景noop / none尽量少干预CPU 开销低不主动优化请求顺序SSD、虚拟化、底层已整形deadline控制延迟和饥饿尾延迟更稳有额外排序和超时管理成本数据库、读延迟敏感业务BFQ公平分配多任务体验好调度复杂度更高桌面、多租户公平性四、IO 调度为什么会成为系统瓶颈IO 调度本来是为了优化系统但在某些负载下它本身也会变成瓶颈。原因通常不是算法名字而是请求规模、竞争强度和设备能力不匹配。4.1 典型开销来源请求排序和插入成本队列锁竞争合并请求的判断成本超时管理和定时检查上层请求过密导致队列持续满载当 IO 请求量很低时这些成本几乎可以忽略当系统进入高并发写入、日志刷盘、批量导入、数据库 checkpoint 之类的场景时调度器和块层开销会被明显放大。4.2 瓶颈并不总是在磁盘下面这些症状经常会误导排查方向iostat里%util接近 100%但实际设备并没有到物理极限应用延迟高但磁盘吞吐量并不高await很大svctm却不一定能说明问题CPU 看起来不满但进程却响应很慢这类问题往往说明“队列深了”而不是“盘完全不够快”。也就是说请求在进入设备之前就已经堆积起来了。4.3 一个更完整的链路flowchart LR A[应用线程发起读写] -- B[页缓存/文件系统] B -- C[块层请求合并] C -- D[IO 调度器排序] D -- E[设备队列] E -- F[存储设备执行] F -- G[完成中断/回调] G -- A瓶颈可能出现在任一层应用层请求模式不合理文件系统层同步写、元数据更新频繁块层队列过深、排序开销过高设备层真实吞吐打满五、如何判断系统到底卡在哪里最有用的排查方式不是先猜而是沿着“现象 - 队列 - 设备 - 进程”逐层缩小范围。5.1 先看系统级症状先确认是 CPU 问题、内存问题还是 IO 问题。常用观察项工具关注点典型含义top/htop%wa、负载、进程状态是否大量任务在等 IOvmstatr、b、si、so是否存在阻塞和换页iostatawait、aqu-sz、util队列是否过深pidstat -d进程级 IO谁在制造 IOsar -d设备历史统计延迟是否持续升高5.2 再看进程级行为如果某个服务延迟高要回答三个问题是谁在读写磁盘是读多还是写多是同步 IO 还是后台刷盘比如数据库延迟抖动可能是 checkpoint 或 flush 太集中日志服务卡顿可能是写入太频繁且同步提交太重搜索服务慢可能是随机读过多导致队列被打散5.3 最后看设备层指标如果设备层已经接近瓶颈常见特征是队列深度长期较高读写延迟明显上升吞吐没有继续增长但等待时间持续变长这时继续加并发通常不会让系统更快只会让排队更长。六、实战诊断流程下面是一套更适合线上排障的顺序。6.1 第一步确认是不是 IO 瓶颈看三个信号应用响应时间是否升高%wa是否显著增加iostat的await和aqu-sz是否同时上升如果这三个信号同时成立基本可以先按 IO 问题排查。6.2 第二步确认是读慢还是写慢读慢通常更影响在线请求的尾延迟写慢通常更影响刷新、提交、落盘和后台任务如果读写混在一起要区分同步路径和后台路径。很多“写慢”其实是应用在等落盘确认而不是设备写不进去。6.3 第三步确认是队列问题还是设备问题判断思路很简单如果队列深、延迟高但吞吐没到硬件极限优先看调度和并发模型如果吞吐已经接近设备上限优先看是否需要扩容或换介质6.4 第四步检查内存是否在拖后腿很多 IO 慢并不是盘慢而是内存不足导致页缓存命中率下降频繁回收脏页回写集中抖动加重所以在看磁盘前也要看内存是否把系统拖进了“边读边回收”的状态。七、调优思路不是盲调参数而是先定目标IO 调优的第一原则是先明确你想优化什么降低尾延迟提升平均吞吐减少 CPU 开销提升多租户公平性不同目标答案不同。7.1 什么时候应该尽量减少调度干预如果底层是 SSD、NVMe 或云盘并且设备本身已经有较强的内部调度能力那么内核层过度排序未必有收益。此时更重要的是让请求路径尽量短减少不必要的合并和锁竞争控制上层并发避免队列过深7.2 什么时候需要更强的调度策略如果业务对尾延迟很敏感或者存在明显的读写竞争那么带延迟控制能力的策略往往更合适。尤其是数据库、日志系统、事务型应用常常需要优先保护读请求和关键写请求。7.3 参数调优要围绕负载特征不要直接照搬别人的参数。应该先看设备类型机械盘、SSD、NVMe、云盘负载类型随机读、顺序写、混合读写IO 深度单线程还是高并发同步比例同步写多不多是否有缓存页缓存和应用缓存是否覆盖了大部分请求八、示例从系统视角理解调度效果sequenceDiagram participant App as 应用 participant FS as 文件系统 participant Scheduler as IO调度器 participant Disk as 存储设备 App-FS: 发起读写请求 FS-Scheduler: 生成块 IO 请求 Scheduler-Scheduler: 排序/合并/限流 Scheduler-Disk: 下发请求 Disk--Scheduler: 完成返回 Scheduler--FS: 通知完成 FS--App: 唤醒等待线程这个链路里任何一层变慢都会放大到应用延迟文件系统层慢应用线程先卡住调度器层慢设备还没忙起来队列先堆满设备层慢所有上层都要跟着等待所以排查时不能只看“磁盘忙不忙”还要看“请求是不是已经在前面堵住了”。九、创业团队为什么要关心这件事对创业团队来说IO 调度不是纯底层知识它会直接影响成本和交付稳定性。同样的机器能跑更多请求意味着单位成本更低尾延迟更稳意味着用户体验更可控能快速定位瓶颈意味着事故恢复更快真正有价值的不是把每个调度器名字背下来而是建立一套判断方法看到慢先判断在哪一层慢看到高延迟先判断是排队还是执行慢看到抖动先判断是并发问题还是介质问题总结Linux 的调度模型不是单一算法而是一整套围绕 CPU、内存、文件系统和块设备的资源协调机制。CPU 调度解决“谁运行”IO 调度解决“谁先进设备”系统级瓶颈分析则要回答“为什么会排队、排在哪一层、怎么降低排队成本”。对于线上系统来说最实用的能力不是记住某个调度器的名字而是能迅速把问题分成三类设备真的慢、队列排太长、上层请求模式不合理。只要这条判断链清楚IO 优化就不再是拍脑袋调参数而是可以被验证、复现和持续迭代的工程工作。
Linux 内核中的调度模型：从磁盘 IO 调度算法到系统级资源瓶颈分析
发布时间：2026/6/5 19:53:40
Linux 内核中的调度模型从磁盘 IO 调度算法到系统级资源瓶颈分析引言Linux 的调度并不只有 CPU 调度。很多线上问题表面上看是“CPU 慢了”实际根因却是磁盘 IO 排队、文件系统提交、页缓存回收或者块设备队列被打满。真正有价值的性能分析不是盯着一个指标看而是把“谁在排队、为什么排队、排在哪一层”讲清楚。本文从磁盘 IO 调度器讲起向上连接到系统级资源瓶颈分析最后落到可执行的诊断方法。重点不是背算法名而是理解不同调度策略背后的取舍以及这些取舍会在生产环境里表现成什么现象。一、Linux 调度模型的整体视角Linux 内核里的“调度”可以分成两层看CPU 调度决定哪个任务先拿到 CPUIO 调度决定哪个 IO 请求先进入设备队列这两层彼此影响。一个进程如果因为磁盘 IO 阻塞就会睡眠并让出 CPU反过来CPU 忙不过来时IO 完成中断和提交路径也会被拖慢。很多系统瓶颈并不是单点故障而是 CPU、内存、文件系统和块设备之间的连锁反应。1.1 CPU 调度只解决“谁跑”IO 调度解决“谁先写盘”CPU 调度关注的是 runnable task也就是“已经准备好运行”的任务。IO 调度关注的是 block layer 上等待下发给设备的请求。二者属于不同队列优化手段也不同。一个常见误区是看到 iowait 高就以为只要换更快的磁盘就行。实际上iowait 高可能是真正的存储慢队列太长延迟被放大文件系统同步写太多内存不足频繁回写和回收上层应用一次性发了太多并发请求二、进程调度CFS 为什么适合通用负载Linux 默认的进程调度器是 CFS核心目标不是简单轮转而是尽量让任务获得“公平”的 CPU 时间。2.1 CFS 的核心思想CFS 维护的是虚拟运行时间vruntime。任务真正执行得越多vruntime增长越快权重更高的任务增长得更慢。调度器总是优先挑选vruntime最小的任务运行。这样设计的结果有两个CPU 资源更均衡权重大的任务可以获得更长的有效运行时间struct sched_entity { struct load_weight load; u64 vruntime; u64 sum_exec_runtime; struct rb_node run_node; };2.2 CFS 的实际意义在生产系统里CFS 的价值不是“看起来公平”而是让不同类型任务能在同一台机器上共存。比如后台批处理不会轻易饿死前台请求高优先级业务可以通过权重获得更稳定的响应任务切换的整体开销比较可控但要注意CPU 调度再公平也无法解决磁盘慢的问题。一个进程可能是因为 IO 阻塞而“看起来不占 CPU”这时真正的瓶颈在别处。三、磁盘 IO 调度不是越复杂越好IO 调度器的任务是在块设备发出请求之前对请求进行排序、合并和节流。它的目标通常有三个减少寻道和访问抖动控制延迟避免某类请求长期排队在吞吐量和公平性之间做平衡3.1 机械盘和 SSD 的差异决定了调度策略传统机械硬盘有明显的物理寻道成本所以“顺序访问”非常重要。把相近位置的请求合并在一起可以显著减少磁头移动。SSD 没有机械寻道但仍然存在设备内部并行度限制写放大队列拥塞读写延迟不对称所以SSD 时代并不是“不需要调度”而是“调度目标变了”。重点从减少寻道逐渐转向控制延迟、保护关键请求和减少队列抖动。3.2 常见调度思路noop / none最简单的策略尽量少做事情更多把排序交给下层设备或硬件队列。适合场景存储设备自己有较强的内部调度能力虚拟化环境中底层已经做了充分整形对 CPU 开销敏感且不希望内核层再做额外排序deadline核心思想是给每个请求设置截止时间避免某类请求长期饥饿。它通常会维护读写队列并优先处理快要超时的请求。适合场景读延迟敏感需要抑制写请求长期占队列业务对尾延迟比较敏感BFQ更强调按进程或 cgroup 维度的公平性适合交互型负载较多的系统。适合场景桌面环境多租户公平性要求高希望限制某些任务过度抢占 IOmq-deadline / kyber / none现代 Linux 的多队列块层更强调并行提交和设备特性匹配。实际选型时往往不是追求“最强调度”而是选一个与底层存储最匹配、最少额外开销的策略。3.3 典型对比策略核心目标优点代价适用场景noop / none尽量少干预CPU 开销低不主动优化请求顺序SSD、虚拟化、底层已整形deadline控制延迟和饥饿尾延迟更稳有额外排序和超时管理成本数据库、读延迟敏感业务BFQ公平分配多任务体验好调度复杂度更高桌面、多租户公平性四、IO 调度为什么会成为系统瓶颈IO 调度本来是为了优化系统但在某些负载下它本身也会变成瓶颈。原因通常不是算法名字而是请求规模、竞争强度和设备能力不匹配。4.1 典型开销来源请求排序和插入成本队列锁竞争合并请求的判断成本超时管理和定时检查上层请求过密导致队列持续满载当 IO 请求量很低时这些成本几乎可以忽略当系统进入高并发写入、日志刷盘、批量导入、数据库 checkpoint 之类的场景时调度器和块层开销会被明显放大。4.2 瓶颈并不总是在磁盘下面这些症状经常会误导排查方向iostat里%util接近 100%但实际设备并没有到物理极限应用延迟高但磁盘吞吐量并不高await很大svctm却不一定能说明问题CPU 看起来不满但进程却响应很慢这类问题往往说明“队列深了”而不是“盘完全不够快”。也就是说请求在进入设备之前就已经堆积起来了。4.3 一个更完整的链路flowchart LR A[应用线程发起读写] -- B[页缓存/文件系统] B -- C[块层请求合并] C -- D[IO 调度器排序] D -- E[设备队列] E -- F[存储设备执行] F -- G[完成中断/回调] G -- A瓶颈可能出现在任一层应用层请求模式不合理文件系统层同步写、元数据更新频繁块层队列过深、排序开销过高设备层真实吞吐打满五、如何判断系统到底卡在哪里最有用的排查方式不是先猜而是沿着“现象 - 队列 - 设备 - 进程”逐层缩小范围。5.1 先看系统级症状先确认是 CPU 问题、内存问题还是 IO 问题。常用观察项工具关注点典型含义top/htop%wa、负载、进程状态是否大量任务在等 IOvmstatr、b、si、so是否存在阻塞和换页iostatawait、aqu-sz、util队列是否过深pidstat -d进程级 IO谁在制造 IOsar -d设备历史统计延迟是否持续升高5.2 再看进程级行为如果某个服务延迟高要回答三个问题是谁在读写磁盘是读多还是写多是同步 IO 还是后台刷盘比如数据库延迟抖动可能是 checkpoint 或 flush 太集中日志服务卡顿可能是写入太频繁且同步提交太重搜索服务慢可能是随机读过多导致队列被打散5.3 最后看设备层指标如果设备层已经接近瓶颈常见特征是队列深度长期较高读写延迟明显上升吞吐没有继续增长但等待时间持续变长这时继续加并发通常不会让系统更快只会让排队更长。六、实战诊断流程下面是一套更适合线上排障的顺序。6.1 第一步确认是不是 IO 瓶颈看三个信号应用响应时间是否升高%wa是否显著增加iostat的await和aqu-sz是否同时上升如果这三个信号同时成立基本可以先按 IO 问题排查。6.2 第二步确认是读慢还是写慢读慢通常更影响在线请求的尾延迟写慢通常更影响刷新、提交、落盘和后台任务如果读写混在一起要区分同步路径和后台路径。很多“写慢”其实是应用在等落盘确认而不是设备写不进去。6.3 第三步确认是队列问题还是设备问题判断思路很简单如果队列深、延迟高但吞吐没到硬件极限优先看调度和并发模型如果吞吐已经接近设备上限优先看是否需要扩容或换介质6.4 第四步检查内存是否在拖后腿很多 IO 慢并不是盘慢而是内存不足导致页缓存命中率下降频繁回收脏页回写集中抖动加重所以在看磁盘前也要看内存是否把系统拖进了“边读边回收”的状态。七、调优思路不是盲调参数而是先定目标IO 调优的第一原则是先明确你想优化什么降低尾延迟提升平均吞吐减少 CPU 开销提升多租户公平性不同目标答案不同。7.1 什么时候应该尽量减少调度干预如果底层是 SSD、NVMe 或云盘并且设备本身已经有较强的内部调度能力那么内核层过度排序未必有收益。此时更重要的是让请求路径尽量短减少不必要的合并和锁竞争控制上层并发避免队列过深7.2 什么时候需要更强的调度策略如果业务对尾延迟很敏感或者存在明显的读写竞争那么带延迟控制能力的策略往往更合适。尤其是数据库、日志系统、事务型应用常常需要优先保护读请求和关键写请求。7.3 参数调优要围绕负载特征不要直接照搬别人的参数。应该先看设备类型机械盘、SSD、NVMe、云盘负载类型随机读、顺序写、混合读写IO 深度单线程还是高并发同步比例同步写多不多是否有缓存页缓存和应用缓存是否覆盖了大部分请求八、示例从系统视角理解调度效果sequenceDiagram participant App as 应用 participant FS as 文件系统 participant Scheduler as IO调度器 participant Disk as 存储设备 App-FS: 发起读写请求 FS-Scheduler: 生成块 IO 请求 Scheduler-Scheduler: 排序/合并/限流 Scheduler-Disk: 下发请求 Disk--Scheduler: 完成返回 Scheduler--FS: 通知完成 FS--App: 唤醒等待线程这个链路里任何一层变慢都会放大到应用延迟文件系统层慢应用线程先卡住调度器层慢设备还没忙起来队列先堆满设备层慢所有上层都要跟着等待所以排查时不能只看“磁盘忙不忙”还要看“请求是不是已经在前面堵住了”。九、创业团队为什么要关心这件事对创业团队来说IO 调度不是纯底层知识它会直接影响成本和交付稳定性。同样的机器能跑更多请求意味着单位成本更低尾延迟更稳意味着用户体验更可控能快速定位瓶颈意味着事故恢复更快真正有价值的不是把每个调度器名字背下来而是建立一套判断方法看到慢先判断在哪一层慢看到高延迟先判断是排队还是执行慢看到抖动先判断是并发问题还是介质问题总结Linux 的调度模型不是单一算法而是一整套围绕 CPU、内存、文件系统和块设备的资源协调机制。CPU 调度解决“谁运行”IO 调度解决“谁先进设备”系统级瓶颈分析则要回答“为什么会排队、排在哪一层、怎么降低排队成本”。对于线上系统来说最实用的能力不是记住某个调度器的名字而是能迅速把问题分成三类设备真的慢、队列排太长、上层请求模式不合理。只要这条判断链清楚IO 优化就不再是拍脑袋调参数而是可以被验证、复现和持续迭代的工程工作。
)
