咱们为什么要关注业务的 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 特色的剖析，为用户的业务进行针对性的系统优化。