MongoDB 和 ZFS 性能不佳：磁盘总是忙于读取而只做写入

Question

我在使用 ZFSonlinux 的 MongoDB（我相信它是 mmapped DB）时遇到了巨大的性能问题。

我们的 Mongodb 几乎只写。在没有 ZFS 的副本上，磁盘完全忙于大约 5 秒的峰值，当应用程序每 30 秒写入一次数据库时，并且中间没有磁盘活动，因此我将其作为比较的基准行为。
在具有ZFS副本，盘完全是忙碌所有的时间，与副本有点吃力跟上与MongoDB的主。我在所有副本上都启用了 lz4 压缩，并且节省的空间很大，因此访问磁盘的数据应该少得多

所以在这些 ZFS 服务器上，我首先使用默认的 recordsize=128k。然后我在重新同步 Mongo 数据之前擦除了数据并设置了 recordsize=8k。然后我再次擦拭并尝试recordsize = 1k。我也试过 recordsize=8k 没有校验和

尽管如此，它并没有解决任何问题，磁盘始终保持 100% 忙碌。仅在记录大小= 8k 的一台服务器上，磁盘比任何非 ZFS 副本忙得多，但是在尝试不同的设置并再次尝试记录大小= 8k 后，磁盘为 100%，我看不到以前的良好行为，并且在任何其他副本上也看不到它。

此外，应该几乎只有写入，但看到在不同设置下的所有副本上，磁盘完全忙于 75% 的读取和仅 25% 的写入

（注意，我相信 MongoDB 是 mmapped DB。有人告诉我在 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、16 或 32GB RAM 上的 8 个 vcore zfs_arc_max=2147483648，使用 HP 硬件 RAID1。所以ZFS zpool 在/dev/sda2 上，不知道有底层RAID1。即使是 ZFS 的次优设置，我仍然不明白为什么磁盘在读取时阻塞，而 DB 只写入。
我明白很多原因，我们不需要在这里再次公开，这既糟糕又糟糕，......对于 ZFS，我很快就会拥有一个 JBOD/NORAID 服务器，我可以用 ZFS 自己的 RAID1 做同样的测试在 sda2 分区上实现，/、/boot 和交换分区使用 mdadm 执行软件 RAID1。

Answer 1

首先，值得指出的是 ZFS 不是 Linux 上 MongoDB 支持的文件系统 - 推荐的文件系统是 ext4 或 XFS。因为在 Linux 上甚至没有检查 ZFS（例如，参见SERVER-13223）它不会使用稀疏文件，而是尝试预分配（用零填充），这将意味着COW文件系统上的可怕性能。在修复之前，添加新数据文件将对 ZFS 的性能造成巨大影响（您将经常尝试在写入时执行此操作）。虽然您没有这样做，但性能应该会提高，但是如果您添加数据的速度足够快，您可能永远不会在分配命中之间恢复。

此外，ZFS 不支持直接 IO，因此您将多次将数据复制到内存（mmap、ARC 等）中 - 我怀疑这是您的读取来源，但我必须进行测试才能确定。上次我看到在 Linux 上使用 MongoDB/ZFS 进行任何测试时，性能很差，即使在 SSD 上使用 ARC - ext4 和 XFS 的速度要快得多。ZFS 将来可能适用于 Linux 上的 MongoDB 生产用途，但现在还没有准备好。

Answer 2

这听起来有点疯狂，但我支持另一个受益于 ZFS 卷管理属性的应用程序，但在本机 ZFS 文件系统上表现不佳。

我的解决方案？！？

对XFS顶级的ZFS zvols。

为什么？！？

因为 XFS 性能良好并且消除了我在使用原生 ZFS 时遇到的特定于应用程序的问题。ZFS zvol 允许我对卷进行精简配置、添加压缩、启用快照并有效利用存储池。对我的应用程序更重要的是，zvol 的 ARC 缓存减少了磁盘上的 I/O 负载。

看看你是否可以按照这个输出：

# zpool status
  pool: vol0
 state: ONLINE
  scan: scrub repaired 0 in 0h3m with 0 errors on Sun Mar  2 12:09:15 2014
config:

        NAME                                            STATE     READ WRITE CKSUM
        vol0                                            ONLINE       0     0     0
          mirror-0                                      ONLINE       0     0     0
            scsi-SATA_OWC_Mercury_AccOW140128AS1243223  ONLINE       0     0     0
            scsi-SATA_OWC_Mercury_AccOW140128AS1243264  ONLINE       0     0     0
          mirror-1                                      ONLINE       0     0     0
            scsi-SATA_OWC_Mercury_AccOW140128AS1243226  ONLINE       0     0     0
            scsi-SATA_OWC_Mercury_AccOW140128AS1243185  ONLINE       0     0     0

ZFS zvol，创建方式为：（zfs create -o volblocksize=128K -s -V 800G vol0/pprovol注意自动快照已启用）

# zfs get all vol0/pprovol
NAME          PROPERTY               VALUE                  SOURCE
vol0/pprovol  type                   volume                 -
vol0/pprovol  creation               Wed Feb 12 14:40 2014  -
vol0/pprovol  used                   273G                   -
vol0/pprovol  available              155G                   -
vol0/pprovol  referenced             146G                   -
vol0/pprovol  compressratio          3.68x                  -
vol0/pprovol  reservation            none                   default
vol0/pprovol  volsize                900G                   local
vol0/pprovol  volblocksize           128K                   -
vol0/pprovol  checksum               on                     default
vol0/pprovol  compression            lz4                    inherited from vol0
vol0/pprovol  readonly               off                    default
vol0/pprovol  copies                 1                      default
vol0/pprovol  refreservation         none                   default
vol0/pprovol  primarycache           all                    default
vol0/pprovol  secondarycache         all                    default
vol0/pprovol  usedbysnapshots        127G                   -
vol0/pprovol  usedbydataset          146G                   -
vol0/pprovol  usedbychildren         0                      -
vol0/pprovol  usedbyrefreservation   0                      -
vol0/pprovol  logbias                latency                default
vol0/pprovol  dedup                  off                    default
vol0/pprovol  mlslabel               none                   default
vol0/pprovol  sync                   standard               default
vol0/pprovol  refcompressratio       4.20x                  -
vol0/pprovol  written                219M                   -
vol0/pprovol  snapdev                hidden                 default
vol0/pprovol  com.sun:auto-snapshot  true                   local

ZFS zvol 块设备的属性。900GB 卷（磁盘上的实际大小为 143GB）：

# fdisk -l /dev/zd0

Disk /dev/zd0: 966.4 GB, 966367641600 bytes
3 heads, 18 sectors/track, 34952533 cylinders
Units = cylinders of 54 * 512 = 27648 bytes
Sector size (logical/physical): 512 bytes / 131072 bytes
I/O size (minimum/optimal): 131072 bytes / 131072 bytes
Disk identifier: 0x48811e83

    Device Boot      Start         End      Blocks   Id  System
/dev/zd0p1              38    34952534   943717376   83  Linux

ZFS 块设备上的 XFS 信息：

# xfs_info /dev/zd0p1
meta-data=/dev/zd0p1             isize=256    agcount=32, agsize=7372768 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=235928576, imaxpct=25
         =                       sunit=32     swidth=32 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=65536, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

XFS 挂载选项：

# mount
/dev/zd0p1 on /ppro type xfs (rw,noatime,logbufs=8,logbsize=256k,nobarrier)

注意：在某些情况下，我也在 HP Smart Array 硬件 RAID 之上执行此操作。

池创建看起来像：

zpool create -o ashift=12 -f vol1 wwn-0x600508b1001ce908732af63b45a75a6b

结果如下：

# zpool status  -v
  pool: vol1
 state: ONLINE
  scan: scrub repaired 0 in 0h14m with 0 errors on Wed Feb 26 05:53:51 2014
config:

        NAME                                      STATE     READ WRITE CKSUM
        vol1                                      ONLINE       0     0     0
          wwn-0x600508b1001ce908732af63b45a75a6b  ONLINE       0     0     0

Answer 3

我们正在研究在 ZFS 上运行 Mongo，发现这篇文章引起了对可用性能的主要担忧。两年后，我们想看看使用 WiredTiger 而非 mmap 的 Mongo 新版本如何在最新的 Ubuntu Xenial 版本附带的现在官方支持的 ZFS 上执行。

总之，很明显 ZFS 的性能不如 EXT4 或 XFS，但性能差距并不大，尤其是当您考虑 ZFS 提供的额外功能时。

我已经写了一篇关于我们的发现和方法的博客文章。希望对你有帮助！