Назад | Перейти на главную страницу

Почему производительность zfs при перемещении файлов внутри файловой системы будет плохой?

На моем NAS с FreeNAS (9.1.1 с zfs v28) я получаю ужасную производительность при перемещении файлов между двумя каталогами в одной и той же raidz fs. Ожидается ли это? Как я могу найти это, если нет?

В данном случае приложением является Beets (программа для управления файлами mp3), работающая в тюрьме на самом NAS, поэтому это не связано с производительностью CIFS или проблемами сети - данные не покидают сервер. Все программное обеспечение переименовывает в другой каталог, но производительность такая, как если бы оно копировало все данные.

Система не испытывает особой нагрузки. Я фактически остановил другие процессы, запущенные на сервере, просто чтобы освободить память и процессор, на всякий случай.

Обновлено: два каталога находятся в одной точке монтирования в тюрьме. Пул - это 4 диска SATA по 2 ТБ в raidz1. Без дедупликации или сжатия.

Обновлено 2: отключение atime на fs также не имеет значения (подумал, что я могу попробовать).

Обновление 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

21 ГБ из ~ 6 ТБ => <1% свободного пространства. ZFS рекомендует 20% свободного пространства для RAIDZ, и не менее 10% в большинстве случаев является обязательным для любой разумной производительности. Вам нужно освободить место или увеличить размер массива.

Боковые узлы:

  1. Диски SATA необходимо очищать еженедельно, если вы ожидаете обнаружить сбои массива до того, как вероятная потеря данных территория. Похоже, с последнего скраба прошел месяц.
  2. Вы, наверное, все еще в весь процент вероятность отказа массива при перестроении из-за того, как он работает. Видеть Что считается «большим» массивом рейда 5? для подробностей.