共计 2304 个字符，预计需要花费 6 分钟才能阅读完成。
CentOS（Community Enterprise Operating System）作为 Linux 发行版之一，是 Red Hat Enterprise Linux（RHEL）按照凋谢源代码规定公布的源代码所编译而成。因为出自同样的源代码，有些要求高度稳定性的服务器以 CentOS 代替商业版的 Red Hat Enterprise Linux 应用。
最近应用 CentOS 8 的小伙伴可能会发现，CentOS 8 的磁盘性能监控工具 iostat 与 CentOS 7 相比，精准性有所降落，天翼云弹性存储团队在实际过程中发现问题，并用 SFS 弹性文件晋升了 iostat 的监控精确性。
在 Linux 中最罕用的就是 iostat。它可能监控零碎磁盘设施的负载，提供磁盘设施的 IO 合并次数，读写带宽、均匀 IO 大小，均匀队列长度，磁盘利用率等信息。util（utilization）即磁盘设施的利用率，代表了磁盘设施有百分之多少的工夫用于解决 IO，如果 util 长期处于 100%，阐明 IO 压力过大，磁盘已满负荷工作。同样都是满负荷工作的状况下，iostat 中 util 的统计在 CentOS 7 与 CentOS 8 中，显示存在显著差别：
CentOS 7：
CentOS 8：
同一个环境，压力测试把磁盘压满的状况下，CentOS 7 的 util 曾经显示 100% 了，CentOS 8 的 util 可能还不到 75%。
iostat 中的 util，代表过来的一段时间内, 存储设备解决 IO 的工夫占总工夫的百分比。设施解决 IO 的工夫是由设施在内核中的 io_ticks 属性保护：
io_ticks 代表设施解决 IO 的总工夫，是一个一直累加的值。io_ticks 不关怀队列中有多少个 IO 在排队，它只关怀设施有 IO 的工夫。即不思考 IO 有多少，只思考 IO 有没有。如果工夫过来了 1s，其中的 500ms 设施中有 IO，io_ticks 就会减少 500，util 就是依据这个算式计算出的：io_ticks/ 总 ticks=500/1000=50%。
CentOS 7 降级到 CentOS 8，util 显示呈现了如此大的差别，就是因为在 io_ticks 的算法上，进行了变动。
tips：
对于机械盘，IO 是串行的，util 能精确的反映磁盘的忙碌水平。但对于 SSD，因为 IO 能够并行处理，通过 util 就无奈间接示意磁盘忙碌水平，但还是有肯定参考价值。
原理剖析
在 CentOS 7 中，在每次 IO 开始、合并、完结及查问时，都会调用 part_round_stats_single 判断以后是否有 IO 申请在被解决，若有 IO 申请则依据工夫戳与以后工夫差值累加 io_ticks，绝对比拟精确：
这两头就须要用到一个重要的变量，磁盘的 inflight。inflight 示意以后设施中未实现的 IO 申请数量，在 CentOS 7 中是通过每次 IO 开始时加 1，完结时减 1 来实现对 inflight 的保护。
而在最新内核中，因为多队列的利用，计算 inflight 时会遍历所有解决中的 IO 申请，判断是否在以后磁盘以统计 inflight。
如果为了统计 io_ticks，每次都去遍历所有 IO，就会影响 IO 的效率。所以在 CentOS 8 中，计算 io_ticks 时摈弃了 inflight 值，通过每次 IO 时调用 update_io_ticks，如果发现不在同一个 jiffies 就对 io_ticks 加 1，并将以后工夫赋予 stamp。
然而这个改良有一个很显著的问题，在存储较快时不会有问题（iops > 1000）。然而在存储较慢时，比方一个 IO 继续多个 jiffies，当 IO end 的时候经验了多个 jiffies，后果也只对 io_ticks 加 1，会导致 utils 精度失落很多。
这个问题存在了近 2 年，才在 2020 年失去了修复，通过每次 IO end 的时候将 stamp-jiffies 的工夫退出 io_tick，缩小误差：
但还是不能解决以下这种场景：如果第一个 io 还没有完结，通过了 n 个 jiffies，第二个 io 进来了，它会将 stamp 设置为以后 jiffies，这个时候，stamp 比之前第一个 IO 记录的值就少了 n，IO 完结时的减少的 io_ticks 就会少 n，同样失落了精确度。如下图所示：
因为内核没有在每次 IO 时计算 inflight，也就无奈判断是否须要对 io ticks 加上 jiffies，这个问题就遗留了下来，导致了 iostat 监控后果的不精确，目前来说开源社区也没有太好的解决方案。
天翼云的改良
针对社区高版本内核对慢速设施 util 统计不准确的问题，天翼云 SFS 弹性文件设计了兼容老版本 io_ticks 统计办法的计划，实用于对于 util 精确度要求较高的场景，能够实时开启 / 敞开基于 inflight 的精准 io_ticks 统计，让用户在应用 CentOS 8 零碎的同时也能享受到 CentOS 7 的精准 iostat 监控程度。
sfs-tools 定义了须要跟踪的内核函数及从内核函数中提取相干的时延等数据的办法，并实现了对数据的二次加工和展现，其架构设计如下：
sfs_tools 能够作为独立的工具应用，也能够作为文件网关的一个个性对外提供各项监控数据。目前该工具已集成天翼云文件存储的监控告警平台。
除此之外，天翼云 SFS 弹性文件还在纠正了精准度的根底上进一步提供了自研的性能监控工具，通过对内核文件函数接口的跟踪，在不影响性能的状况下，提供基于函数及文件级别的 iops，读写提早等监控数据，不便了更多开发者、用户对支流开源零碎的应用。
将来，天翼云将持续保持自主翻新，施展本身技术劣势，继续晋升创新能力与外围竞争力，为自主可控、牢靠高效的云计算基础架构添砖加瓦，为国家信息技术产业的倒退提供松软的技术保障。
