为什么在我的 ZFS NAS 上进行大量删除、复制和移动会阻止所有其他 IO?

为什么在我的 ZFS NAS 上进行大量删除、复制和移动会阻止所有其他 IO?

我有一个基于 Solaris 11 ZFS 的 NAS 设备,带有 12x1TB 7.2k rpm SATA 驱动器,采用镜像配置。

它从同一个池中提供 2 项服务 - 一个用于小型 VM 场的 NFS 服务器和一个用于小型团队托管共享文件的 CIFS 服务器。cifs ZFS 已启用重复数据删除,而 NFS ZFS 文件系统已禁用重复数据删除。所有地方都关闭了压缩。我每天都会为每个文件系统创建快照,并保留最近的 14 个快照。

当我直接通过 SSH 连接 NAS 并移动、复制或删除大量数据时,我遇到了性能问题。基本上,该过程似乎会阻止所有其他 IO 操作,甚至导致虚拟机因收到磁盘超时而停滞。

对于为什么会出现这种情况,我有几种理论,但我希望能够了解我下一步该怎么做。

任何一个:

1) 硬件不够好。我对此不太确定 - 系统是 HP X1600(单个 Xeon CPU),30GB RAM。虽然驱动器只有 7.2k SATA,但它们每个应该可以达到最大 80 IOPS,这对我来说已经足够了。不过很高兴证明我错了。

2) 我配置错误 - 很有可能。是否值得在所有地方关闭重复数据删除?我假设 RAM = 适合重复数据删除,因此给它留出合理的 RAM 空间。

3) Solaris 在调度 IO 方面很愚蠢。本地命令是否可能rm完全阻止 nfsd 的 IO?如果是这样,我该如何改变这种情况?

答案1

选项 #2 很可能是原因。当重复数据删除表 (DDT) 完全适合内存时,重复数据删除性能最佳。如果不能,则重复数据删除会溢出到磁盘,而必须转到磁盘的 DDT 查找会非常慢,从而产生阻塞行为。

我认为 30G 的 RAM 已经足够了,但 DDT 的大小直接取决于要进行重复数据删除的数据量以及重复数据删除对数据的效果。重复数据删除属性是在数据集级别设置的,但查找是在整个池中进行的,因此只有一个池范围的 DDT。

此 zfs-讨论线程计算 DDT 大小。本质上,池中每个唯一块都有一个 DDT 条目,因此如果您有大量数据但重复数据删除率较低,则意味着更多唯一块,因此 DDT 更大。系统会尝试将 DDT 保留在 RAM 中,但如果应用程序需要内存,则其中一些可能会被逐出。拥有 L2ARC 缓存可以帮助防止 DDT 进入主池磁盘,因为它将从主内存 (ARC) 逐出到 L2ARC。

答案2

使用 ZFS 和快照时要记住的一件事是,没有什么是免费的,当您删除大量数据并期望快照继续为您维护这些数据时,尤其是当您有大量快照时,在您执行删除时,快照必须相应地更新以反映文件系统的更改。我假设您有 6 个 VDEV,基本上是池中的 6 个镜像,这意味着您实际上必须对所有磁盘执行这些更改,因为数据在每个 VDEV 上分布得相当均匀。启用重复数据删除后,情况会变得更加复杂,尤其是当比率很好时,如果比率很差,请不要使用它。本质上,如果比率很好或很好,您就会有大量引用,所有这些引用当然都是元数据,它们都需要更新,以及快照和快照相关的元数据。如果您的文件系统具有较小的块大小,情况会变得更加复杂,因为 4K 块大小数据集与 128K 数据集相比,引用的数量要大得多。

基本上,除了以下几点之外,您能做的事情很少:1) 添加高性能 SSD 作为缓存设备,并调整文件系统以将缓存设备仅用于元数据;2) 减少大量删除/销毁操作;3) 重新考虑重复数据删除的使用。但是,您不能简单地在池或文件系统上禁用重复数据删除。如果在整个池上启用,则必须重新创建池;或者,如果在单个文件系统上设置,则销毁并重新创建文件系统将解决该问题。

在 Nexenta,我们在向客户推荐重复数据删除时非常谨慎。在很多情况下,重复数据删除都是一个绝妙的解决方案,客户没有它就无法生存。在这些情况下,我们经常有客户使用 96GB 或更多的 RAM,以在 RAM 中维护更多的元数据和 DDT。一旦 DDT 元数据被推送到旋转介质,一切都会戛然而止。希望这能有所帮助。

相关内容