我用ZFSonlinux使用MongoDB（我相信它是mmapped数据库）有巨大的性能问题。
我们的Mongodb几乎只是写道。 对于没有ZFS的副本，磁盘完全忙于〜5秒的峰值，当应用程序每30秒写入一次数据库，并且两者之间没有磁盘活动时，我将其作为基准行为进行比较。
在使用ZFS的副本上，磁盘始终处于繁忙状态，副本持续跟踪MongoDB主节点。 我在所有副本上都启用了lz4压缩function，节省的空间非常大，所以应该有更less的数据打到磁盘上
所以在这些ZFS服务器上，我首先有默认的recordsize = 128k。 然后我擦除数据，并设置recordsize = 8K，然后再同步Mongo数据。 然后我又擦了一遍，试着logging= 1k。 我也尝试logging= 8K没有校验
尽pipe如此，它并没有解决任何问题，磁盘总是保持100％的繁忙。 在logging大小= 8k的服务器上只有一次，磁盘比任何非ZFS复本less得多，但是在尝试不同的设置并再次尝试recordize = 8k后，磁盘是100％，我看不到以前的良好行为，并不能在任何其他副本上看到它。
而且，应该几乎只有写入，但是看到在不同设置下的所有副本上， 磁盘完全忙于75％的读取，只有25％的写入
（注意，我相信MongoDB是mmap数据库，有人告诉我在AIO模式下试用MongoDB，但是我没有find如何设置它，而在另一个运行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：
硬件：这些是租用服务器，至强1230或1240,16或32GB内存上的8个核心， zfs_arc_max=2147483648 ，使用HP硬件RAID1。 所以ZFS zpool在/ dev / sda2上并不知道底层有RAID1。 即使是ZFS的次最佳设置，我仍然不明白为什么磁盘在读取时窒息，而DB只写入。
我了解了很多原因，我们不需要再次暴露在这里，这是糟糕的，对于ZFS来说，我很快就会有一个JBOD / NORAID服务器，我可以使用ZFS自己的RAID1在sda2分区上执行，用/，/ boot和swap分区，用mdadm做软件RAID1。
这可能听起来有点疯狂 ，但我支持另一个受益于ZFS卷pipe理属性的应用程序，但在本机ZFS文件系统上performance不佳。
我的解决scheme？！？
XFS在ZFS zvols之上 。
为什么？！？
因为XFS运行良好，并消除了我在本地ZFS面临的特定于应用程序的问题。 ZFS zvols使我可以精简configuration卷，添加压缩，启用快照并有效利用存储池。 对我的应用来说更重要的是，zvol的ARCcaching减less了磁盘上的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 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之上执行此操作。
池的创build如下所示：
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
首先，值得一提的是，ZFS并不是Linux上支持MongoDB的文件系统 – 推荐的文件系统是ext4或XFS。 因为在Linux上甚至没有检查过ZFS（例如参见SERVER-13223 ），所以它不会使用稀疏文件，而是试图预先分配（填充零），这将意味着COW文件系统的可怕performance。 在修正之前，添加新的数据文件将会对ZFS产生巨大的性能影响（您将会频繁地使用您的写入function）。 虽然你不这样做，性能应该改善，但如果你正在快速添加数据，你可能永远不会恢复分配点击。
此外，ZFS不支持直接IO，因此您将多次拷贝数据到内存（mmap，ARC等） – 我怀疑这是您的读取的来源，但我将不得不testing确定。 上一次我看到在Linux上使用MongoDB / ZFS进行testing时，性能很差，即使在SSD上使用ARC，ext4和XFS的速度也大大提高。 将来ZFS可能适用于Linux上的MongoDB生产，但现在还没有准备好。
我们正在研究在ZFS上运行Mongo，看到这个post提出了对可用性能的主要担忧。 两年来，我们希望看到如何在mmap上使用WiredTiger的新版本的Mongo，在最新的Ubuntu Xenial发行版附带的现在正式支持的ZFS上执行。
总而言之，ZFS显然不如EXT4或XFS，但性能差距并不那么显着，特别是当您考虑ZFS提供的额外function时。
我写了一篇关于我们的发现和方法的博客文章 。 希望对你有帮助！
我相信你的磁盘忙于读取，因为
zfs_arc_max=2147483648
设置。 这里你明确地将ARC限制在2Gb，即使你有16-32Gb。 当涉及到ARC时，ZFS对内存饥渴，热情非常高。 如果您有非ZFS副本与ZFS副本（下面的HW RAID1）相同，则可以执行一些math操作
5s spike @ (200Mb/s writes (estimated 1 hdd throughput) * 2 (RAID1)) = 2Gb over 5sec
这意味着您可能在5秒钟内使整个ARCcaching失效。 ARC（在某种程度上）是“智能的”，并且会尽量保留最近写的块和最常用的块，所以你的ZFS卷可能会试图为你提供一个体面的数据caching，它的空间有限。 尝试将zfs_arc_max提升到内存的一半（甚至更多），并使用arc_shrink_shift更积极地驱逐ARCcaching数据。
在这里你可以find一个17部分的博客阅读调整和理解ZFS文件系统。
在这里，您可以findARC缩进设置解释（第一段），这将允许您在驱逐时回收更多的ARC RAM并将其保持在控制之下。
我不确定在zvol解决scheme上的XFS的可靠性。 即使ZFS是COW，XFS也不是。 假设XFS正在更新其元数据，并且机器断电。 由于COWfunction，ZFS将读取数据的最后一个正确副本，但是XFS不会知道这个变化。 您的XFS卷可能会保留“断电”到掉电前的版本一半，以及断电后的版本（因为ZFS不知道所有8Mb写入必须是primefaces的，并且只包含inode） 。
[编辑] arc_shrink_shift和其他参数可用作ZFSonlinux的模块参数。 尝试
modinfo zfs
获取所有支持的configuration。