页面历史记录

...

测试结果如下：

进入nasv3，对本地RAID进行测试

执行命令：fio -filename=/data/activemembers/testfio -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs= 4k -size=2G -numjobs=300 -runtime=120 -group_reporting -name=mytest

测试结果如下：

Image Modified

注意：测试文件（2GB）相对于 RAID 卡缓存（通常为 1GB-4GB）来说尺寸较小，导致测试结果严重偏向于缓存性能，而不是 24 块物理 HDD 的真实随机读性能。这使得测试结果无法客观反映当工作集（Working Set）超出缓存大小时，系统的实际表现。

增加测试文件的大小到10G，执行命令：fio -filename=/data/activemembers/testfio -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs= 4k -size=10G -numjobs=300 -runtime=120 -group_reporting -name=mytest

测试结果如下：

Image Modified

横向对比结果分析

参数说明：

...

• 条带化配置未优化 (核心瓶颈)

• BeeGFS 的性能高度依赖条带大小和条带宽度配置：
  • 条带宽度：需设置为等于磁盘数（4），确保数据均匀分布到所有磁盘；
  • 条带大小：4K 随机读场景下，建议条带大小设置为 64K~256K（过小会增加元数据开销，过大则无法充分利用并行 IO）。
  • 当前 2.38 倍的性能提升，低于 4 盘的理论上限，大概率是条带化配置未匹配 4K 随机读场景。

• 超高并发线程数 (次要瓶颈)

  • 300 线程远超 BeeGFS 的最优并发数（通常分布式文件系统的最优并发线程数为 磁盘数 × 8~16，即 4 盘对应 32~64 线程）。
  • 过多线程导致上下文切换开销增加和元数据服务器竞争加剧，是长尾延迟的主要原因。

• 元数据服务器性能 (潜在瓶颈)

  • 随机读场景下，BeeGFS 需要频繁查询元数据服务器（MDS）获取数据块的物理位置。
  • 如果 MDS 为单节点部署，且未使用 SSD 缓存元数据，会成为高并发下的性能瓶颈，导致尾部延迟升高。

对nas本身的阵列性能分析

IOPS结果分析：

指标分析:

• 平均延迟显著升高：平均延迟从 10ms 飙升至 24ms，这直接反映了物理磁盘寻道和旋转延迟的影响。
• 中位数延迟是关键：中位数延迟从 0.109ms（典型缓存命中）猛增至 12.39ms，这是本次测试最核心的变化。这个数值大致等于物理硬盘的平均寻道时间（~8ms）加上旋转延迟（~4ms），完美印证了测试负载已经从 “缓存主导” 转变为 “物理磁盘主导”。
• 长尾延迟依然存在：99% 分位延迟为 156ms，说明在高并发下，仍然存在部分 IO 请求需要等待较长时间才能被处理，但整体分布相比上次更加平滑，没有出现上次那种因缓存未命中而导致的极端尖峰。

指标分析:

• 性能大幅回落：IOPS 和吞吐量均下降了约 60%。这是一个非常明确的信号，表明测试文件大小从 2G 增加到 10G，已经超出了 RAID 卡缓存的覆盖范围。系统不再能依赖高速缓存来响应大部分请求，必须频繁地访问物理硬盘，从而导致性能显著下降。
• 10G性能更真实：11.5k IOPS 的成绩，是这个 24 盘 RAID5 阵列在 4K 随机读场景下，更接近其物理极限的真实性能表现。

平均延迟分析：

结论

文件系统在高并发下的比较：

• 4 盘 BeeGFS 系统在相同超高并发配置下，性能显著优于本地单 HDD 和 NFS NAS，充分验证了分布式并行存储的优势；
• 当前性能未达理论上限，后续可通过调整优化条带化配置，可有 30%~50% 的 IOPS提升空间；
• BeeGFS 适合高并发、大规模的高性能计算（HPC）和 AI 训练场景，是本地单盘和 NAS 的理想升级方案。

Nasv3的RAID5阵列的性能：

• RAID5阵列本身的IOPS即使没有命中缓存，也依旧表现优异，理论上不应该出现卡顿。
• 说明NFS文件系统严重限制了NasV3的并发性能。