У меня есть аналогичная (хотя и меньшая) установка с 12 дисками по 2 ТБ в массиве RAID6, которые используются для той же цели (rsnapshot резервный сервер).

Во-первых, это нормально для du -hs уделять так много времени такой большой и используемой файловой системе. более того du учитывает жесткие ссылки, которые вызывают значительную и резкую загрузку ЦП в дополнение к очевидной нагрузке ввода-вывода.

Ваша медлительность связана с тем, что метаданные файловой системы расположены в очень удаленных (в терминах LBA) блоках, что вызывает много запросов. Поскольку обычный диск со скоростью вращения 7,2 КБ обеспечивает около 100 операций ввода-вывода в секунду, вы можете увидеть, сколько часов, если не дней, необходимо для загрузки всех метаданных.

Что-то, что вы можете попробовать (неразрушающим образом) улучшить ситуацию:

• обязательно не имея mlocate/slocate индексация вашего /backup-root/ (вы можете использовать предприятие Prunefs чтобы избежать этого), иначе удаление кэша метаданных серьезно снизит время резервного копирования;
• по той же причине избегайте бега du на /backup-root/. При необходимости запустите du только в конкретной интересующей подпапке;
• ниже vfs_cache_pressure от значения по умолчанию (100) до более консервативного (10 или 20). Это укажет ядру отдать предпочтение кэшированию метаданных, а не кэшированию данных; это, в свою очередь, должно ускорить rsnapshot/rsync фаза открытия;
• вы можете попробовать добавить устройство кэширования метаданных с возможностью записи, например, через lvmcache или bcache. Этим устройством метаданных, очевидно, должен быть SSD;
• увеличьте доступную оперативную память.
• поскольку вы используете ext4, помните о проблемах с распределением inode (прочтите Вот для примера). Это не связано напрямую с производительностью, но это важный фактор, когда в файловой системе на основе ext имеется так много файлов.

Вы можете попробовать и другие вещи, но это разрушительные операции:

• используйте XFS с обоими -ftype и -finobt набор опций;
• использовать ZFS в Linux (ZoL) со сжатым ARC и primarycache=metadata настройка (и, возможно, L2ARC для кеша только для чтения).

Эта файловая система хранит огромное количество небольших файлов с очень большим количеством операций SEEK, но с низкой пропускной способностью ввода-вывода.

🎉

Это то, что сейчас привлекает множество людей. Увы, обычные FS здесь плохо масштабируются. Я могу дать вам, наверное, всего несколько советов, когда дело доходит до уже имеющейся настройки: EXT4 через RAID-6 на жестких дисках:

1. Нижняя vm.vfs_cache_pressure вниз, скажем 1. Это было бы изменить предвзятость кеширования к сохранению большего количества метаданных (inode, dentry) вместо самих данных, и это должно иметь положительный эффект в сокращении количества поисков
2. Добавить больше RAM. Хотя это может показаться странным для сервера, на котором не работают какие-либо копилки, помните: единственный способ уменьшить количество запросов - хранить больше метаданных в более быстром хранилище, учитывая, что у вас есть только 16 ГБ, кажется, что это должно быть относительно легко увеличить объем оперативной памяти
3. Как я уже сказал, EXT4 - не лучший выбор для вашего варианта использования, но все же вы можете использовать некоторые из его функций, чтобы облегчить боль:
   • внешний журнал поддерживается, поэтому вы можете попробовать добавить SSD (лучше зеркальный) и разместить там журнал. Проверять, выписываться "ext4: предупреждения о внешнем журнале"
   • Попробуйте переключиться режим журнала к "ведению журнала всех данных" монтаж с data=journal
4. Пытаться перемещение файлов за пределы единой области FS. Для е. g., если у вас здесь LVM-2, вы можете создавать тома меньшего размера и использовать их какое-то время, затем, когда он заполнится, создайте еще один и так далее.
   • Если у вас нет LVM-2, вы можете попробовать сделать это с помощью / dev / loop, но это не так удобно и, вероятно, менее производительно.

UPD.: так как оказалось Программный RAID Linux (LSR) RAID-6, вот дополнительный элемент:

5. LSR имеет собственные параметры настройки, которые многие люди, кажется, упускают из виду.
   • Полосовой кеш, который может быть установлен таким образом на максимум: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size - Но делайте это осторожно (при необходимости используйте меньшее значение), так как размер кратен размеру блока и в зависимости от выбранного размера блока потребуется разный объем ОЗУ.
   • Внешний журнал, который также может находиться на этих зеркальных SSD (но в настоящее время MD-устройство, созданное без журнала, не может быть преобразовано для использования одного).

- Это, наверное, большая часть того, что можно улучшить без редизайна с нуля.

У меня очень низкая производительность, так как файловая система (нетто 60 ТБ) превысила 50% использования. На данный момент загрузка составляет 75%

Это очень серьезная проблема, потому что высокий уровень занятости дискового пространства только усугубляет фрагментацию. А чем больше фрагментация, тем больше поисков. Не удивительно, почему он давал более или менее приемлемую производительность до достижения 50%. Во многих руководствах есть четкие рекомендации, чтобы ФБК не разрастались ниже 75–80%.

В этом случае RAID6 не особо поможет, что-то вроде ZFS может обеспечить гораздо более быстрый доступ к метаданным и каталогам при сохранении примерно такой же скорости.

RAID-6 чередует диски, поэтому весь ввод-вывод идет на все диски. Это довольно неэффективно для множества небольших файлов. Однако, вероятно, это не ваша главная проблема, которая ...

Ext4 не очень подходит для больших файловых систем с миллионами файлов. Использовать XFS. У меня есть файловые системы XFS размером до 1,2 ПБ и с 1 миллиардом файлов, без проблем. Просто используйте XFS.

Спасибо всем, кто ответил на мой вопрос.

Вот как я это решил:

Первым делом я добавил на плату максимальный объем оперативной памяти. К сожалению, плата поддерживает только до 64 ГБ оперативной памяти. Я наблюдал за поведением после расширения, и оно меня разочаровало. Хотя вся доступная оперативная память использовалась для кэша ввода-вывода, производительность RSNAPSHOT-Backup заметно не улучшилась.

Так что мне пришлось вытащить большую булаву. Я добавил два диска NVME емкостью 1 ТБ и собрал их в RAID 1. RAID 6, состоящий из 8 жестких дисков по 10 ТБ, был разобран на один RAID 1 (состоящий из 2 жестких дисков по 10 ТБ, ext4) и один RAID 5 (состоящий из 6 жестких дисков по 10 ТБ). RAID 1 теперь содержит операционную систему и рабочую копию серверов (которые загружаются на этот диск 4 раза в день).

RAID5 теперь является устройством с поддержкой BCACHE, поддерживаемым NVME-RAID 1 и отформатированным с помощью ext4. На этом диске находятся копии RSNAPSHOT. Каждую ночь файлы синхронизируются с RAID1 на RAID5, что снижает вдвое пропускную способность ввода-вывода RAID5 по сравнению с предыдущим RAID6, который содержал рабочие копии И резервные копии. Благодаря BCache не буквально каждый файл записывается на диски, но все изменения в одном блоке записываются один раз, даже если он содержит несколько сотен изменений одного файла. Это еще больше снизило количество операций ввода-вывода на жестких дисках.

Наконец, я изменил конфигурацию RSnapshot. Раньше было 31 ежедневный снимок и 18 ежемесячных снимков, в результате чего было создано 49 резервных копий. Теперь у меня есть классический дизайн 7d / 4w / 12m / 1y, который сокращает количество генераций резервных копий до 24.

После этих изменений (и с 64 ГБ ОЗУ, упомянутой выше) продолжительность одного снимка снизилась с ~ 20 часов до 1,5 часов. Уровень попадания в кэш-память устройств BCache составляет 82% (после 6 недель нормальной работы).

Миссия выполнена. Спасибо всем за ваши мысли и вклад.