注:本文是笔者2012 年 3 月 08 日在(https://www.ibm.com/developerworks/cn/aix/library/1203_weixy_aixio/)发表的作品
磁盘 I/O 的概念
I/O的概念,从字义来理解就是输入输出。操作系统从上层到底层,各个层次之间均存在 I/O。比如,CPU 有 I/O,内存有 I/O, VMM有I/O, 底层磁盘上也有 I/O,这是广义上的 I/O. 通常来讲,一个上层的 I/O 可能会产生针对磁盘的多个 I/O,也就是说,上层的 I/O 是稀疏的,下层的 I/O 是密集的。
磁盘的 I/O,顾名思义就是磁盘的输入输出。输入指的是对磁盘写入数据,输出指的是从磁盘读出数据。
衡量磁盘 I/O 性能的指标
图 1. 物理磁盘的架构以及常见磁盘类型
我们常见的磁盘类型有 ATA、SATA、FC、SCSI、SAS。这几种磁盘中,服务器常用的是 SAS 和 FC 磁盘,一些高端存储也使用 SSD 盘。每一种磁盘的性能是不一样的。
我们在测试工作中,衡量磁盘 I/O 性能主要参考 IOPS 和吞吐量两个参数。下面,将介绍一下这两个参数的含义。
IOPS 与吞吐量的概念
磁盘的 IOPS,也就是在一秒内,磁盘进行多少次 I/O 读写。
磁盘的吞吐量,也就是每秒磁盘 I/O 的流量,即磁盘写入加上读出的数据的大小。
IOPS 与吞吐量的关系
每秒 I/O 吞吐量= IOPS* 平均 I/O SIZE。从公式可以看出: I/O SIZE 越大,IOPS 越高,那么每秒 I/O 的吞吐量就越高。因此,我们会认为 IOPS 和吞吐量的数值越高越好。实际上,对于一个磁盘来讲,这两个参数均有其最大值,而且这两个参数也存在着一定的关系。
下图为各种磁盘的 IOPS 极限值。
表 1. 常见磁盘类型及其 IOPS
注:上表源自维基百科 http://en.wikipedia.org/wiki/IOPS
在 AIX 中,对于同一个磁盘(或者 LUN),随着每次 I/O 读写数据的大小不通,IOPS 的数值也不是固定不变的。例如,每次 I/O 写入或者读出的都是连续的大数据块,此时 IOPS 相对会低一些;在不频繁换道的情况下,每次写入或者读出的数据块小,相对来讲 IOPS 就会高一些。
I/O 读写的类型
大体上讲,I/O 的类型可以分为:读 / 写 I/O、大 / 小块 I/O、连续 / 随机 I/O, 顺序 / 并发 I/O。在这几种类型中,我们主要讨论一下:大 / 小块 I/O、连续 / 随机 I/O, 顺序 / 并发 I/O。
大 / 小块 I/O
这个数值指的是控制器指令中给出的连续读出扇区数目的多少。如果数目较多,如 64,128 等,我们可以认为是大块 I/O;反之,如果很小,比如 4,8,我们就会认为是小块 I/O,实际上,在大块和小块 I/O 之间,没有明确的界限。
连续 / 随机 I/O
连续 I/O 指的是本次 I/O 给出的初始扇区地址和上一次 I/O 的结束扇区地址是完全连续或者相隔不多的。反之,如果相差很大,则算作一次随机 I/O
连续 I/O 比随机 I/O 效率高的原因是:在做连续 I/O 的时候,磁头几乎不用换道,或者换道的时间很短;而对于随机 I/O,如果这个 I/O 很多的话,会导致磁头不停地换道,造成效率的极大降低。
顺序 / 并发 I/O
从概念上讲,并发 I/O 就是指向一块磁盘发出一条 I/O 指令后,不必等待它回应,接着向另外一块磁盘发 I/O 指令。对于具有条带性的 RAID(LUN),对其进行的 I/O 操作是并发的,例如:raid 0+1(1+0),raid5 等。反之则为顺序 I/O。
磁盘 I/O 性能的监控
监控磁盘的 I/O 性能,我们可以使用 AIX 的系统命令,例如:sar -d, iostat, topas, nmon 等。下面,我将以 nmon 和 topas 为例,讲述在系统中如何观察磁盘 I/O 的性能。
topas
登录 AIX 操作系统,输入 topas,然后按 D,会出现如下界面:
在上图中,TPS 即为磁盘的 IOPS,KBPS 即为磁盘每秒的吞吐量。由于服务器处于空闲的状态,我们可以看到 IOPS,KBPS 的数据都非常低。
我们使用 dd if 命令向磁盘 hdisk2 发读 I/O,block 大小为 1MB:
利用 topas 进行监控:
此时,hdisk2 的吞吐量为 163.9M,IOPS 为 655。
我们再启动一个 dd if,使 hdisk 的 busy 数值达到 100%:
从上图可以看出,在磁盘 busy 达到 100% 的时候,其吞吐量为 304.1M,IOPS 为 1200。
hdisk2 是本地集成的 SAS 盘,我们可以查出本地集成 SAS 通道的带宽为 3Gb:
对于 3Gb 的 SAS 通道,304.1M 的磁盘吞吐量已经接近其 I/O 带宽的峰值了。
需 要指出的是,使用 dd if 测量磁盘的带宽是可行的,但是由此来确定业务 I/O 的 IOPS 和吞吐量是不科学的。因为,dd if 所发起的读写仅为顺序 I/O 读写,在 OLTP 的业务中,这种读写是不常见的,而是随机小 I/O 比较多,因此,测量业务的磁盘 I/O 性能,需要在运行业务的时候进行监控。
nmon
在系统中输入 nmon,按 d,可以得到如下界面 :
可以得到此时磁盘 hdisk2 吞吐量为 318M。
使用 nmon 收集一个时间段的数据,然后使用 nmon analyzer 进行分析,可以得出更为直接的图表:
将收集好的 nmon 文件使用 nmon analyzer 进行分析,得出如下报表:
图 2.nmon 图表显示磁盘性能
磁盘 I/O 性能调优
确认磁盘 I/O 存在性能问题
对于随机负载,当遇到余下情况时,我们那通常认为存在 I/O 性能问题:
平均读时间大于 15ms
在具有写 cache 的条件下,平均写时间大于 2.5ms
对于顺序负载,当遇到余下情况时,我们那通常认为存在 I/O 性能问题:
在一个磁盘上有两个连续的 I/O 流
吞吐量不足(即远远小于磁盘 I/O 带宽)
对于一块磁盘来讲,随着 IOPS 数量的增加,I/O service 也会增加,并且会有一个饱和点,即 IOPS 达到某个点以后,IOPS 再增加将会引起 I/O service time 的显著增加。
图 3. 磁盘 IOPS 与 IO service time 关系图
从 经验上讲,我们在测试工作中,我们主要关注 IOPS 和吞吐量以及磁盘的 busy% 这三个数值。如果 IOPS 和吞吐量均很低,磁盘的 busy% 也很低,我们会认为磁盘压力过小,造成吞吐量和 IOPS 过低;只有在 IOPS 和吞吐量均很低,磁盘的 busy% 很高(接近 100%)的时候,我们才会从磁盘 I/O 方面分析 I/O 性能。
通过调整 AIX 参数改善磁盘 I/O 性能
在 AIX 系统中,有关磁盘 I/O 性能相关的参数我们主要调整的参数如下图:
图 4.AIX 常见的磁盘 I/O 性能参数
需要注意的是,下面几个参数的调整值,只是经验数值;对于不同的应用,不同的场景,应具体情况具体分析。
调整I/O 队列长度
queue_depth 是 AIX 一次可以传送到磁盘设备的命令的数量,把命令放在队列中再传送给磁盘可以提高 I/O 性能。AIX 中定义的每个磁盘在 ODM 库中都有 queue_depth 属性。这个属性限制了 AIX 可以传送到设备的最大命令的数量。
queue_depth 默认数值为 4
将 hdisk2 的队列长度从 16 调整为 64:
max_transfer 参数
这个参数的含义是,存储 driver 可以向存储发的最大的 I/O。通过增加 max_transfer 的数值,我们可以允许 VG 的 LTG 的数值更大。
这个参数我们可以从 64M 调整到 128M。
光纤卡num_cmd_elems参数
如果是通过光纤卡连接的外置存储,可以考虑调整 num_cmd_elems,这个参数的作用是:controls maximum number of in-flight Ios
这个参数的默认值为 500,我们将其修改为 1000:
光 纤卡 max_xfer_size 参数 : attribute also controls a DMA memory area used to hold data for transfer, and at the default is 16 MB. 这个参数是控制 DMA 区域的,用于保持传输的数据的的区域,它的默认值是 16MB,可以把这个数值调整成 128MB,这样光纤卡的带宽会高一些 .
FSCSI 设备
对 于 FSCSI 设备而言,我们可以通过设置参数:dyntrk 和 fc_err_recov 来达到路径快速切换的目的:This sets the adapters to fast fail over and reduces the amount of time required to select a new data path.
修改完毕以后,荣如下命令进行确认:
总结
在 AIX 下调整磁盘 I/O 性能是一个相对复杂的工作,参数的数值往往是根据环境的变化而不通。这就要求我们在熟悉磁盘 I/O 性能架构的基础上,灵活调整。
本文分享自微信公众号 - 大魏分享(david-share)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
来源:oschina
链接:https://my.oschina.net/u/4567873/blog/4595926