У меня есть универсальный сервер, предоставляющий почту, 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.