3. 性能指标与容量术语体系
在 Pure Storage 全闪存阵列的性能优化与容量规划中，最容易出错的地方往往不是工具不会用，而是术语理解不一致。例如有人把“IOPS 高”直接等同于“性能好”，却忽略了时延已经恶化；有人看到阵列显示 5:1 数据缩减比，就认为 10TB 物理容量可以承载 50TB 业务数据，却忽略了精简配置、快照和克隆带来的额外空间开销。本节把这些术语放在同一张“性能—容量”坐标系里讲清楚，并给出可实际使用的判断方法。
一、性能侧：IOPS、时延、带宽与队列深度
IOPS（Input/Output Operations Per Second）表示每秒完成的 I/O 次数，它衡量的是“处理请求的数量能力”。在 Pure Storage 阵列中，IOPS 通常按读、写分别统计，因为写操作涉及 NVRAM 写入、元数据处理和后续刷盘，成本与读不同。需要注意的是，IOPS 必须和块大小绑定才有意义：4KB 随机读的 10 万 IOPS 与 256KB 顺序写的 10 万 IOPS，对后端压力完全不同。
时延（Latency）表示一个 I/O 从发出到完成所经历的时间，通常以毫秒（ms）或微秒（µs）计。时延是用户体验最直接的指标。Pure Storage 官方常以“亚毫秒级”描述其全闪存阵列的稳定时延，但在实际环境中，时延会随负载上升而抬升。判断时延是否健康，不能只看平均值，还要看 P99 或 P95 分位值，因为少量慢 I/O 会显著拖累数据库和虚拟化平台。
带宽（Throughput/Bandwidth）表示单位时间内传输的数据量，常用 MB/s 或 GB/s。带宽 = IOPS × 平均 I/O 大小（近似）。因此大块顺序业务（如备份、媒体处理）看带宽，小块随机业务（如 OLTP 数据库）看 IOPS 和时延。
队列深度（Queue Depth）表示主机或阵列在任一时刻允许“在途”的未完成 I/O 数量。队列深度是连接 IOPS 与时延的桥梁：在时延稳定的区间内，增加队列深度可以提升 IOPS；但一旦超过阵列或卷的承载能力，队列深度继续增加只会让时延快速上升，而 IOPS 不再增长。这就是著名的“时延—吞吐拐点”。
下面这张图把四个性能指标放在同一条信号链上，展示它们之间的因果关系：主机发起 I/O 形成队列深度，阵列处理产生 IOPS，每个 I/O 的完成时间构成时延，而 IOPS 与 I/O 大小的乘积决定带宽。
二、容量侧：数据缩减比、有效容量与精简配置
数据缩减比（Data Reduction Ratio）是 Pure Storage 阵列的核心容量指标，通常由三部分叠加而成：去重（Deduplication）消除重复数据块，压缩（Compression）缩小数据块体积，精简配置（Thin Provisioning）避免为未写入空间分配物理容量。三者共同作用后，阵列会显示一个综合缩减比，例如 5:1 表示逻辑数据量是物理占用量的 5 倍。
有效容量（Effective Capacity）是指扣除 RAID 保护、元数据、系统预留和快照开销后，真正可供业务写入的逻辑容量。它与“物理裸容量”不是同一个概念。例如一台标称 50TB 裸容量的阵列，扣除双校验 RAID 和系统开销后，可用物理容量可能只有约 36TB；再乘以 5:1 缩减比，有效容量约为 180TB。但这个 180TB 是“逻辑可写容量”，不是“保证能写满的容量”。
精简配置让卷在创建时只声明逻辑大小，实际物理空间按写入量分配。这带来两个好处：一是提高空间利用率，二是简化扩容。但它也带来一个风险：如果多个卷同时快速增长，物理池可能被耗尽，导致写入失败。因此 Pure Storage 阵列会设置“阈值告警”，通常在物理池使用率达到 70%、85% 时触发。
三、快照与克隆的空间开销
快照（Snapshot）和克隆（Clone）是 Pure Storage 阵列中非常高效的功能，但它们并非“零成本”。Pure Storage 采用元数据指针机制：快照创建时只复制指针，不复制数据块，因此初始开销极小。但当源卷数据被修改时，旧数据块需要保留给快照，这就产生了写时复制（Copy-on-Write）开销。快照保留时间越长、源卷修改越频繁，快照占用的物理空间就越大。
克隆与快照类似，但克隆是一个可独立读写的卷。克隆创建时同样只复制指针，后续对克隆或源卷的修改都会触发数据块分离。因此，如果计划创建大量克隆用于测试或开发，必须预留足够的物理池空间，否则可能因空间不足导致克隆失败或源卷写入受阻。
| 术语 | 含义 | 关键影响 | 观察/判断方式 |
|---|---|---|---|
| IOPS | 每秒完成 I/O 次数 | 反映处理能力，需结合块大小 | 读/写分开看，关注是否随 QD 线性增长 |
| 时延 | 单 I/O 完成时间 | 直接影响用户体验 | 看 P95/P99，而非仅平均值 |
| 带宽 | 单位时间传输数据量 | 决定大块业务吞吐 | 带宽 ≈ IOPS × 平均 I/O 大小 |
| 队列深度 | 在途未完成 I/O 数 | 连接 IOPS 与时延的桥梁 | 找拐点：IOPS 增幅小、时延增幅大 |
| 数据缩减比 | 去重+压缩+精简的综合效果 | 决定有效容量上限 | 看阵列综合缩减比，但需扣除保护开销 |
| 有效容量 | 扣除保护与开销后的可写逻辑容量 | 容量规划的真实依据 | 裸容量 → 可用物理 → 乘缩减比 |
| 精简配置 | 按写入量分配物理空间 | 提高利用率，但有池耗尽风险 | 监控物理池使用率，设 70%/85% 告警 |
| 快照/克隆 | 指针复制 + 写时复制 | 初始开销小，长期保留会增长 | 关注快照保留策略与源卷修改频率 |
四、把性能与容量放在一起判断
性能指标和容量术语不是两套独立体系。例如，当物理池使用率超过 85% 时，阵列可能触发空间回收和垃圾回收，间接推高时延；当快照数量过多时，元数据操作增加，也会影响 IOPS 和时延。因此在实际运维中，建议把 IOPS、时延、带宽、队列深度、物理池使用率、快照数量放在同一个监控面板中观察，才能快速定位是性能瓶颈还是容量瓶颈。
一个实用的判断顺序是：先看时延是否稳定，再看 IOPS 是否随队列深度合理增长，然后用带宽校验业务吞吐是否达标；容量侧则先看物理池使用率，再看缩减比是否与预期一致，最后检查快照和克隆的保留策略是否合理。这样，性能优化和容量规划就能在同一套术语体系下协同进行。