业务服务器的操作系统作为存储的用户只能看到disk(存储层面的LUN)，而存储管理员才知道存储内部的具体RAID方式、条带化方式等等，在关注系统性能的活动(性能测试、性能调优)中，一般很少直接关注磁盘IO的指标，而是遇到性能问题(比如业务的响应时间非常慢)，并且逐步排查到磁盘时，才重点关注磁盘IO的性能指标。这是因为，磁盘IO的性能的确是不好拿一个指标说清楚的事。
当磁盘IO有性能问题，需要分析IOPS、MBPS、服务时间、平均每次写入的block大小、队列等待时间等指标，分析IO路径、驱动、光纤卡、光纤交换机、后台存储的规划、硬盘域和存储池划分、thin LUN还是thick LUN、存储的缓存设置、IO的Qos、磁盘类型、存储接口模块数量、RAID划分、是否配置快照、克隆、远程复制等增值功能、存储控制器的CPU利用率，甚至数据在盘片的中心还是边缘等等。
本节并不主要从存储的角度介绍，而是从存储的用户(业务服务器的操作系统)的角度介绍磁盘IO的性能指标，以及相关分析。
主要关注指标
虽然每类物理资源都有N个性能指标来体现，但CPU、内存资源最主要的指标只有一个，即利用率，但磁盘IO的主要指标却有三个(IOPS、带宽、响应时间)。这是因为存储的能力会根据IO模型的不同而差异较大，IO模型可以理解为读IO和写IO的比例、顺序的还是随机的、每个IO的大小等等。例如：当测试IOPS***能力的时候，采用随机小IO进行测试，此时占用的带宽是非常低的，响应时间也会比顺序的IO要长很多。而测试顺序大IO时，此时带宽占用非常高，但IOPS却很低。
从业务服务器、存储控制器、前端主机端口、磁盘、LUN、存储池等角度，都有以下三个主要指标，本文重点从业务服务器角度介绍。
IOPS
I/O per second，即每秒钟可以处理的I/O个数，用来衡量存储系统的I/O处理能力。在数据库OLTP(Online Transaction Processing)业务场景，通常以IOPS衡量系统的性能。测量存储的***IOPS往往是以随机读写小IO来评估。
1. 获取来源
总IOPS：Nmon DISK_SUMM Sheet：IO/Sec
每个盘对应的读IOPS ：Nmon DISKRIO Sheet
每个盘对应的写IOPS ：Nmon DISKWIO Sheet
总IOPS：命令行iostat -Dl：tps
每个盘对应的读IOPS ：命令行iostat -Dl：rps
每个盘对应的写IOPS ：命令行iostat -Dl：wps
2. 适用场景
对于I/O小于64KB的应用场景，存储性能主要关注IOPS指标。
OLTP(联机事务处理)系统是大量用户在线进行事务操作的数据库业务的一种应用类型。
OLTP应用的负载特征如下：
从数据库角度看：
– 每个事务的读、写、更改涉及的数据量非常小。
– 数据库的数据必须是***的，所以对数据库的可用性要求很高。
– 同时有很多用户访问。
– 要求数据库快速响应，通常一个事务需要在几秒内完成。
从存储角度看：
– 每个I/O非常小，通常为2KB～8KB。
– 访问硬盘数据的位置非常随机。
– 至少30%的数据是随机写操作。
– REDO日志(重做日志文件)写入非常频繁
带宽
每秒钟可以处理的数据量，常以KB/S或MB/s或GB/s为单位，表示为KBPS/MBPS/GBPS，用于衡量存储系统的吞吐量。在数据库OLAP(Online Analytical Processing)业务、媒资业务、视频监控业务等应用场景，通常以带宽衡量系统性能。
1. 获取来源
总带宽：Nmon DISK_SUMM Sheet：Disk Read KB/s，Disk Write KB/s
每个盘对应的读带宽：Nmon DISKREAD Sheet
每个盘对应的写带宽：Nmon DISKWRITE Sheet
总带宽：命令行iostat -Dl：bps
每个盘对应的读带宽：命令行iostat -Dl：bread
每个盘对应的写带宽：命令行iostat -Dl：bwrtn
2. 适用场景
对于I/O大于等于64KB的应用场景，存储性能主要关注带宽指标。
OLAP业务是用户长时间在线对数据库执行复杂的统计查询操作的一种应用类型。
OLAP应用的负载特征如下：
从数据库管理员角度看：
– 数据修改量小或无数据修改。
– 数据查询过程复杂。
– 数据的使用频率逐渐减小。
– 查询结果以统计值呈现，方便查看。
从存储采样看：
– 单个I/O数据量大，通常为64KB～1MB。
– 读取操作通常顺序读取。
– 当进行读取操作进行时，写操作的数据存放在临时表空间内。
– 对在线日志写入少。只有在批量加载数据时，写入操作增多。
响应时间
也称为时延或者服务时间，发起I/O请求到I/O处理完成的时间间隔，常以毫秒(ms)为单位。
1. 获取来源
每个盘对应的读响应时间：命令行iostat -Dl：read - avg serv，max serv
每个盘对应的写响应时间：命令行iostat -Dl：write - avg serv，max serv
2. ***实践
数据库OLTP业务一般时延要求10ms以下，事实上大多数情况下不足1ms;VDI(Virtual Desktop Infrastructure)场景一般时延要求30ms以下;视频点播和视频监控的时延要求随码率的不同而不同。
从业务系统用户的角度，响应时间是这三个指标中最重要的指标。因为，如果IOPS或带宽达到了存储的瓶颈，那么一定会体现在IO响应时间上。
其他关注指标
用户从业务系统经常关注的其他指标有：磁盘繁忙程度、队列满等等，这里简单介绍一下。
磁盘繁忙程度
Diskbusy体现了磁盘驱动的利用率，即磁盘驱动有百分之多少时间是活动的。
1. 获取来源
Nmon DISKBUSY Sheet
命令行iostat -Dl：% tm_act
2. 详细解释
但这个指标的高低与IOPS、带宽并不是线性关系。例如当diskbusy=80%的时候IOPS=500，当diskbusy=90%的时候IOPS可能可以达到800。
可以把驱动理解为道路，每个IO的数据块理解为道路上行使的汽车。当道路上没有车的时候，认为是不活动的;当道路上有车的时候，认为是活动的，但有1辆车也是活动，有10辆车也是活动。因此diskbusy并不能作为磁盘IO的重要性能指标。但在日常情况下，可以从这个值的高低对磁盘使用情况有个大概的判断。
服务队列满
服务队列每秒变满(磁盘不再接受服务请求)的次数。
1. 获取来源
命令行iostat -Dl：sqfull
2. 详细解释
通常情况下这个sqfull的值为0，如果经常不为0，可能是IO队列深度太小或者磁盘/存储能力不足。
queue_depth 是IO队列深度，即AIX 一次可以传送到磁盘设备的命令的数量，把命令放在队列中再传送给磁盘可以提高 I/O 性能。这个属性限制了 AIX 可以传送到设备的***命令的数量。可以通过命令查看lsattr -El hdiskxxx|grep queue_depth，queue_depth 默认数值为 4，可以调整。但调整queue_depth这种方法对于提高磁盘IO能力来说很有限。
文件系统使用率
文件系统和inode的利用率其实已经不在磁盘IO的讨论范围，但仍然属于磁盘的范围，需要业务系统用户关注。
1. 获取来源
NMON：JFSFILE SHEET
命令行df- g
2. ***实践
当使用率超过80%的时候，系统的性能可能会被拖慢。
同时，统计业务量与文件系统利用率的增长情况，可以推测该文件系统可以支撑的***业务量，管理员可以根据日常业务量和文件系统的空间，设定备份删除策略。
Inode使用率
Inode：索引节点，它用来存放文件及目录的基本信息，inode数量即文件系统的节点的***数量。
Inode使用率容易被忽略。对于一些文件大小很小，文件数量却很大的系统，若采用默认参数生成文件系统，可能导致inode数量不足。当inode使用率达到100%后就不能再创建新的文件或目录。
1. 获取来源
NMON：JFSINODE SHEET
命令行df- g：%Iused
