你了解自己的业务 IO 么？

我们为什么要关注业务的 IO 行为，或者 IO 访问模型呢？原因很简单，任何系统都要关注自己服务的对象，存储系统服务的对象就是上层应用，所以存储的研发离不开对业务行为的分析和研究。存储系统的整体设计和架构，是多种因素综合权衡的结果。在存储系统性能达到极限的时候，无论是存储的开发者还是使用者，都想知道 IO 的具体表现行为，开发者是为了能够找到瓶颈点，更好地优化存储系统，使用者是为了能够更优地使用存储系统，让业务稳定运行。

常见业务类型的 IO 特点

我们先基于几个典型的业务场景，介绍一下这些场景下 IO 模型的特点。

记录日志

日志文件通常情况都是追加写入，在每一次写之前，都需要调用 statfs 获取文件大小，以此作为 pos（新内容插入位置）写入数据，因此 write 和 statfs 的请求比例是 1:1。反过来，如果发现在某个客户端的请求统计中发现，write/stat 请求比例接近 1:1，基本可以断定，此客户端上的业务基本上是文件的追加写业务。如果面对这种日志 IO 类型在存储整体访问中占比比较高的用户，在需要提升系统整体性能时，可以建议用户扩大日志文件的写入 buffer，从而减少 write/stat 的请求次数，达到性能优化的效果。

系统命令 du/ls

操作系统的几个命令对于分布式文件存储来说，都不是特别友好，比如说 ls/du，尤其是 du 命令。du 命令会调用 readdir，获取 entry 列表，再依此调用 statfs 获取文件 size，如果是目录，还会递归查询统计，因此是多个 readdir 和多个 statfs 请求的组合，并且穿插调用，对于多 MDS 架构的文件系统，通常每个 MDS 都会处理大量 readdir 和 statfs 的请求。ls 命令也是 readdir 和 stat 的组合，但是跟 du 不同的是，ls 只会统计单一目录下的 stat 信息，因此是一个 readdir 和多个 statfs 请求。假如日常巡检的时候发现某个 MDS 负载较高，可以查看该 MDS 的负载类型，如果都集中在 readdir/statfs，那么基本可以断定，有业务在执行系统统计命令，可以根据请求发送的客户端 IP，获取到是哪个客户端发起的请求，进而可以查到是哪个业务触发的系统指令。

数据库

数据库的读写比例一般符合二八原则，20%是写，80%为读，在写的时候，以 8KB，16KB 为主，并且每一个写请求都会附带一个 fsync 请求和一个 fdatasync 请求，用来保证数据持久化到存储上，对于采用 buffered cache 的分布式文件存储，fsync 带来的系统开销会比较大，进而导致数据库的写入性能较差，假如用户有数据业务的需求，建议采用 direct IO 的方式。MySQL 的存储引擎 InnoDB 中有一项设置——innodb_flush_method，这项设置负责控制 InnoDB 写入数据时所使用的系统调用。我们会建议用户采用 O_DIRECT_NO_FSYNC，即只使用 O_DIRECT 方式，绕过 pagecache，将数据直接写入磁盘，并在写操作时跳过 fsync()更新日志的元数据信息。在 8.0.14 版本之后， MySQL 会在创建文件、增加文件长度以及关闭文件时自动调用 fsync()来更新 MySQL 文件在文件系统中的元数据信息。

AI 训练

大家都知道，在 AI 训练过程中，数据 90%以上都是读操作，并且是小文件的顺序读或大文件的随机读。在训练过程中，数据集是不会被修改和删除的，元数据的操作集中在 open/close/stat/revalidate，不会有特殊的元数据操作，数据操作就是 read。基于这种 IO 特点，当需要进一步提升性能时，可以选择性弱化某些 POSIX 语义，甚至是降低数据的一致性，比如说在客户端增加弱化一致性之后的读缓存，从而大大提升训练过程中对数据的读取速度，缩短训练时间。

分析业务 IO 模型的方法

分析业务 IO 的模型有两种方式，可以通过阅读业务的源码，或者是通过存储系统提供的 IO 分析工具。然而，阅读业务源码大多数时候并不现实，而且对于存储开发人员或者运维人员，也没有这个必要，所以更多时候，只能依靠存储系统提供的 IO 分析工具。

在大规模存储系统中，分析业务的 IO 行为是一套非常复杂的流程，尤其是分布式文件存储，文件存储需要实现一套标准 POSIX 语义的文件接口，丰富的接口带来的困扰就是需要监控和分析更多的 IO 操作类型，分析的难度也就更大。对文件存储来说，我们需要关注两类 IO，元数据和数据。元数据 IO 主要包括文件/目录的元数据操作，比如说 open/close/mkdir/rmdir/stat/unlink/revalidate/hardlink/rename 等，数据 IO 主要包括 read/write，在统计 read/write 的时候，还要统计对应的 IOPS 和 BW。遗憾的是，市场上常用的文件存储产品和方案也很少提供方便的工具帮助管理员系统地了解业务 IO 特点。

我们是怎么做的

俗话说，工欲善其事，必先利其器。为了能够对各种业务系统 IO 特点有更深入和全面的掌握， YRCloudFile 专门实现了一套 IO 统计框架，方便管理员实时了解和分析业务 IO 特点，我们也可以通过这个功能对存储系统做针对性的优化。

当 YRCloudFile 客户端连接到存储集群后，集群将自动加载并开始监控客户端的元数据及数据请求行为，同时在界面上实时展示。

• 元数据请求：客户端为了获取元数据信息而做的请求，请求类型多种多样，一般来说，比较常发生的元数据请求大概可以分为 3 类：

• 文件数据请求：指的是客户端或者元数据服务为了获取文件数据或者信息所做的请求，注意并不是所有文件数据请求都是读写文件数据本身的。文件数据请求主要有以下 8 种：

YRCloudFile 的客户端监控功能，涵盖了 35 项元数据操作请求和 17 项文件数据操作请求，用户可以根据生产的实际情况来设置最常使用的 OPS 选项作为重点观察项。该功能不仅能实时展示各 OPS 的情况，还能按天平均和周平均 OPS 来展示、排序和导出，为 CTO 和管理团队对系统资源的调配、优化运营提供精准的数据支撑。

通过这个功能，用户可以很清晰地看到各个客户端的 IO 统计分布。同时也可以根据自身情况，选择性监控某些操作类型和某些客户端，还可以根据某种操作类型进行排队，让用户能够快速定位和分析各个客户端的情况。焱融科技的研发团队也可以根据这些 IO 特征的分析，为用户的业务进行针对性的系统优化。