为什么 zfs 性能对于在 fs 内移动文件不利?

Ano*_*wie 4 performance zfs freenas

在我的 FreeNAS NAS(运行 zfs v28 的 9.1.1)上,我在同一个 raidz fs 中的两个目录之间移动文件的性能很差。这是预期的吗?如果没有,我怎么能找出故障呢?

本例中的应用程序是 Beets(mp3 mgmt 软件),在 NAS 本身的监狱中运行,因此这不是 CIFS 性能或网络问题的情况 - 数据不会离开服务器。软件所做的只是重命名到不同的目录中,但性能就像是在复制所有数据。

系统未处于任何特定负载下。我实际上已经停止了服务器上运行的其他进程,只是为了释放一些内存和 CPU,以防万一。

更新:这两个目录在监狱内的同一个挂载点上。该池是raidz1 中的4 个2TB SATA 驱动器。没有重复数据删除或压缩。

更新 2:在 fs 上禁用 atime 也没有区别(我想我不妨试试)。

更新 3:zfs/zpool 输出。

[root@Stillmatic2] ~# zpool status
  pool: jumbo1
 state: ONLINE
  scan: scrub repaired 0 in 95h19m with 0 errors on Wed Jul 16 23:20:06 2014
config:

        NAME        STATE     READ WRITE CKSUM
        jumbo1      ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            ada0    ONLINE       0     0     0
            ada1    ONLINE       0     0     0
            ada2    ONLINE       0     0     0
            ada3    ONLINE       0     0     0

errors: No known data errors

[root@Stillmatic2] ~# zfs list
NAME                                                         USED  AVAIL  REFER  MOUNTPOINT
jumbo1                                                      5.32T  21.4G  40.4K  /mnt/jumbo1
jumbo1/data                                                 76.0G  21.4G  76.0G  /mnt/jumbo1/data
jumbo1/howie                                                2.03G  21.4G  2.03G  /mnt/jumbo1/howie
jumbo1/jails                                                45.1G  21.4G   139M  /mnt/jumbo1/jails
jumbo1/jails/.warden-template-9.1-RELEASE-amd64              347M  21.4G   347M  /mnt/jumbo1/jails/.warden-template-9.1-RELEASE-amd64
jumbo1/jails/.warden-template-9.1-RELEASE-amd64-pluginjail   853M  21.4G   852M  /mnt/jumbo1/jails/.warden-template-9.1-RELEASE-amd64-pluginjail
jumbo1/jails/hj-tools                                       43.8G  21.4G  44.1G  /mnt/jumbo1/jails/hj-tools
jumbo1/movies                                               1.56T  21.4G  1.56T  /mnt/jumbo1/movies
jumbo1/music                                                1.45T  21.4G  1.45T  /mnt/jumbo1/music
jumbo1/tv                                                   2.19T  21.4G  2.19T  /mnt/jumbo1/tv
Run Code Online (Sandbox Code Playgroud)

Chr*_*s S 5

大约 6TB 中的 21GB 可用 => <1% 可用空间。ZFS 建议为 RAIDZ 提供 20% 的可用空间,并且至少 10% 是任何合理性能所必需的。您需要释放一些空间或扩展数组的大小。

侧节点:

  1. 如果您希望在进入可能的数据丢失区域之前检测到阵列故障,则需要每周清理 SATA 驱动器。看起来距离上次磨砂已经有一个月了。
  2. 由于这种工作方式,您可能仍然处于重建时阵列失败的全部百分比中。请参阅什么算作“大型”raid 5 阵列?详情。