直播回顾：如何对付臭名昭著的 IO 夯？诊断利器来了 | 龙蜥技术

简介：听到IO夯总是让人头疼，那有没有可以分析IO夯问题的利器/p>

一、引言

“为什么 Load 高呢

“因为有 500 多个进程变成了 D 状态。”

“那为什么会有这个多进程 D 状态呢

“因为出现了 IO 夯问题…”

先来看看这个栈，500 多个进程是因为在内核下等待某个磁盘的块设备互斥锁而进入 D 状态，如图 1-1 所示：

图 1-1

互斥锁正被执行读 IO 请求的内核进程 kworker 持有，如图 1-2 所示，只有读 IO 流程完成之后才能释放锁。但是因为 IO 夯住了，读 IO 流程无法顺利完成，所以就没法正常释放锁了。所以接下来就需要找到是访问哪块磁盘出现了 IO 夯O 究竟夯在哪里/p>

图1-2

图1-3

二、史诗级的IO架构

图 2-1

1. 假设我们以一次用户态程序的写 IO 为例，那么在调用 write 时候会传入一个数据 buf，这个 buf 在内核层面也是有对应page的。在默认情况下，IO 会以 buffer io 方式往下走；
2. 假设以 buffer io 方式往下走，走到文件系统层，会将 1 中 buf 里面的数据拷贝到内核 page cache 中，然后把这些 page 置脏，如果此时系统的脏页水位还没有达到系统所设置的阈值，这里就返回了，对用户而言这次 IO 结束了；如果此时脏页水位达到系统所设置的阈值，那么就会启动刷脏流程，这里根据脏页水位具体达到的不同阈值，对用户进程会有不同的处理策略，如短暂休眠或不休眠，在此之后依旧会返回，用户一次 IO 结束；
3. 刷脏是通过 writeback 机制进行，这一流程的触发，可能是通过定期触发，或者如 2 所说水位已经超过系统所设定的阈值了，又或者是用户执行了同步命令或者调用了 sync/fsync 之类的 api 等等。writeback 机制将脏页回写包装成一个个 work，然后这些 work 由系统的 worker 进程，也就是内核的 kworker 进程来执行。刷脏的过程以一个个 inode 为单位，然后将其中的脏页进一步包装成 bio 结构（bio 结构中，会有一个 bio_vec 来描述被包装的脏页 page，简单理解就是会有一个 page 指针指向这个脏页），之后将 bio 提交到 block 层；当然如果此次 IO 涉及到文件系统元数据的变更，中途内核进程 jbd 也会往 block 层提交 bio；
4. bio 进入 block 层之后会经历一系列的限制性的处理，如这个 bio 所包装的数据长度是否过大，有或者是否已经触发到 IO 限流，因为这些机制有点小复杂，就不在图上展示了。在此之后，会尝试与已有的 IO 请求进行合并，具体合并则根据 bio 所描述磁盘上起始扇区和长度与 IO 请求中 bio 描述的磁盘地址是否连续来进行合并。如能合并就不再往下，直接返回了；
5. 如不能合并，则申请一个新的 IO 请求，在多队列架构中，根据磁盘的队列个数和队列深度，在磁盘初始化阶段，在内存上对每条硬件队列已经预先分配了一个 request 集合，同时会有对应的 bitmap 来表示每个请求是否已经被申请。当没有请求可以被申请到时，说明此队列上的 IO 请求已经满了，申请的进程将进入深度休眠等待队列上的 IO 请求已经成功刷到磁盘并释放 IO 请求，才能申请到；
6. 申请到之后，将 bio 包装成 IO 请求——request，将 IO 请求添加到进程的 plug 队列中，当积蓄到一定量的 IO 请求之后，一把“泄洪”到派发队列上；（补充说明：plug队列“蓄流”机制属内核行为，用户无法控制，plug 队列能积累的 IO 请求数也是有限制的；触发“泄洪”，有可能是 plug 队列满了自己触发的，也有可能是提交完一段数据之后，主动调用的内核接口触发）；
7. request 进入派发队列之后，会被派发到驱动层，上图以 virtio blk 为例，request 会被封装成一个个 sg，这些 sg 里面有描述数据 page 的物理地址、本次 IO 访问的磁盘起始扇区、数据长度等信息。之后驱动将 sg 推入到 vring 缓存中，vring缓存在主机上，是主机上 virtio blk 前端和后端磁盘共享的一块可 dma 访问的内存。sg 推入 vring 之后，会 kick 磁盘提取 IO 并通过 dma 完成数据传输，IO 完成之后，磁盘给主机一个中断，virtio blk 驱动从 vring 中取出完成的 request，进入 io cpmplete 路径；
9. 至此，一个 IO 的生命周期结束，而对于 direct io 的方式，整个过程会缺少数据buf复制到内核 page cache、脏页回写这个步骤。上面提到的流程可能不是一个完成 IO 生命周期的全部，由于 IO 链路的复杂性，中间也省掉了部分流程，有兴趣的读者可以再去摸索摸索，或者加入我们系统运维 sig 交流群，欢迎一起探讨。

三、臭名昭著的IO夯

3.1 何为IO夯

IO 夯，可简单理解为 IO 路径在一定程度上堵住了，轻则经过特定路径的 IO 不可访问，重则整条 IO 路径堵住不可用，任你多少 IO 丢下来，我就是没反应。为什么 IO 路径会堵住呢，无外乎是在等待资源。

等待资源一般涉及的是 IO 路径上不可重入的临界区，要求进程持有资源进入、释放资源退出，又或者是事物处理型，允许接受有限个进程的事物，但要等待这些进程的事物全部被处理完之后，才能接收新的进程事物，开始处理新一轮的流程。而当处于临界区内的进程，由于内核 bug 或存储介质原因，导致无法顺利完成 IO 后正常退出，最终造成临界区外的进程因为拿不到资源而处于阻塞状态，导致无 IO 可用。由此可见，只要临界区内的进程不退出这种尴尬的状态，整条 IO 路径就不可用。

图 3-1

图 3-2

经过本小节的介绍，结合章节 2 的 IO 结构图（图 2-1），可以发现 IO 夯是可以发生 IO 路径上的任何地方。

3.2 IO夯的危害

从 3.1 可知，IO 夯会造成有 IO 需求的进程无 IO 可用；从业务稳定性角度来看，对于那些有 IO 访问需求的业务进程，IO 夯可能会引起进程长期阻塞，且在 IO 路径恢复之前，都无法对外提供服务。从系统稳定性角度来看，IO 夯可能会引起大量的进程进入 D 状态，导致系统高负载，甚至系统夯住，shell 命令无法执行，机器无法登陆，最终不得不重启系统去解决。

3.3 IO夯问题分析方法现状

当遇到 IO 夯问题时，我们通常会分析 dmesg 中 hungtask 调用栈、或者是 iosta 信息、sysfs/debugfs 中的统计信息，再结合以往经验去推测问题可能出在哪。当我们碰到如下图 3-3 所示的 iostat 信息时，根据经验，会怀疑是磁盘侧有 IO 没回，因此怀疑io夯在磁盘上，让存储的同学去排查磁盘侧。但这种经验却不一定靠谱，如果是在磁盘返回到 io complete 之间有内核 bug，iostat 也会出现下图中的信息。

图 3-3

那如何分析 IO 夯问题是最有效的呢/strong>答案肯定是要找出来夯住的 IO 请求，然后根据请求里面的信息去分析当前这个请求是处于什么状态、已经走到哪个路径了。但遗憾的是，目前没有实现这个功能的通用工具，唯一能快速实现这一需求的，就只有对问题现场做 crash 分析了，找到夯住的 IO 请求，根据 IO 请求中的信息，再结合代码流程，一步步深入最终找到问题原因，但前提是业务可以容忍这么操作。

3.4 利器简介——sysak iosdiag

sysAK iosdiag，是 sysAK 工具平台中的 IO 诊断工具，已具备 IO 时延探测、IO 夯诊断两大功能，其中 IO 夯诊断可用于检测当前系统中 IO 夯事件并确定问题边界。工具的大体架构图 3-4 所示：

图 3-4

首先通过 sysAK 的 iosdiag 功能去使能 IO 夯诊断，这里诊断到 IO 夯之后，会对 IO 进行数据分析，然后形成诊断结论，诊断结论是以 json 的数据格式保存在一个日志文件里面，同时也支持将数据上传到指定的地方，目前支持 oss 的上传方式，不上传的话，数据也会存在机器本地，供调用者去查看。

图 3-5

工具的性能开销情况：单核 cpu 低于 1%、内存消耗低于 10MB、消耗少许磁盘空间保存诊断结果。

工具支持的内核版本种类：3.10/4.9/4.19多种版本。

iosdiag 诊断结果输出，力求信息准确、结果直观，期望即便不具备内核IO子系统知识的同学也能快速上手。工具会输出一些结论性的信息，如什么时间点，检测到了 IO 事件，这是一个什么样的 IO，从哪个 cpu 发出来的，从哪个磁盘的哪个位置访问多大的数据量，然后这个 IO 夯在哪个路径上，夯住了多久。

图 3-6

四、TODO

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8587 人正在系统学习中