我有一个通用服务器，为许多用户提供邮件、DNS、网络、数据库和一些其他服务。
它配备了 3.40 GHz 的 Xeon E3-1275、16 GB ECC RAM。运行 Linux 内核 4.2.3，带有 ZFS-on-Linux 0.6.5.3。
磁盘布局为 2 个 Seagate ST32000641AS 2 TB 驱动器和 1 个 Samsung 840 Pro 256 GB SSD
我在 RAID-1 镜像中安装了 2 个 HD，并且 SSD 充当缓存和日志设备，全部在 ZFS 中进行管理。
我第一次安装系统时，它的速度快得惊人。没有真正的基准，只是……快。
现在，我注意到速度极度缓慢，尤其是在保存所有邮件目录的文件系统上。每晚备份仅 46 GB 的邮件就需要 90 多分钟。有时，备份会导致如此严重的负载，以至于系统几乎在长达 6 小时内无响应。
我在速度变慢期间运行过zpool iostat zroot（我的池名为zroot），看到写入速度大约为 100-200kbytes/sec。没有明显的 IO 错误，磁盘似乎没有特别努力地工作，但读取速度几乎慢得无法使用。
奇怪的是，我在另一台运行 FreeBSD 的机器上也有同样的经历，虽然没有 SSD，但硬件规格类似。几个月来它运行良好，然后以同样的方式变慢了。
我的怀疑是这样的：我使用zfs 自动快照创建每个文件系统的滚动快照。它会创建 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挂起。图表：
答案1
查看 arc_meta_used 和 arc_meta_limit。如果有大量小文件，内存中的元数据缓存就会被填满，因此内存必须查看磁盘中的文件信息，这会使整个系统运行缓慢。
我不确定如何在 Linux 上执行此操作，我的经验是在 FreeBSD 上。