技术社群的这篇文章《存储 IO 性能优化策略、方案与瓶颈分析（15张图干货）》通过这15张图讲解了存储IO性能的优化策略、方案和瓶颈分析，值得我们学习和借鉴，应用到实际工作。
一、不同应用数据的 IO 模型特点
首先我们来了解一下不同的应用程序类型的典型IO模型特点，让大家有个大体印象以便于下文章节的展开。
下表总结描述了不同的应用程序对应的IO大小、读写比例、随机和顺序比例情况，表中的比例为一个通用参考值。不能包含全部的应用类型，同时根据不同生产环境数值也会有很大的差异。这里表1的数据仅提供一个通用的参考。
表1 应用数据的IO模型
二、存储 IO 性能指标和计算公式
1. 三大存储IO性能指标：
三大性能指标分析中，对于大IO的应用使用吞吐量来评测性能更加科学；而小IO的应用，比如数据库，则需要通过IOPS和延时的指标来评测性能，高IOPS和低延时同时满足的情况下，才能应对高并发且快速的数据库访问，如表2。
表2 三大存储IO性能指标
2. 其它重要的存储性能指标（表3）：
表3 其它重要的存储性能指标
3. 各IO性能指标的计算和相互转换公式
･ IOPS、IO size、带宽、QueueDepth之间的计算转换公式（如图1）：
图1 IOPS、IO size、带宽、QueueDepth之间的计算转换公式
4. 各性能指标在vdbench基准测试工具中的体现（如图2）
图2 各性能指标在vdbench基准测试工具中的体现
三、存储 IO 性能优化
1. 优化策略
存储IO性能优化工作需要一定的策略性（如表4）：
表4 存储IO性能优化策略
2. 优化方案
存储设备层优化方案（如图3）：
图3 存储设备层优化方案
网络层优化方案（图4）：
图4 网络层优化方案
存储传输协议方案选择（如图5）：
图5 存储传输协议方案选择
主机层优化方案（如图6）：
图6 主机层优化方案
应用层优化方案（如图7）：
图7 应用层优化方案
3. 传统关系型数据库的IO性能的瓶颈点分析（如图8）
图8 Oracle 数据文件和日志文件读写过程
如表5所示，OLTP系统中，单进程的LGWR进程有可能成为一个大瓶颈，特别是在无法保证在线日志IO写性能的情况下，很容易出现排队等LGWR进程的情况。这其实也是很容易引发问题的一个点，是传统关系性数据库一个相对脆弱的地方。
表5 关系型数据库data和log数据IO读写模型
OLTP数据库存储性能优化思路（如图9）：
图9 OLTP数据库存储性能优化思路
4. IO并发队列的考虑
队列深度（Queue-Depths）是指主机端单个LUN可以一次被允许并行的处理的I/O数目(SCSI命令)。例如QD=32,代表可以在同一个时刻并行对该LUN做32个IO操作。
在SCSI命令层面，每个从发送端（initiator）主机HBA卡端口发送到接收端(target)存储HBA卡端口的IO request都会消耗一个Queue条目。
一般来说，更高的队列深度相当于更好的性能。如果存储控制器/节点到达最大队列深度并耗尽，存储控制器将拒绝新的传入命令并通过返回QFULL回应主机从而引起性能的降低。如果大量的主机访问存储控制器,应该仔细计划,以避免QFULL条件显著降低系统性能和在某些系统会导致错误。
有关队列深度（Queue-Depths）计算的深入分析（表6）：
表6 队列深度计算的深入分析
有关队列深度（Queue-Depths）注意事项：
队列深度的存在，在流水线上的每个不同环节设置缓冲空间(Buffer)，使正常流水线数据传送从紧耦合变成了松耦合。简单来讲从主机访问存储存在很多层的Queue（软硬件在传输过程中设计的Buffer大小，将串行流水线操作模拟成并行操作的一种并发交易模拟机制）。在IO处理没有卡顿时，有Queue 和没有Queue 的效果是一样的。使用Queue-Depths 传送机制的系统中，整个系统的吞吐量和延迟由性能最差的那个部位决定。
如果您认为这篇文章有些帮助，还请不吝点下文章末尾的"点赞"
