Экстремальное замедление ZFS после нескольких месяцев

У меня есть сервер общего назначения, обеспечивая почту, DNS, сеть, базы данных и некоторые другие сервисы для многих пользователей.

Это имеет Xeon E3-1275 на уровне 3,40 ГГц, 16 ГБ RAM ECC. Выполнение ядра Linux 4.2.3, с ZFS-Linux 0.6.5.3.

Структура диска 2x диски емкостью Seagate ST32000641AS 2 и 1x Samsung 840 Pro SSD на 256 ГБ

У меня есть 2 HDs в зеркале RAID-1, и SSD действует как кэш и устройство журналирования, все управляемые в ZFS.

Когда я сначала настроил систему, это было удивительно быстро. Никакие реальные сравнительные тесты, просто... быстро.

Теперь, я замечаю экстремальное замедление, особенно в файловой системе, содержащей все maildirs. Выполнение ночного резервного копирования принимает 90 минут для всего лишь 46 ГБ почты. Иногда, резервное копирование вызывает такую экстремальную нагрузку, что система почти безразлична в течение максимум 6 часов.

Я работал zpool iostat zroot (мое объединение называют zroot) во время этого замедления и замеченных записей на порядке 100-200kbytes/sec. Нет никаких очевидных ошибок IO, диск, кажется, особенно не упорно работает, но читать, является почти неприменимо медленным.

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

Мое идущее подозрение - это: Я использую zfs-auto-snapshot для создания прокручивающихся снимков каждой файловой системы. Это создает 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 просто зависает. График: