Чрезвычайные замедления ZFS после нескольких месяцев

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

У него Xeon E3-1275 с тактовой частотой 3,40 ГГц и 16 ГБ ECC RAM. Запуск ядра Linux 4.2.3, с ZFS-on-Linux 0.6.5.3.

Компоновка диска - 2 накопителя Seagate ST32000641AS 2 ТБ и 1 накопитель Samsung 840 Pro 256 ГБ SSD

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

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

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

Я запустил zpool iostat zroot(мой пул назван zroot) во время этих замедлений и видел записи порядка 100-200 Кбайт / с. Там нет очевидных ошибок ввода-вывода, диск, кажется, не работает особенно тяжело, но чтение почти невероятно медленно.

Странно то, что у меня был точно такой же опыт на другой машине, со схожим техническим оборудованием, но без 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просто зависает. График:

Посмотрите на arc_meta_used и arc_meta_limit. С большим количеством маленьких файлов вы можете заполнить кэш метаданных в оперативной памяти, чтобы он смотрел на диске информацию о файлах и мог замедлить просмотр.

Я не уверен, как это сделать на Linux, мой опыт на FreeBSD.