查看原文
其他

存储能力探测方法、工具及存储问题的定位

杨建旭 twt企业IT社区 2022-07-03

一、 存储能力探测

当业务吞吐量不能如预期增加,可以考虑是否是由于存储的瓶颈导致。

业务系统运行起来后,可以提炼其中的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未格式化完成引起短时的性能问题。

本文原题:性能指标之资源指标-磁盘-存储能力探测及存储问题定位

作者专栏:系统性能测试

专栏地址:http://www.aixchina.net/Column/detail/id/9


相关文章:

AIX内存资源问题诊断与规划 五大实用攻略


长按下图二维码关注“AIX专家俱乐部”公众号

也可以直接搜索公众号名称“AIX专家俱乐部”或微信号“AIXChina”关注

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存