一、 存储能力探测
当业务吞吐量不能如预期增加，可以考虑是否是由于存储的瓶颈导致。
业务系统运行起来后，可以提炼其中的IO模型，按照IO模型，有针对性的进行存储方面的规划和测试。有不少工具可以用来探测LPAR所用的存储的最大能力，本文以Orion工具为例介绍。
1.1 IO模型
IO模型包括：
- 磁盘IO分别在哪些盘
- IOPS
- 带宽
- 读IO和写IO的比例
- 读IO是顺序的还是随机的
- 写IO是顺序的还是随机的
- 读IO的大小
- 写IO的大小
数据收集来源除了上述介绍的IOPS、带宽指标，还需要关注IO的大小。IO的大小可以通过带宽/IOPS来计算，但更细致的数据可以通过NMON中DISKAVGRIO/DISKAVGWIO来读取，毕竟带宽/IOPS计算得出的IO Size是某个时间段的平均值，而真实场景中每一秒的情况可能与平均值相差甚远。
1.2 存储能力探测工具-Orion
Orion工具是由Oracle开发，用于探测Oracle数据库所在的存储在不同IO模型下的最大IO能力，预测Oracle的最大读写能力。Orion可模拟Oracle数据库IO负载（采用与Oracle相同的IO软件栈），可模拟Oracle Automatic Storage Management提供的条带效果。
本测试中针对某一文件进行100%的写操作，写操作的类型为顺序写，每个写IO大小为8K。
Orion按照上述指定参数施压，自动地、逐渐地增加并发写的进程数，直到Orion认为吞吐量不再增加。测试结束后，从trace文件中提取有用信息，如下图：
Orion还可以不进行参数设置，自动对存储的IOPS、带宽的最大能力进行探测，是一款不错的小工具。
二、 存储问题定位
从用户的角度来说，性能问题最直观的感受是应用响应时间或者业务处理时间变长，性能问题是系统性的，问题可能出现在各个环节。通常情况下，最先排查的是CPU、内存等服务器内在的原因，当服务器内在原因被初步排除后，才会排查网络IO、磁盘IO的问题。
即使确定是磁盘IO导致的，也要分析整个IO路径，分析IO瓶颈是主机/网络/存储中的哪个环节导致的。
2.1 主机侧
当主机侧观察到的时延很大，存储侧的时延较小，则可能是主机侧或网络存在问题。
主机是I/O的发起端，I/O特性首先由主机的业务软件和操作系统软件和硬件配置等决定。例如，在“服务队列满”这一章节介绍的I/O 队列长度参数（queue_depth），当然，还有许多其他的参数（如： driver 可以向存储发的最大的 I/O、光纤卡DMA memor区域大小、块设备并发数、HBA卡并发数）。
若排查完成，性能问题还是存在，则需要对组网及链路、存储侧进行性能问题排查。
2.2 交换网络
当主机侧观察到的时延很大，存储侧的时延较小，且排查主机侧无问题时，则性能问题可能出现在链路上。
可能的问题有：带宽达到瓶颈、交换机配置不当、交换机故障、多路径选路错误、线路的电磁干扰、光纤线有损、接口松动等。带宽达到瓶颈、交换机配置不当、多路径选路错误、线路的电磁干扰等。
2.3 存储侧
如果主机侧时延与存储侧时延都很大且相差较小，说明问题可能出现在存储上。首先需要了解当前存储侧所承载的IO模型、存储资源配置，并从存储侧收集性能数据，按照I/O路径进行性能问题的定位。
常见原因如硬盘性能达到上限、镜像带宽达到上限、存储规划（如条带过小）、硬盘域和存储池划分（例如划分了低速的磁盘）、LUN对应的存储缓存设置过小、IO的Qos限制的磁盘IO的带宽、存储接口模块数量过小、RAID划分（比如RAID10>RAID5>RAID6）、配置快照、克隆、远程复制等增值功能拖慢了性能、存储控制器的CPU利用率过高、LUN未格式化完成引起短时的性能问题。
