Gluster + ZFS，基准测试期间死锁：zfs_iput_taskq 100% cpu

Question

首先是一些背景：我在一家运行 PHP 网络应用程序的公司工作。我们在多个网络服务器上通过 NFS 安装了一个存储后端。今天我们遇到了一个问题，如果一个网络服务器通过 NFS 写入文件，有时该文件直到几分钟后才会出现在其他安装的客户端上。它也不是多余的，因此我们无法执行任何“隐形”维护。

我一直在考虑迁移到 GlusterFS 解决方案（两个或三个复制的砖块/机器以实现冗余）。现在，使用 XFS 作为 Gluster “背后”的存储文件系统效果很好，性能也很好。Gluster 似乎也没有上面提到的同步问题。

但是，我想使用 ZFS 作为后端文件系统，原因是；

• 便宜的压缩（当前存储 1.5TB 未压缩）
• 很容易扩展存储卷“实时”（一个命令，比较 LVM 一团糟）
• 快照、位腐烂保护和所有其他 ZFS 荣耀。

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

为了测试这个设置，我在 Gluster 上安装了卷，然后运行 ​​BlogBench ( http://www.pureftpd.org/project/blogbench ) 来模拟负载。我遇到的问题是，在测试结束时，ZFS 存储似乎陷入僵局。所有三台机器都有“zfs_iput_taskq”以 90-100% 的 CPU 运行，并且测试冻结。如果我中止测试，僵局不会消失，唯一的选择似乎是硬重启。

我试过了：

• 禁用时间
• 禁用调度程序（noop）
• 不同压缩/无压缩
• 直接在 ZFS 上的 Blogbench 工作正常
• 作为后端的 Gluster + XFS 上的 Blogbench 工作正常

想法？我应该放弃 ZFS 并使用其他东西吗？备择方案？

问候奥斯卡

Answer 1

Linux 上的 ZFS 需要进行一些基本调整才能在负载下良好运行。ZFS ARC 和 Linux 虚拟内存子系统之间存在一些争议。

对于您的 CentOS 系统，请尝试以下操作：

创建/etc/modprobe.d/zfs.conf配置文件。这是在模块加载/启动期间读取的。

添加如下内容：

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)。SAS 可能是 12-24 点。否则，保留默认值。

您还需要一些下限值/etc/sysctl.conf

vm.swappiness = 10
vm.min_free_kbytes = 512000

最后，对于 CentOS，您可能需要安装tuned并将tuned-utils您的配置文件设置为虚拟来宾tuned-adm profile virtual-guest。

尝试这些方法，看看问题是否仍然存在。

编辑：

跑步zfs set xattr=sa storage。原因如下。您可能必须擦除卷并重新开始（我绝对建议这样做）。