☰

Linux 软件 raid-10 性能不佳

tag-icon • tag-icon linux software-raid sas lsi
Linux 软件 raid-10 性能不佳

我有一台配备 8 通道 LSI SAS3008 控制器芯片的机器，单独驱动器测试表明我可以以 174 MB/秒到 193 MB/秒之间的速度写入任何磁盘或所有磁盘，并且写入速度持续：

dd if=/dev/zero of=/dev/mapper/mpath?p1 bs=1G count=100 oflag=direct这是在命令中运行的输出平行线所有 12 个磁盘：

107374182400 bytes (107 GB) copied, 556.306 s, 193 MB/s
107374182400 bytes (107 GB) copied, 566.816 s, 189 MB/s
107374182400 bytes (107 GB) copied, 568.681 s, 189 MB/s
107374182400 bytes (107 GB) copied, 578.327 s, 186 MB/s
107374182400 bytes (107 GB) copied, 586.444 s, 183 MB/s
107374182400 bytes (107 GB) copied, 590.193 s, 182 MB/s
107374182400 bytes (107 GB) copied, 592.721 s, 181 MB/s
107374182400 bytes (107 GB) copied, 598.646 s, 179 MB/s
107374182400 bytes (107 GB) copied, 602.277 s, 178 MB/s
107374182400 bytes (107 GB) copied, 604.951 s, 177 MB/s
107374182400 bytes (107 GB) copied, 605.44 s, 177 MB/s

但是，当我将这些磁盘组合成一个软件 raid 10 设备时，我获得了大约 500 MB/秒的写入速度。我预计会获得大约两倍的速度，因为同时访问这些磁盘不会有任何损失。

我确实注意到 md10_raid10 进程（我假设它负责软件 raid 本身）的使用率接近 80%，并且一个核心始终处于 100% 等待时间，0% 空闲。但是，哪个核心在变化。

此外，当使用缓冲区缓存写入已挂载的 EXT4 文件系统而不是使用 oflag=direct 绕过缓存时，性能会进一步下降。磁盘报告 25% 繁忙（根据 munin 监控），但磁盘显然没有过热，但我担心 md10 设备本身可能过热。

关于下一步该怎么做，有什么建议吗？我正在尝试使用硬件 raid 10 配置进行比较，尽管我似乎只能构建一个 10 个磁盘单元——话虽如此，我希望能够持续获得 900 MB/秒的写入速度。我会在发现更多信息后更新这个问题。

编辑1：

如果我使用dd一个紧密循环中的命令来写入安装在该设备上的 ext4 分区，并且我不使用缓冲区缓存（oflag=direct），那么我可以在峰值时获得高达 950 MB/秒的速度，并且在对挂载标志进行一些修改后可以维持 855 MB/秒的速度。

如果我同时使用 iflag=direct 进行读取，我现在可以获得 480 MB/秒的写入速度和 750 MB/秒的读取速度。

如果我不使用 oflag=direct 进行写入，从而使用缓冲区缓存，我可以获得 230 MB/秒的写入速度和 1.2 MB/秒的读取速度，但机器似乎非常缓慢。

那么，问题是，为什么使用缓冲区缓存会如此严重地影响性能？我尝试了各种磁盘排队策略，包括在驱动器级别使用“noop”并在适当的多路径 dm 设备上放置“deadline”或“cfq”，或在所有设备上放置 deadline，或在 dm 上放置 none 并在备份驱动器上放置 deadline。似乎备份驱动器应该没有，而多路径设备应该是我想要的，但这根本不影响性能，至少在缓冲区缓存的情况下是这样。

答案1

编辑：

您的dd oflag=direct观察结果可能是由于电源管理问题造成的。使用电源TOP查看在写入负载下，CPU 的 C 状态是否过于频繁地切换至 C1 以上。如果是，请尝试调整 PM 以确保 CPU 不会进入休眠状态并重新运行基准测试。请参阅发行版的文档以了解如何执行此操作 - 在大多数情况下，这将是intel_idle.max_cstate=0内核引导行参数，但 YMMV。

写入和缓冲写入之间的性能巨大差异O_DIRECT可能是由于：

  • 当使用 O_DIRECT 时，CPU 不会进入 C3+ 睡眠状态或
  • CPU 被送入 C3+，但由于使用 O_DIRECT 时处理过程显著简化，因此这并不那么重要 - 只需指向归零的内存区域并发出 DMA 写入请求，所需的周期数比缓冲处理要少，并且对延迟的敏感度较低

过时的答案：

这看起来很像是单线程造成的瓶颈md。

推理

  • 这控制器数据表有望实现 6,000 的吞吐量
  • 您的并行dd运行显示每个驱动器 170MB /s +，因此路径不受连接 PCIe 带宽的限制
  • 您会看到 md10_raid10 的利用率高达接近 100%

虽然针对多线程 RAID5 校验和计算的补丁已承诺mdraid在 2013 年，我找不到任何有关类似 RAID1 / RAID10 增强功能的信息，所以它们可能根本不存在。

可以尝试的事情

  • 不止一个写作线程dd，只是为了看看它是否改变了什么
  • 不同的 RAID10 实现 -LVM RAID 10但你也可能想到看看 ZFS1 的设计正是考虑到了这种用例（许多磁盘，没有硬件 RAID 控制器）
  • 可能是较新的内核版本

值得一提的是，在使用机械存储介质时，您很少（如果有的话）会看到带宽上的写入性能达到峰值（尤其是使用非 CoW 文件系统）。大多数时候，您会受到寻道时间的限制，因此峰值带宽不应该成为大问题，只要它满足您的最低要求即可。

1如果你做ZFS，您应该改进测试方法，因为将全零块写入 ZFS 数据集的速度可能非常快。如果为数据集启用了压缩，则零不会写入磁盘，而只是链接到全零块。

相关内容