关于IO性能的一些学习与了解

关于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来记性
如果吞吐量低, 速度快, 可能跟队列数量有关系, 或者是调度算法有关, 需要进行处理.

---

总结

任何事物都要从多个角度来进行查看
不能就一个指标就得出结论
需要辩证的完整的去查看系统性能. 

共勉.