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，读写提早等监控数据，不便了更多开发者、用户对支流开源零碎的应用。

将来，天翼云将持续保持自主翻新，施展本身技术劣势，继续晋升创新能力与外围竞争力，为自主可控、牢靠高效的云计算基础架构添砖加瓦，为国家信息技术产业的倒退提供松软的技术保障。