各种存储性能瓶颈如何分析与优化？

【摘要】本文结合实践剖析存储系统的架构及运行原理，深入分析各种存储性能瓶颈场景，并提出相应的性能优化手段，希望对同行有一定的借鉴和参考价值。

【作者】陈萍春，现就职于保险行业，拥有多年的系统、存储以及数据备份等运维工作经验。

前言

可靠性、安全性和性能是 IT 系统最重要的三个评价维度。对于 IT 系统来说，可靠性和安全性是基础，系统故障或数据泄露等造成的破坏性是显而易见的；而性能则是核心能力，代表着 IT 系统的服务水平，性能瓶颈会制约企业业务的发展，严重影响用户体验。

存储系统是企业 IT 基础架构重要的组成部分，为企业内部众多的 IT 系统提供数据存储服务。随着数字化转型的深入，企业的 IT 系统建设也进一步加快，这一方面带来了数据量的急剧增长，另一方面也提高了数据的访问频率，存储的性能瓶颈的影响也会被进一步放大。本文将结合个人运维实践，剖析存储系统的架构及运行原理，深入分析各种存储性能瓶颈场景，并提出相应的性能优化手段，希望对同行有一定的借鉴和参考价值。

1. 存储系统概述

了解存储系统的架构及其运行原理是性能分析与优化的入门课，才能去全局分析解决存储性能问题。经过多年的技术演进和架构变化，存储系统可大致分为 SAN 存储、 NAS 存储以及分布式存储这三类，它们有类似之处，又各有特点。下文将分别详细剖析这三类存储架构及其运行原理。

1.1 SAN 存储

SAN （ Storage Area Network ）本身是一个承担数据存储任务的存储网络，与业务 LAN 网相互隔离。SAN 存储则是一种基于存储块的存储系统，一般使用 FC 、 ISCSI 、 NVMe 等通信协议。

架构层面看， SAN 存储一般是存储控制器后端挂载磁盘阵列，数据最终储存在磁盘阵列，而磁盘阵列则包括了多个 RAID 组。N 个磁盘组成一个 RAID 组，在 RAID 组之上又会被划分出逻辑存储单元 LUN ，也就是共享存储池的逻辑磁盘，这些 LUN 会通过 SAN 网络与服务器的 HBA 卡相连，从而会被服务器的操作系统识别为磁盘，并被分区和格式化后使用，其架构如图 1 所示。

图 1.SAN 存储架构图

从存储的数据 IO 流角度来看，以常用的 FC-SAN 存储为例，服务器操作系统一般会使用文件系统管理文件，文件系统是建立在存储 LUN 之上，文件的读写会对应着存储的 IO 操作；文件会被分为多个 Block ， Block 大小固定，一般是 4KB-16KB ；数据 Block 块会被发送到服务器的 HBA 卡， HBA 卡再将其转换为 FC 协议的数据帧（ Data frame ），并通过 SAN 网络传输到存储系统的前端口；存储的前端口继续将这些数据帧重新封装成数据 Block ， Block 大小一般为 4KB ，并将这些数据 Block 块传输到存储控制器中；存储控制器中会有存储缓存（ Cache ），分为读缓存与写缓存，根据缓存的算法规则，部分缓存命中的 IO 数据流会立刻返回 IO 确认，缓存未命中的 IO 数据流则会需要继续访问磁盘阵列；由于多个磁盘组成了 RAID 组，一个数据 IO 流实际上对应着多个磁盘的并发读写。整个过程如图 2 所示：

图 2.FC-SAN 存储的数据 IO 流图

1.2 NAS 存储

NAS （ Network Attached Storage ）存储一般也可认为是网络文件存储，用户数据大多数以文件形式存在，通过以太网访问模式走 NFS/CIFS 协议，提供了广泛兼容性易用性的共享能力。相比于 SAN 存储， NAS 存储不以磁盘形式提供存储服务，不需要分区和格式化，可以直接提供可以直接挂载的网络文件系统。

架构层面看， NAS 存储一般也是基于磁盘阵列（也有基于集群文件系统或分布式存储的实现方式）实现的，在磁盘阵列之上会有 NAS 机头来创建和管理文件系统；NAS 机头是 NAS 存储的核心逻辑部件，是典型的 C/S 架构风格，是对外提供网络文件服务的 Server 端；其他 client 端在获得授权后，可通过挂载文件系统、映射网络磁盘或 HTTP 、 FTP 等方式就可以共享访问 NAS 文件系统上的文件，其架构如图 3 所示：

图 3.NAS 存储架构图

从存储的数据 IO 流角度来看，以 NFS 为例， NAS 存储是有着明显异于 SAN 存储的特点，比如客户端缓存、 Server 的无状态性等。首先客户端并不是直接访问 NAS 文件系统，而是客户端缓存，是服务端的文件系统目录树映射到了客户端，实际在文件读写时，需要循环读写固定大小的页面，比如 64KB ；而 Server 端的无状态性体现在不需要维护客户端的协议状态信息，客户端通过 RPC 调用操作 Server 端的文件系统数据，但也不能获取 Server 端的状态，当连接中断时，可以不停地连接重试。如图 4 所示，基于 TCP 的应用层协议的 NAS 存储数据 IO 流会更加灵活，适配性较强，但数据 IO 路径更长，数据一致性较差，还会存在数据泄露等安全问题，数据传输效率也不高。

图 4.nfs 协议下的 NAS 存储数据 IO 流图

1.3 分布式存储

分布式存储系统是采用可扩展的集群架构，通过数据副本算法将数据分散存储在多台独立的设备上，分布式集群之间一般通过通用 TCP/IP 网络连接。相比于其传统的集中式存储阵列，分布式存储系统可以通过多台存储服务器来分担存储负荷，可以满足大规模存储应用的需要。常见的分布式存储系统的形式包括分布式文件系统（如 HDFS ）和对象存储（如 Ceph ）。

从架构层面来看，与集中式存储系统相比，分布式存储系统的部署架构相对简单，一般是通用服务器网络互联的方式，但其逻辑架构更加复杂。分布式存储系统的核心设计思想是去中心化， 去中心化的难点主要在于是主控节点的去中心化，有主控节点的架构比如 HDFS 的架构设计思路是 map-reduce ，化大为小，分而治之，再合并处理，其架构中需要主控节点来协调，只是主控节点的负载都分发到了数据节点，数据节点上则存放着数据副本，每个数据副本又都分布在三个不同的数据节点上，如图 5 所示；而无中心化的最大优点是解决了主节点本身的瓶颈，其架构设计思路则是均衡设计，这种架构只有数据节点，但是需要抽象出更多的逻辑功能组件，并均衡分布在不同节点上。以 Ceph 块存储的使用方式为例，除了 Mon 等集群管理监控组件之外， Ceph 中 OSD 组件用于管理物理磁盘，基于 OSD 去构建 PG ，而 PG 上存放着数据对象，数据对象则对应着 Ceph 块设备， Ceph 块设备可被格式化分区，从而被应用使用，其架构图如图 6 所示。

图 5. 有主控节点的分布式存储架构

图 6. 无主控节点的 Ceph 存储架构

        从存储的 IO 数据流来看，不同于集中式存储较少的数据通道，分布式存储的数据入口可以更多更宽，但集群内部的数据流也更多。还是以 Ceph 的块存储为例，客户端应用访问的文件系统对应的是 Ceph 块设备， Block 数据通过网络访问 Ceph 集群 RBD 服务，最终对应于三副本 OSD 的磁盘读写，流程如图 7 所示。对于三副本的分布式存储系统，为保障数据的强一致性，一个写 IO ，一般需要主副本和另外两个从副本都写完后，才能最终确认写完成。

图 7.Ceph 存储 IO 数据流图

2. 存储性能分析

存储性能分析是性能优化的基础，虽然存在多种类型多种设计方案的存储系统，但性能分析方法却具有一定的通用性。存储性能分析方法可分为定性与定量两种方式，通常在接触了解、技术选型的初期可能并不具备定量分析的条件，则主要采用定性分析方法来评估存储系统的性能；而一旦进入 POC 测试、系统运维等阶段，则应以定量分析为主，通过实际的性能指标数据来判断存储性能瓶颈。

2.1 定性分析

定性分析是结合个人的运维经验，来分析存储系统的性能是否能满足应用系统的需求，来分析存储系统是否存在性能瓶颈，而这些都取决于对应用数据类型和存储系统的熟悉程度。

2.1.1 应用数据 IO 分析

了解应用数据 IO 的类型，是存储性能分析的基础。不同应用数据 IO 访问存在着差异，主要体现在 IO 大小、顺序或随机读写、读写比例等方面，如表 1 所示。

应用类型	IO大小	读写比例	随机或顺序读写
一般文件	小	大比例读	主要随机读写
日志文件	小	大比例写	顺序读写
视频流	大	大比例读	主要顺序读写
操作系统	小	大比例读	多数是顺序读写
数据备份	大	大比例写	顺序读写
OLTP数据库	小	约70%读/30%写	主要随机读写
OLAP数据库	大	大比例读	主要顺序读写

表 1. 应用程序的数据 IO 类型

IO 大小

应用数据类型的差异会带来不同大小的数据文件，也对应着不同的数据 IO 大小。假设存储系统 IO 处理能力是固定的，显然单位时间内大 IO 处理的数据更多，那么合并小 IO 会更有效率；而假设存储系统每次处理数据 IO 大小有上限，那么每次处理大 IO 前都需要拆分，显然 IO 处理效率会下降。比如 SAN 存储具有很高的 IO 处理能力，但单次处理的 IO 偏小，那么更适宜性能要求高的、小 IO 应用系统，而处理大 IO 应用数据时，效率反而会下降。

读写比例

读写比例是应用数据的重要特征之一， IO 读和写操作存在着较大的差异。一般来说写操作对于存储性能的消耗更大，写 IO 处理能力、延时都较高，对缓存的需求差异也较大。对于分布式存储来说，多副本机制可以优化读操作，但却不利于写操作，写确认路径较长，需要优化数据传输路径、配置更多的写缓存，更适宜于读比例较高的应用系统。

顺序或随机读写

顺序或随机读写的差异主要表现在磁盘介质特性、预读取机制、缓存命中率等方面。对于机械硬盘来说，顺序读写的 IO 可以减少磁盘寻道时间，随机读写的 IO 则响应时间变长，可以通过提高缓存命中率的方式，将缓存中的数据转化为顺序读写到磁盘；而 SSD 硬盘则不存在机械寻道，随机读写能力会大大优于机械硬盘。

2.1.2 性能瓶颈分析

存储性能分析的关键是对性能瓶颈进行分析，包括两方面的内容：一是触发性能瓶颈的因素；二是性能瓶颈的定位，找出存储 IO 拥塞的位置。

1)触发性能瓶颈的因素

存储热点：存储热点是规划设计中的缺陷，典型场景包括数据 IO 负载过于集中在某个存储节点、端口、磁盘等，存储资源争用、锁竞争，软硬件参数的限制等。

性能尖峰：常见于数据 IO 高并发、性能需求短时间集中释放的场景，性能尖峰更会充分暴露出存在的热点问题，从而触发存储性能瓶颈，典型场景包括虚拟桌面启动风暴、秒杀类业务等。

服务能力下降：常见于故障场景，存储服务能力下降叠加数据 IO 繁忙阶段，会导致触发存储性能瓶颈。典型的故障场景包括 SAN 存储单存储控制器故障、磁盘 rebuild 等；分布式存储更容易出现性能抖动，主要也是由于某个节点或磁盘掉线或重建数据副本或某个数据副本响应变慢；客户端服务器的 CPU 、内存资源不足等。

2)性能瓶颈的定位

存储性能瓶颈的定位需要结合存储系统的架构来分析，按照存储系统的构成大致可分为以下几类性能瓶颈位置：

数据传输网络：存储外接和内接数据传输网络的带宽、端口速率、传输协议、传输路径的负载均衡度

存储控制器：控制器的 CPU 处理能力

缓存：主要分为客户端缓存和存储缓存，包括缓存大小、缓存命中率、读写缓存的分配比例

磁盘：主要分为机械硬盘、闪存盘等磁盘介质，包括磁盘转速、单盘读写的 IOPS 、磁盘容量大小、磁盘数量、磁盘冗余（ RAID 、副本或纠删码）算法

客户端：体现在客户端的 CPU 、内存等资源的使用情况、其他应用对存储资源的占用等外部环境的影响

2.2 定量分析

定量分析是从数据指标角度来分析解决问题，既可以从存储侧来度量存储系统的服务能力，也可以从用户应用侧来衡量存储 IO 体验。一般来说，存储侧的定量分析排除了存储网络和客户端的影响，性能数据能说明存储系统本身是否存在性能瓶颈，可用于存储系统的性能监控；而用户应用侧的定量分析主要用于一些性能测试场景，通过基准测试工具，可以形成当前系统环境的性能基线。

2.2.1 三大性能指标

无论是存储侧还是用户应用侧的定量分析，都离不开三大存储性能数据指标：IOPS 、吞吐量（ Throughput ）、延时（ Latency ）。因此有必要弄清楚三个性能数据指标的含义及其关联关系。

IOPS ：代表存储每秒所处理的 IO 操作数量。对于存储系统来说，我们在性能分析时，既需要关注整体的 IOPS ，有时也需要分析单个控制器、单个 LUN 或者单个磁盘的 IOPS ，甚至可能还需要区分读或者写的 IOPS 。

吞吐量（ Throughput ）：代表存储每秒所处理的 IO 数据量大小，也就是存储数据传输所占用的带宽，与 IOPS 类似，也可以细分读或者写，可以单独组件分析。

延时（ Latency ）：代表存储系统处理 IO 操作所需要的时间，通常情况下，是最重要的存储性能指标，与 IOPS 类似，也可以细分读或者写，可以单独组件分析。

三大性能指标分析中，对于 大 IO 的应用使用吞吐量来评测性能更加科学；而小 IO 的应用，比如数据库，则需要通过 IOPS 和延时的指标来评测性能，高 IOPS 和低延时同时满足的情况下，才能应对高并发且快速的数据库访问。

2.2.2 性能测试分析

存储性能测试可以更好地理解存储的性能指标，以某个存储性能测试为例，存储压测工具 vdbench （可针对裸盘与文件两种访问方式的压测），测试背景是存储上分配了 5 个 lun 给主机，主机对这五块裸盘做随机读写测试， 80% 读 20 写，逐渐调整 IO 的大小进行测试，三大性能数据指标如下表：

IO大小	IOPS	吞吐量（MB/s）	延时（ms）
4KB	89288	348.78	0.411
16KB	75209	1175.15	0.488
32KB	59415	1856.72	0.617
64KB	36612	2288.30	1.005
128KB	20686	2585.82	1.833

表 2. 存储性能测试数据

该存储性能测试的结论如下：

1) 该存储的控制器 CPU 使用率峰值在 20%-45% ，说明该存储控制器还可以承受更高的 IO 负载，如图 8 所示。

图 8. 存储控制器 CPU 使用率

2) 该测试也未达到主机的系统性能瓶颈， CPU 使用了低于 20% ，这一点在存储性能分析中也很重要。

图 9. 主机系统的 CPU 使用率

3) 存储性能基线 ：表 2 中的测试数据就是特定的主机使用该存储的 5 个 lun 在不同 IO 负载下的性能基线数据，在实际运行过程中，考虑到其他应用的 IO 、读写 IO 大小不均等因素，一般 IOPS 峰值在基线值的 50% 。

4) 吞吐量和 IOPS：吞吐量 =IOPS*IO 大小，相同的业务场景，一般 IO 大小不会有明显变化，那么极限测试下的吞吐量与 IOPS 会呈正比关系，但吞吐量受限于网络带宽， IOPS 又受限于存储 lun 的处理能力；

5) 延时和 IOPS：可以看出测试数据中延时和 IOPS 呈现出反比关系，即 IOPS 越低，延时反而越高，这是由于不同的 IO 大小的测试场景下，存储的负载压力不一样，即大 IO 的情况下，存储负载变大， IOPS 下降，延时加大。而存储系统正常运行状态下的 IOPS 和延时关系如图 10 所示，大多数情况下存储的负载压力变大， IOPS 增加，延时也开始变大，一旦 延时过高就会影响业务系统的性能。所以大多数情况下，延时是最重要的存储性能指标，一般性能要求较高的业务系统，存储的延时需要低于 5ms 。

图 10. 正常运行状态下的存储 IOPS 和延时

3. 存储性能优化

存储性能分析与优化是一项长期、复杂而重要的工作，需要明晰存储性能优化目标，做好详细性能分析，并制定阶段性的优化方案和验证方案，以确保存储性能优化工作的持续开展。

3.1 优化策略

存储性能优化工作具有一定的策略性，科学的优化策略才能指导制定更加合理的存储性能优化方案。

1) 通盘考虑：存储性能问题是一个全局性问题，需要通盘考虑 IO 路径上的性能瓶颈，分析性能优化方案中可能出现的连锁反应，以提高性能优化决策的正确性。

2) 优化的性价比：制定合理的性能优化目标，在多种性能优化方案的选择上，要综合考虑方案成本、实施复杂性、收益等。

3) 规划更重要：相比于存储性能优化带来的优化改造成本，提前做好合理的规划更为重要。比如兼顾业务性能需求的存储选型，系统上线前的存储性能测试的基线数据及性能容量管理，存储扩容要关注 性能容量指标（评估扩容后，存储的 IOPS/GB 是否有较大变化），以及存储性能负载的均衡分布等。

4) 完善性能监控：端到端的存储性能也是非常重要的，对整个数据 IO 路径进行监控，基于存储性能基线来分析实际运行中的性能数据，从而及时发现存储性能瓶颈，也能验证存储优化的成果。

3.2 优化方案

存储性能优化方案可以大致分为以下几类：

1) 硬件升级

单块机械硬盘的 IOPS 在 100 左右，延时在 5ms 以上，而单块 SSD 的 IOPS 在 1 万以上，延时小于 1ms ，传统机械硬盘替换为全闪存存储，性能可以得到极大的提升；NVMe 、 RDMA 等技术的应用，优化了底层通信框架，可以极大提高数据传输效率，降低存储延时；存储控制节点的横向或纵向扩展，可以有效增加存储负载能力；客户端的硬件升级，也能消除客户端的 CPU 、内存、网络等带来的性能瓶颈。

硬件升级是一种非常有效的存储性能优化手段，但是很多情况下需要比较高的硬件成本，投入产出比还需要仔细评估。

2) 上层应用优化

上层应用优化手段也比较丰富，主要目标是减少上层应用带给存储的 IO 负载，比如数据传输前启用重复数据删除或数据压缩；优化 IO 并发，将大量的小 IO 聚合成大 IO ；数据库的索引优化、 SQL 语句优化。

3) 调整性能负载

调整性能负载主要针对的存储性能热点问题，方案包括优化磁盘分布方式，调整磁盘负载；调整存储网络端口负载；调整存储控制器负载；新增存储，将部分负载调整到新的存储上。

4) 数据缓存优化

数据缓存是存储系统中非常重要的性能模块，一般缓存都采用内存或闪存等速度更快的存储介质，远远快于一般的磁盘。很多存储性能问题都因缓存而起，也经缓存优化而终结。数据缓存分为客户端本地缓存和存储缓存。比如客户端本地缓存对于一些分布式文件系统非常重要，增加缓存大小，可以有效提高缓存命中率；存储的缓存也极为重要，多层级的数据缓存技术可将热点数据存放在更快的存储介质上，降低存储延时。