OSX 文件系统数据集上的 OpenZFS 性能问题

Question

tl;dr - 当我使用 指定 abs=128K或更高时dd，我的 ZFS RAIDZ2 阵列以 7.5+ GB/s 的速度读取并以 2.0+ GB/s 的速度写入。OS X 假设 1K（按照stat -f %k .），而我的所有速度都是 ~300MB/s；dd使用 提供相同的性能bs=1k。甚至 abs=4k使用 dd 也能提供 1.1GB/s。

我该怎么做才能将常规 I/O 提高到至少 1GB/s？

--

细节：

我在 OSX（v1.31r2）文件系统（v5000）上通过 Thunderbolt 2（双 Areca 8050T2）运行 16 驱动器 SATA3 RAIDZ2 OpenZFS，并将其连接到 12 核 64GB Mac Pro。

ZFS 文件系统是使用ashift=12（具有 4096 字节块的高级格式 HDD）和创建的recordsize=128k。

我看到 OS X 中的阵列和使用默认命令的终端的传输速率约为 300MB/s（注意，复制的文件是 10GB 的随机数据）：

普通副本：

Titanic:lb-bu admin$ time cp big-test.data /dev/null

real    0m23.730s
user    0m0.005s
sys     0m12.123s

≈ 424 MB/秒

--

dd和bs=1k：

Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=1024
9841180+0 records in
9841180+0 records out
10077368320 bytes transferred in 32.572506 secs (309382653 bytes/sec)

real    0m32.575s
user    0m1.880s
sys     0m30.695s

≈ 309 MB/秒

--

dd和bs=4k

Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=4096
2460295+0 records in
2460295+0 records out
10077368320 bytes transferred in 8.686014 secs (1160183301 bytes/sec)

real    0m8.688s
user    0m0.460s
sys     0m8.228s

≈1.16 GB/秒

- dd和bs=2m：

Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=2m
4805+1 records in
4805+1 records out
10077368320 bytes transferred in 1.162891 secs (8665788130 bytes/sec)

real    0m1.165s
user    0m0.003s
sys     0m1.162s

≈8.67 GB/秒

--

OS X's read of the boot drive optimal I/O block size (1TB SSD, HFS+):
Titanic:lb-bu admin$ stat -f %k /
4096

--

OS X's read of the array's optimal I/O block size (16-drives RAIDZ2, ZFS):
Titanic:lb-bu admin$ stat -f %k .
1024

--

我还在文件系统旁边的池上创建了一个 ZFS 卷，并将其格式化为 HFS+。我获得了与上述相同的性能。

我运行的速度比最佳速度低约 20-30 倍！我遗漏了什么？有什么想法吗？

--

更新：高速缓存 I/O（感谢 @yoonix）。≈300MB/s 的速度对于此硬件来说似乎仍然太慢了。

@qasdfdsaq：I/O 期间的 CPU 利用率可以忽略不计（所有核心 <5%）。

zfs 获取所有输出：

NAME            PROPERTY               VALUE                    SOURCE
lb-bu           type                   filesystem               -
lb-bu           creation               Tue Sep 30 16:41 2014    -
lb-bu           used                   36.8T                    -
lb-bu           available              10.0T                    -
lb-bu           referenced             138M                     -
lb-bu           compressratio          1.00x                    -
lb-bu           mounted                yes                      -
lb-bu           quota                  none                     default
lb-bu           reservation            none                     default
lb-bu           recordsize             128K                     default
lb-bu           mountpoint             /Volumes/lb-bu           local
lb-bu           sharenfs               off                      default
lb-bu           checksum               on                       default
lb-bu           compression            lz4                      local
lb-bu           atime                  on                       default
lb-bu           devices                on                       default
lb-bu           exec                   on                       default
lb-bu           setuid                 on                       default
lb-bu           readonly               off                      default
lb-bu           zoned                  off                      default
lb-bu           snapdir                hidden                   default
lb-bu           aclmode                discard                  default
lb-bu           aclinherit             restricted               default
lb-bu           canmount               on                       default
lb-bu           xattr                  on                       default
lb-bu           copies                 1                        default
lb-bu           version                5                        -
lb-bu           utf8only               on                       -
lb-bu           normalization          formD                    -
lb-bu           casesensitivity        insensitive              -
lb-bu           vscan                  off                      default
lb-bu           nbmand                 off                      default
lb-bu           sharesmb               off                      default
lb-bu           refquota               none                     default
lb-bu           refreservation         none                     default
lb-bu           primarycache           all                      default
lb-bu           secondarycache         all                      default
lb-bu           usedbysnapshots        0                        -
lb-bu           usedbydataset          138M                     -
lb-bu           usedbychildren         36.8T                    -
lb-bu           usedbyrefreservation   0                        -
lb-bu           logbias                latency                  default
lb-bu           dedup                  off                      default
lb-bu           mlslabel               none                     default
lb-bu           sync                   standard                 default
lb-bu           refcompressratio       1.01x                    -
lb-bu           written                138M                     -
lb-bu           logicalused            36.8T                    -
lb-bu           logicalreferenced      137M                     -
lb-bu           snapdev                hidden                   default
lb-bu           com.apple.browse       on                       default
lb-bu           com.apple.ignoreowner  off                      default
lb-bu           com.apple.mimic_hfs    off                      default
lb-bu           redundant_metadata     all                      default
lb-bu           overlay                off                      default

Answer 1

您没有zpool status为此发布，但您在帖子中暗示所有 16 个磁盘都在 RAIDZ2 中的单个 vdev 中。虽然这是一个好的、安全的配置，但您必须了解 RAIDZ 的设计主要不是速度。它被设计为近乎无懈可击。RAIDZ2 类似于 RAID6，但变体具有使其速度更慢、更安全的功能。

看这篇写得很好了解完整细节，但以下两句引言应该能帮助你了解问题所在（重点是我的）：

在写入 RAID-Z vdev 时，每个文件系统块都会被拆分成自己的条带，分布在 RAID-Z vdev 的所有设备上（可能）。这意味着每个写入 I/O 都必须等到 RAID-Z vdev 中的所有磁盘都完成写入。因此，从等待 IO 完成的单个应用程序的角度来看，您将获得 RAID-Z vdev 中最慢磁盘的 IOPS 写入性能。

从 RAID-Z vdev 读取时，适用相同的规则，因为过程本质上是相反的（没有像镜像情况下那样的循环捷径）：如果你幸运的话，带宽会更好（并且读取方式与你编写的方式相同）以及大多数情况下单个磁盘的 IOPS 读取性能。

实际上，您有 16 个中速驱动器，每次写入时，您都要等待所有 16 个驱动器与控制器进行检查，并在下一次写入开始之前显示“完成”。使用 16 个磁盘，您实际上总是要等待磁盘旋转接近满，然后才能进行一次写入，因此您会受到物理和 ZFS 提交数据方式的限制。

单个进程/线程写入任务通常不是 ZFS 的最佳情况。同时运行多个小数据读取/写入任务可能会显示更好的 IOPS 数字，但我认为 ZFS 的物理特性才是主要问题。

如果您愿意牺牲空间，镜像可能会更快。通过在池中创建 2 个 8 磁盘 RAIDZ2 vdev（而不是 1 个 16 磁盘 RAIDZ2 vdev），您还可以从 ZFS 中获得略微更好的性能。这也会占用您可用的存储空间，但可能有助于更快地完成提交。

不幸的是我没有好消息告诉你。