几个月后 ZFS 极度减速

Question

我有一个通用服务器，为许多用户提供邮件、DNS、Web、数据库和一些其他服务。

它有一个 3.40 GHz 的 Xeon E3-1275，16 GB ECC RAM。运行 Linux 内核 4.2.3，带有 ZFS-on-Linux 0.6.5.3。

磁盘布局为 2 个希捷 ST32000641AS 2 TB 驱动器和 1 个三星 840 Pro 256 GB SSD

我在 RAID-1 镜像中有 2 个 HD，而 SSD 充当缓存和日志设备，所有这些都在 ZFS 中进行管理。

当我第一次设置系统时，它的速度非常快。没有真正的基准，只是......快。

现在，我注意到速度非常慢，尤其是在保存所有邮件目录的文件系统上。对于仅 46 GB 的邮件，进行每晚备份需要 90 多分钟。有时，备份会导致如此极端的负载，以致系统在长达 6 小时内几乎没有响应。

在这些减速期间，我已经运行zpool iostat zroot（我的池名为zroot），并且看到写入速度为 100-200kbytes/sec。没有明显的 IO 错误，磁盘似乎没有特别努力地工作，但读取速度几乎无法使用。

奇怪的是，我在不同的机器上有完全相同的体验，具有类似规格的硬件，虽然没有 SSD，但运行 FreeBSD。它工作了好几个月，然后以同样的方式变慢。

我的怀疑是：我使用zfs-auto-snapshot来创建每个文件系统的滚动快照。它创建 15 分钟、每小时、每天和每月的快照，并保留一定数量的快照，删除最旧的快照。这意味着随着时间的推移，在每个文件系统上创建和销毁了数千个快照。这是我能想到的唯一具有累积效应的正在进行的文件系统级操作。我尝试销毁所有快照（但保持进程运行，创建新快照），并没有发现任何变化。

不断创建和销毁快照有问题吗？我发现拥有它们是一个非常有价值的工具，并且被引导相信它们（除了磁盘空间）或多或少是零成本的。

还有其他可能导致此问题的原因吗？

编辑：命令输出

的输出zpool list：

NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zroot  1.81T   282G  1.54T         -    22%    15%  1.00x  ONLINE  -

的输出zfs list：

NAME             USED  AVAIL  REFER  MOUNTPOINT
zroot            282G  1.48T  3.55G  /
zroot/abs       18.4M  1.48T  18.4M  /var/abs
zroot/bkup      6.33G  1.48T  1.07G  /bkup
zroot/home       126G  1.48T   121G  /home
zroot/incoming  43.1G  1.48T  38.4G  /incoming
zroot/mail      49.1G  1.48T  45.3G  /mail
zroot/mailman   2.01G  1.48T  1.66G  /var/lib/mailman
zroot/moin       180M  1.48T   113M  /usr/share/moin
zroot/mysql     21.7G  1.48T  16.1G  /var/lib/mysql
zroot/postgres  9.11G  1.48T  1.06G  /var/lib/postgres
zroot/site       126M  1.48T   125M  /site
zroot/var       17.6G  1.48T  2.97G  legacy

一般来说，这不是一个非常繁忙的系统。下图中的峰值是每晚备份：

我设法在减速期间（从今天早上 8 点左右开始）赶上了系统。一些操作相当灵敏，但当前平均负载为 145，zpool list只是挂起。图形：

Answer 1

查看 arc_meta_used 和 arc_meta_limit。如果有大量小文件，您可能会填满内存中的元数据缓存，因此它必须在磁盘上查找文件信息，这可能会降低速度。

我不知道如何在 Linux 上执行此操作，我的经验是在 FreeBSD 上。