说说IO（三）- IO性能的重要指标

最新推荐文章于 2023-02-14 08:27:58 发布

Q蛋黄酱

最新推荐文章于 2023-02-14 08:27:58 发布

阅读量269

点赞数

分类专栏：操作系统，IO

操作系统，IO 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

最重要的三个指标

IOPS

IOPS ，即每秒钟处理的 IO 请求数量。 IOPS 是随机访问类型业务（ OLTP 类）很重要的一个参考指标。

一块物理硬盘能提供多少 IOPS ？

从磁盘上进行数据读取时，比较重要的几个时间是：寻址时间 （找到数据块的起始位置），旋转时间 （等待磁盘旋转到数据块的起始位置），传输时间 （读取数据的时间和返回的时间）。其中寻址时间是固定的（磁头定位到数据的存储的扇区即可），旋转时间受磁盘转速的影响，传输时间受数据量大小的影响和接口类型的影响（不用硬盘接口速度不同），但是在随机访问类业务中，他的时间也很少。因此，在硬盘接口相同的情况下， IOPS主要受限于寻址时间和传输时间。以一个 15K 的硬盘为例，寻址时间固定为 4ms ，传输时间为60s/15000*1/2=2ms ，忽略传输时间。 1000ms/6ms=167 个 IOPS 。

OS 的一次 IO 请求对应物理硬盘一个 IO 吗？

在没有文件系统、没有 VM （卷管理）、没有 RAID 、没有存储设备的情况下，这个答案还是成立的。但是当这么多中间层加进去以后，这个答案就不是这样了。物理硬盘提供的 IO 是有限的，也是整个 IO 系统存在瓶颈的最大根源。所以，如果一块硬盘不能提供，那么多块在一起并行处理，这不就行了吗？确实是这样的。可以看到，越是高端的存储设备的 cache 越大，硬盘越多，一方面通过cache 异步处理IO ，另一方面通过盘数增加，尽可能把一个OS 的IO 分布到不同硬盘上，从而提高性能。文件系统则是在 cache 上会影响，而 VM则可能是一个 IO 分布到多个不同设备上（ Striping ）。

所以，一个 OS 的IO 在经过多个中间层以后，发生在物理磁盘上的IO 是不确定的。可能是一对一个，也可能一个对应多个 。

IOPS 能算出来吗？

对单块磁盘的 IOPS 的计算没有没问题，但是当系统后面接的是一个存储系统时、考虑不同读写比例， IOPS 则很难计算，而需要根据实际情况进行测试。主要的因素有：

- 存储系统本身有自己的缓存 。缓存大小直接影响 IOPS ，理论上说，缓存越大能 cache 的东西越多，在 cache 命中率保持的情况下， IOPS 会越高。
- RAID 级别 。不同的 RAID 级别影响了物理 IO 的效率。
- 读写混合比例 。对读操作，一般只要 cache 能足够大，可以大大减少物理 IO ，而都在 cache 中进行；对写操作，不论 cache 有多大，最终的写还是会落到磁盘上。因此， 100% 写的 IOPS 要越是小于 100% 的读的 IOPS 。同时， 100% 写的 IOPS 大致等同于存储设备能提供的物理的 IOPS 。
- 一次IO 请求数据量的多少 。一次读写 1KB 和一次读写 1MB ，显而易见，结果是完全不同的。

当时上面 N 多因素混合在一起以后， IOPS 的值就变得扑朔迷离了。所以，一般需要通过实际应用的测试才能获得。

IO Response Time

即 IO 的响应时间。 IO 响应时间是从操作系统内核发出一个 IO 请求到接收到 IO 响应的时间。因此， IO Response time 除了包括磁盘获取数据的时间，还包括了操作系统以及在存储系统内部 IO 等待的时间。一般看，随 IOPS 增加，因为 IO 出现等待， IO 响应时间也会随之增加。对一个 OLTP 系统， 10ms 以内的响应时间，是比较合理的。下面是一些 IO 性能示例：

一个8K 的 IO 会比一个 64K 的 IO 速度快 ，因为数据读取的少些。
一个64K 的 IO 会比 8 个 8K 的 IO 速度快 ，因为前者只请求了一个 IO 而后者是 8 个 IO 。
串行IO 会比随机 IO 快 ，因为串行 IO 相对随机 IO 说，即便没有 Cache ，串行 IO 在磁盘处理上也会少些操作。

需要注意， IOPS 与 IO Response Time 有着密切的联系。一般情况下， IOPS 增加，说明 IO 请求多了， IO Response Time 会相应增加。但是会出现 IOPS 一直增加，但是 IO Response Time 变得非常慢，超过 20ms 甚至几十 ms ，这时候的 IOPS 虽然还在提高，但是意义已经不大，因为整个 IO 系统的服务时间已经不可取。

Throughput

为吞吐量。这个指标衡量标识了最大的数据传输量。如上说明，这个值在顺序访问或者大数据量访问的情况下会比较重要 。尤其在大数据量写的时候。

吞吐量不像 IOPS 影响因素很多，吞吐量一般受限于一些比较固定的因素，如：网络带宽、 IO 传输接口的带宽、硬盘接口带宽等。一般他的值就等于上面几个地方中某一个的瓶颈。

一些概念

IO Chunk Size

即单个 IO 操作请求数据的大小。一次 IO 操作是指从发出 IO 请求到返回数据的过程。 IO Chunk Size 与应用或业务逻辑有着很密切的关系。比如像 Oracle 一类数据库，由于其 block size 一般为 8K ，读取、写入时都此为单位，因此， 8K 为这个系统主要的 IO Chunk Size 。 IO Chunk Size

小，考验的是 IO 系统的 IOPS 能力； IO Chunk Size 大，考验的时候 IO 系统的 IO 吞吐量。

Queue Deep

熟悉数据库的人都知道， SQL 是可以批量提交的，这样可以大大提高操作效率。 IO 请求也是一样， IO 请求可以积累一定数据，然后一次提交到存储系统，这样一些相邻的数据块操作可以进行合并，减少物理 IO 数。而且Queue Deep 如其名，就是设置一起提交的 IO 请求数量的。一般 Queue Deep 在 IO 驱动层面上进行配置。

Queue Deep 与 IOPS 有着密切关系。 Queue Deep 主要考虑批量提交 IO 请求，自然只有 IOPS 是瓶颈的时候才会有意义，如果 IO 都是大 IO ，磁盘已经成瓶颈， Queue Deep 意义也就不大了。一般来说， IOPS 的峰值会随着 Queue Deep 的增加而增加 ( 不会非常显著 ) ， Queue Deep 一般小于 256 。

随机访问（随机IO ）、顺序访问（顺序IO ）

随机访问的特点是每次 IO 请求的数据在磁盘上的位置跨度很大 （如：分布在不同的扇区），因此 N个非常小的 IO 请求（如： 1K ），必须以 N 次 IO 请求才能获取到相应的数据。

顺序访问的特点跟随机访问相反，它请求的数据在磁盘的位置是连续的 。当系统发起 N个非常小的 IO 请求（如： 1K ）时，因为一次 IO 是有代价的，系统会取完整的一块数据（如 4K 、 8K ），所以当第一次 IO 完成时，后续 IO 请求的数据可能已经有了。这样可以减少 IO 请求的次数。这也就是所谓的预取。

随机访问和顺序访问同样是有应用决定的。如数据库、小文件的存储的业务，大多是随机 IO 。而视频类业务、大文件存取，则大多为顺序 IO 。

选取合理的观察指标：

以上各指标中，不用的应用场景需要观察不同的指标，因为应用场景不同，有些指标甚至是没有意义的。

随机访问和IOPS : 在随机访问场景下， IOPS 往往会到达瓶颈，而这个时候去观察 Throughput ，则往往远低于理论值。

顺序访问和Throughput ：在顺序访问的场景下， Throughput 往往会达到瓶颈（磁盘限制或者带宽），而这时候去观察 IOPS ，往往很小。