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

Чрезвычайное замедление работы 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 ГБ.

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

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

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

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

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

Мое подозрение таково: я использую zfs-auto-снимок для создания скользящих снимков каждой файловой системы. Он создает 15-минутные, ежечасные, ежедневные и ежемесячные снимки и хранит определенное количество каждого снимка, удаляя самые старые. Это означает, что с течением времени в каждой файловой системе были созданы и уничтожены тысячи снимков. Это единственная текущая операция на уровне файловой системы, о которой я могу думать с кумулятивным эффектом. Я попытался уничтожить все снимки (но продолжал процесс, создавая новые) и не заметил никаких изменений.

Есть ли проблема с постоянным созданием и уничтожением снимков? Я считаю их чрезвычайно ценным инструментом, и меня заставили поверить, что они (помимо дискового пространства) более или менее бесплатны.

Есть ли что-то еще, что может вызвать эту проблему?

EDIT: вывод команды

Выход 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.