Gluster + ZFS,基准testing期间死锁:zfs_iput_taskq 100%cpu

首先是一些背景:我在一家运行PHP-web应用程序的公司工作。 我们在几个networking服务器上通过NFS安装了一个存储后端。 今天,如果一个networking服务器通过NFS写入一个文件,有时这个文件在几分钟之后才会出现在其他挂载的客户端上。 这也不是多余的,所以我们不能进行任何“隐形”维护。

我一直在考虑迁移到一个GlusterFS解决scheme(两个或三个复制砖/冗余机器)。 现在,使用XFS作为Gluster后面的存储文件系统运行得非常好,性能更好。 Gluster也似乎没有上面提到的同步问题。

但是,我想用ZFS作为后端文件系统,原因在于;

  • 廉价的压缩(目前存储1.5TB未压缩)
  • 很容易扩大存储量“活”(一个命令,比较LVM的混乱)
  • 快照,Bit-rot保护和所有其他ZFS荣耀。

在我的解决scheme的演示设置中,我有三台服务器,每台服务器上有一个独立的磁盘,带有一个ZFS后端池的复制Gluster。 我在Linux(0.6.2)+ GlusterFS 3.4上使用CentOS 6.5和ZFS。 我也尝试与Ubuntu 13.10。 一切都在VMware ESX中。

为了testing这个设置,我把音量挂在Gluster上,然后运行BlogBench( http://www.pureftpd.org/project/blogbench )来模拟加载。 我遇到的问题是,在testing结束时,ZFS存储似乎陷入了僵局。 所有这三台机器都有以90-100%CPU运行的“zfs_iput_taskq”,并且testing冻结。 如果我中止testing,死锁不会消失,只有选项似乎是硬重启。

我努力了:

  • 禁用一次
  • 禁用调度程序(noop)
  • 不同的压缩/不压缩
  • 直接在ZFS上的Blogbench工作正常
  • Gluster + XFS上的Blogbench作为后端工作正常

想法? 我应该放弃ZFS和其他东西? 备择scheme?

问候奥斯卡

Linux上的ZFS需要一些基本的调整才能在负载下正常运行。 ZFS ARC和Linux虚拟内存子系统之间有一点争执。

对于您的CentOS系统,请尝试以下操作:

创build一个/etc/modprobe.d/zfs.confconfiguration文件。 这是在模块加载/启动期间读取的。

添加如下内容:

 options zfs zfs_arc_max=40000000000 options zfs zfs_vdev_max_pending=24 

其中zfs_arc_max大概是你的RAM的40%( 编辑:尝试 zfs_arc_max=1200000000 )。 zfs_vdev_max_pending的编译默认值是8或10,具体取决于版本。 SSD或低延迟驱动器的值应该很高(48)。 也许12-24为SAS。 否则,保持默认。

你也想在/etc/sysctl.conf有一些底价值

 vm.swappiness = 10 vm.min_free_kbytes = 512000 

最后,在CentOS中,您可能需要安装tuned tuned-utils并将您的configuration文件设置为具有tuned-adm profile virtual-guest

尝试这些,看看问题是否依然存在。

编辑:

运行zfs set xattr=sa storage 。 这是为什么。 你可能需要擦拭卷并重新开始( 我肯定会推荐这么做 )。