在 ZFSonlinux 上使用 MongoDB（我相信它是映射数据库）时，我遇到了巨大的性能问题。
我们的 Mongodb 几乎只有写入。在没有 ZFS 的副本上，当应用程序每 30 秒写入一次数据库时，磁盘完全繁忙约 5 秒，中间没有磁盘活动，因此我将其作为比较的基准行为。
在具有 ZFS 的副本上，磁盘一直都很忙，副本挣扎着跟上 MongoDB 主数据库的最新状态。我在所有副本上都启用了 lz4 压缩，并且节省的空间很大，所以应该有更少的数据打到磁盘
所以在这些 ZFS 服务器上，我首先设置了默认记录大小 = 128k。然后我在重新同步 Mongo 数据之前擦除了数据并设置了 recordsize=8k。然后我再次擦拭并尝试recordsize = 1k。我也试过没有校验和的recordsize=8k
尽管如此，它并没有解决任何问题，磁盘始终保持 100% 忙碌。只有一次在记录大小 = 8k 的服务器上，磁盘比任何非 ZFS 副本都忙得多，但是在尝试不同的设置并再次尝试记录大小 = 8k 后，磁盘为 100%，我看不到以前的良好行为，并且在任何其他副本上也看不到它。
此外，应该几乎只有写入，但看到在不同设置下的所有副本上，磁盘完全忙于 75% 的读取和只有 25% 的写入
（注意，我相信 MongoDB 是映射数据库。有人告诉我在 AIO 模式下尝试 MongoDB，但我没有找到如何设置它，并且在另一台运行 MySQL InnoDB 的服务器上我意识到 ZFSonLinux 无论如何都不支持 AIO。）
我的服务器是 CentOS 6.5 内核 2.6.32-431.5.1.el6.x86_64。spl-0.6.2-1.el6.x86_64 zfs-0.6.2-1.el6.x86_64
#PROD 13:44:55 root@rum-mongo-backup-1:~: zfs list
NAME USED AVAIL REFER MOUNTPOINT
zfs 216G 1.56T 32K /zfs
zfs/mongo_data-rum_a 49.5G 1.56T 49.5G /zfs/mongo_data-rum_a
zfs/mongo_data-rum_old 166G 1.56T 166G /zfs/mongo_data-rum_old
#PROD 13:45:20 root@rum-mongo-backup-1:~: zfs list -t snapshot
no datasets available
#PROD 13:45:29 root@rum-mongo-backup-1:~: zfs list -o atime,devices,compression,copies,dedup,mountpoint,recordsize,casesensitivity,xattr,checksum
ATIME DEVICES COMPRESS COPIES DEDUP MOUNTPOINT RECSIZE CASE XATTR CHECKSUM
off on lz4 1 off /zfs 128K sensitive sa off
off on lz4 1 off /zfs/mongo_data-rum_a 8K sensitive sa off
off on lz4 1 off /zfs/mongo_data-rum_old 8K sensitive sa off
那里会发生什么？我应该怎么看才能弄清楚 ZFS 在做什么或哪个设置设置不当？
EDIT1：
硬件：这些是租用的服务器，Xeon 1230 或 1240 上的 8 个 vcore，16 或 32GB RAM，zfs_arc_max=2147483648使用 HP 硬件 RAID1。所以 ZFS zpool 在 /dev/sda2 上，并不知道有底层 RAID1。即使是 ZFS 的次优设置，我仍然不明白为什么磁盘在读取时阻塞，而 DB 只写入。
我理解许多原因，我们不需要在这里再次公开，这很糟糕，......对于 ZFS，我很快就会有一个 JBOD/NORAID 服务器，我可以用 ZFS 自己的 RAID1 进行相同的测试在 sda2 分区上实现，使用 /、/boot 和交换分区使用 mdadm 执行软件 RAID1。
首先，值得说明的是 ZFS 不是 Linux 上 MongoDB 支持的文件系统——推荐的文件系统是 ext4 或 XFS。因为在 Linux 上甚至没有检查 ZFS（例如，参见SERVER-13223），它不会使用稀疏文件，而是尝试预分配（用零填充），这将意味着COW文件系统上的可怕性能。在解决此问题之前，添加新数据文件将对 ZFS 造成巨大的性能影响（您将尝试频繁地进行写入操作）。虽然您没有这样做，但性能应该会提高，但如果您添加数据的速度足够快，您可能永远无法在分配命中之间恢复。
此外，ZFS 不支持 Direct IO，因此您将多次将数据复制到内存中（mmap、ARC 等）——我怀疑这是您读取的来源，但我必须进行测试才能确定。上次我在 Linux 上看到任何使用 MongoDB/ZFS 进行的测试时，性能很差，即使使用 SSD 上的 ARC - ext4 和 XFS 速度要快得多。ZFS 将来可能适用于 Linux 上的 MongoDB 生产使用，但现在还没有准备好。
这可能听起来有点疯狂，但我支持另一个受益于 ZFS 卷管理属性的应用程序，但在本机 ZFS 文件系统上表现不佳。
我的解决方案？！？
XFS 在ZFS zvols之上。
为什么？！？
因为 XFS 性能良好并且消除了我在使用原生 ZFS 时遇到的特定于应用程序的问题。ZFS zvols 允许我精简配置卷、添加压缩、启用快照并有效利用存储池。对我的应用程序更重要的是，zvol 的 ARC 缓存减少了磁盘上的 I/O 负载。
看看你是否可以按照这个输出：
ZFS zvol，通过以下方式创建：（
zfs create -o volblocksize=128K -s -V 800G vol0/pprovol请注意，启用了自动快照）ZFS zvol 块设备的属性。900GB 卷（磁盘上的实际大小为 143GB）：
ZFS 块设备上的 XFS 信息：
XFS 挂载选项：
注意：在某些情况下，我也在 HP Smart Array 硬件 RAID 之上执行此操作。
池创建如下所示：
结果看起来像：
我们正在研究在 ZFS 上运行 Mongo，发现这篇文章引起了对可用性能的主要担忧。两年过去了，我们想看看在 mmap 上使用 WiredTiger 的 Mongo 新版本如何在最新的 Ubuntu Xenial 版本附带的现在官方支持的 ZFS 上执行。
总之，很明显 ZFS 的性能不如 EXT4 或 XFS，但性能差距并不明显，尤其是考虑到 ZFS 提供的额外功能时。
我已经发表了一篇关于我们的发现和方法的博客文章。希望对你有帮助！
我相信您的磁盘正忙于读取，因为
环境。在这里，您明确将 ARC 限制为 2Gb，即使您有 16-32Gb。谈到 ARC，ZFS 非常消耗内存和热心。如果您有与 ZFS 副本相同的非 ZFS 副本（下面的 HW RAID1），则进行一些数学运算会产生
这意味着您可能会在 5 秒内使整个 ARC 缓存失效。ARC（在某种程度上）是“智能的”，并且会尝试保留最近写入的块和最常用的块，因此您的 ZFS 卷很可能会尝试为您提供一个体面的数据缓存，而它拥有的空间有限。尝试将 zfs_arc_max 提高到 RAM 的一半（甚至更多），并使用 arc_shrink_shift 更积极地驱逐 ARC 缓存数据。
在这里，您可以找到一个包含 17 部分的博客阅读材料，用于调优和理解 ZFS 文件系统。
在这里您可以找到 ARC 收缩移位设置说明（第一段），这将允许您在驱逐时回收更多的 ARC RAM 并保持控制。
我不确定 XFS on zvol 解决方案的可靠性。尽管 ZFS 是 COW，但 XFS 不是。假设 XFS 正在更新其元数据并且机器断电。由于 COW 功能，ZFS 将读取数据的最后一个良好副本，但 XFS 不会知道该更改。您的 XFS 卷可能会保留一半的“快照”到电源故障前的版本，以及另一个电源故障后的版本（因为 ZFS 不知道所有 8Mb 写入必须是原子的并且仅包含 inode） .
[编辑] arc_shrink_shift 和其他参数可用作 ZFSonlinux 的模块参数。尝试
获取所有受支持的配置。
您的 ZFS 设置是什么，尤其是主缓存、logbias 和同步？
确保 primarycache=all，logbias=throughput。
sync=disabled 将显着加快写入速度，但如果发生崩溃，可能会丢失最多 5 秒最近写入的数据。鉴于您所描述的症状，您可能还希望禁用 ZFS 预取。
我写了一篇文章，基于我不久前关于在 ZFS 上运行 MySQL的演讲，您可能会发现它很有帮助。