Вопросы Теги

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

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

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

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

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

Обновленный 2: отключение 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
4
задан 12 August 2014 в 00:08
1 ответ

21GB из ~6TB available => <1% Freespace. ZFS рекомендует 20% свободного пространства для RAIDZ, и по крайней мере 10% является обязательным для любой разумной производительности. Необходимо освободить некоторое пространство или расширить размер массива.

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

  1. SATA диски необходимо чистить еженедельно, если вы ожидаете обнаружить сбои в массиве до того, как вы попадете в территорию вероятно data-loss. Похоже, с момента последней очистки прошёл уже месяц.
  2. Вероятно, вы всё ещё имеете целые проценты шансов на сбой массива при восстановлении из-за того, как это работает. Смотрите Что считается "большим" массивом рейда 5? для подробностей.
5
ответ дан 3 December 2019 в 03:17

Теги

Похожие вопросы