正文
关于IO性能的一些学习与了解
摘要
最近心气不高.
学习进度也拖的比较慢.
以后想能够多为自己着想.自己有自己的节奏, 不能只为别人考虑.
要改变一下自己的做事风格. 一些事情想帮则帮, 不想帮就当看不见.
互勉.
磁盘IO的指标
IOPS
RT
BW
部分监控指标的解释
iowait
await
util%
iowait
Percentage of time that the CPU or CPUs were idle during
which the system had an outstanding disk I/O request.
其实 iowait计算的标准就是 CPU在idle时存在IO操作的比率
第一点必须是CPU属于idle的
第二点是进行了io操作
需要说明一下.所有的监控指标都是基于采样的.
所以如果CPU的压力很大, 是不会有太多 iowait的.
如果是单线程专用的情况可能存在io不足导致CPU在等待的情况
但是大多数情况可能就是CPU比较闲,没有太多工作要做.
await
每个I/O的平均耗时,
包括在内核 IO 队列内的时间和在存储设备上执行此 IO 的时间,
所以 await 高可能有两个原因,
一是 IO 在 IO queue 里耗时较长,
二个就是由于 IO 在存储设备上执行的时间比较长,
而 IO 在 IO queue 里耗时较长可能是由于程序一次并发了过多的 IO, 让 IO 在 queue 排队,
IO 在存储设备上执行的时间比较长也有可能时 IO 本身就比较大,
例如在硬盘上写 1KB 文件, 耗时一定是比 1MB的时间短的,
所以 await 高, 还要结合业务本身的特点判断 await 高的原因
来源: https://blog.csdn.net/MrSate/article/details/105372924
util%
这个反映 IO queue, 中存在 IO 在采样周期里的占比,
只要 IO queue 中存在 IO, 就会被计入到 %util 的时间内,
无论是 1 个 IO 或者 100 个IO, 并且也只计算 IO 存在于 queue 里面的时间,
所以此时即使磁盘压力较大, 但是 IO queue 中并没有排队的 IO 那么 %util 也不会高(例如每次 IO size 都比较大),
或者有些程序进行顺序 IO, 完成几个再发下一个, 并且 IO size 并不大, 此时即使磁盘压力较小 %util 也会比较高
一些自己的理解
IO性能虽然有三个比较大的指标, 吞吐量, 响应时间, 每秒IO次数
但是能够进行磁盘优化的地方也很多
需要说明一下. 监控指标是基于很早的机械磁盘来的
但是现阶段因为raid卡以及固态磁盘的飞速发展, 现在再看着三个监控指标的意义其实已经脱离了实际情况.
磁盘是通过磁头的寻道来进行IO块的寻找和基于磁头对盘面进行磁性读取进行数据读取.
早期的磁盘其实磁头比较少, 但是随着现在硬盘技术的发展, 磁头的数量越来越多.
现阶段的硬盘都是盘面旋转, 磁头在旋转带起来的气流将磁头升起来. 然后由步进电机进行寻址和读取写入.
所以理论上的最大寻址时间是 60/转速(rpm), 比如 15000rpm的磁盘,平均寻址时间就是最时间的一半约为 2ms的时间.
前期操作系统的一些调度算法主要是 电梯算法 也是为了将就磁盘磁头进行位置选择来提高寻址和读取的速度.
这里就有了 IO队列数量和IO队列深度的两个概念.
IO对列数量和深度
按照机械磁盘的理解.
IO队列可以理解为 磁头的数量.
队列深度可以理解为 操作系统一次给这个磁头想要读取和写入的任务数量.
基于机械磁盘的一些设置在raid卡的大容量缓存,以及固态硬盘面前变的越来越难以发挥他的性能.
最开始的ACHI 其实只允许一个队列, 并且队列深度是32最大.
但是NVME的存储协议下, 可以有 64000个对列, 并且每个队列都可以有64000的深度.
如果队列深度不够, 就算是磁盘的性能足够好, 也会导致磁盘喂不饱. 显得性能比较弱一些.
关于USE, 利用率 错误率 饱和度
操作系统最容易观测的是自己的行为, 所以很多监控其实更多的考虑的是操作系统层的
到底硬件层的监控其实不是非常多.
比如
%util
表示采样期间, 队列里面有没有IO的请求, 其实并没有考虑多少个队列.
如果可以支持较多的队列,但是仅用了一个队列, 导致利用率很高, 但是实际上磁盘的艳丽并不是很大.
如果提高IO对列数量, 加深队列深度, 还是能够提高性能的
相反, 如果磁盘有压力, 就不能提高太多, 这一块可以通过RT时间来排查,
如果使用率很高, 但是RT时间很短,可以适当加大, 如果RT时间很长, 则需要考虑升级存储.
%iowait
寿命采样期间, CPU没有压力,或者是在等磁盘的返回
这个时候可以采用比如epoll 后者是其他的IO非阻塞模型来提高吞吐量
也可以使用异步模式来提高产品的性能. 当然, 如果此时IOPS和吞吐量都已经到达协议的上限
说明机器磁盘的确存在并且, 需要升级.
await
如果await时间较长, 说明要么硬盘不够快, 要么队列不合理, 需要进行调整
调整也是需要根据 磁盘的吞吐量, IOPS, 以及RT来记性
如果吞吐量低, 速度快, 可能跟队列数量有关系, 或者是调度算法有关, 需要进行处理.
总结
任何事物都要从多个角度来进行查看
不能就一个指标就得出结论
需要辩证的完整的去查看系统性能.
共勉.
