极端的ZFS在几个月后减速

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

它有一个3.40 GHz的Xeon E3-1275,16GB 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充当caching和日志设备，全部在ZFS中pipe理。

• 部分轻抚/短轻抚/半轻轻抚摸硬盘？
• 在OS X上的hdparm
• 恒定的磁盘活动 – 我怎么知道哪些文件正在被访问不间断？
• 最佳的Nagios插件SMARTd / smartmontools？
• OSX – 全盘encryption

当我第一次build立这个系统时，它非常快。 没有真正的基准，只是…快。

现在，我注意到极端的减速，特别是在保存所有maildirs的文件系统上。 做一个每晚备份需要90分钟，只有46 GB的邮件。 有时候，备份会造成极大的负载，导致系统在长达6小时内几乎无响应。

我在这些减速过程中运行zpool iostat zroot （我的池被命名为zroot ），看到的写入量为100-200kbytes / sec。 没有明显的IO错误，磁盘似乎没有工作特别困难，但读取几乎不可能慢。

奇怪的是我在另外一台机器上也有相同的体验，使用类似的spec硬件，但没有运行FreeBSD的SSD。 它工作好几个月，然后以相同的方式缓慢。

我怀疑是这样的：我使用zfs-auto-snapshot创build每个文件系统的滚动快照。 它创build15分钟，每小时，每天和每月的快照，并保持每个周围的一定数量，删除最老的。 这意味着随着时间的推移，每个文件系统上已经创build并销毁了数千个快照。 这是唯一可以考虑的累积效应的文件系统级操作。 我试图销毁所有的快照（但保持进程运行，创build新的），并没有发现变化。

是否有不断创build和销毁快照的问题？ 我发现让他们成为一个非常有价值的工具，并且被认为是（除了磁盘空间）或多或less的零成本。

还有别的可能导致这个问题吗？

编辑：命令输出

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只是挂起。 graphics：