У меня есть Ubuntu 16.04 Backup Server с жестким диском 8x10 ТБ через объединительную плату SATA 3.0. 8 жестких дисков собраны на RAID6, используется файловая система EXT4. Эта файловая система хранит огромное количество небольших файлов с очень большим количеством операций SEEK, но низкой пропускной способностью ввода-вывода. На самом деле существует множество небольших файлов с разных серверов, которые каждый день получают снимки snappshot с помощью rsnapshot (несколько INODES направляются к одним и тем же файлам. У меня очень низкая производительность, поскольку файловая система (60 ТБ) превысила 50%. В настоящее время использование на 75% и

du -sch /backup-root/

занимает несколько дней (!). Машина имеет 8 ядер и 16 ГБ оперативной памяти. ОЗУ полностью используется кэшем файловой системы ОС, из-за IOWAIT 7 из 8 ядер постоянно простаивают.

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              912203776
Block count:              14595257856
Reserved block count:     0
Free blocks:              4916228709
Free inodes:              793935052
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Wed May 31 21:47:22 2017
Last mount time:          Sat Apr 14 18:48:25 2018
Last write time:          Sat Apr 14 18:48:18 2018
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed May 31 21:47:22 2017
Check interval:           0 (<none>)
Lifetime writes:          152 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       513933330
Default directory hash:   half_md4
Directory Hash Seed:      5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00c0b9d5
Journal start:            30179

Мне не хватает опыта работы с такого рода файловой системой. Какие варианты я должен настроить это. Какая файловая система будет работать лучше в этом сценарии? Есть ли варианты задействовать ОЗУ для других вариантов кэширования, кроме встроенной ОС?

Как вы обрабатываете очень большие объемы небольших файлов на больших сборках RAID?

Спасибо Себастьян

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

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

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

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

• быть уверены, что не имея mlocate/slocateиндексировать ваш /backup-root/(вы можете использовать объект prunefs , чтобы избежать этого), или метаданные кэша громить будут severly ухудшать ваше время резервного копирования;
• по той же причине, избегайте бежать duдальше /backup-root/. При необходимости запускайте duтолько в определенной интересующей подпапке;
• ниже vfs_cache_pressureзначения по умолчанию (100) до более консервативного (10 или 20). Это заставит ядро ​​отдавать предпочтение кэшированию метаданных, а не кэшированию данных; это, в свою очередь, должно ускорить rsnapshot/rsyncфазу обнаружения;
• вы можете попробовать добавить writethrough устройства кэширования метаданных, например , через 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. Было бы изменить уклон кэширования на сохранении больше метаданных (инода, dentry) вместо данных себя , и она должна иметь положительное влияние на сокращение числа испрашивает
2. Добавьте больше оперативной памяти . Хотя это может показаться странным для сервера, на котором не запускаются какие-либо непонятные приложения, помните: единственный способ уменьшить количество запросов - это сохранить больше метаданных в более быстром хранилище, учитывая, что у вас есть только 16 ГБ, но кажется, что это должно быть относительно легко увеличить объем оперативной памяти
3. Как я уже сказал, EXT4 не является хорошим выбором для вашего варианта использования, но вы все равно можете использовать некоторые функции, которые он создает для облегчения боли:
   • поддерживается внешний журнал, так что вы можете попробовать добавить SSD (лучше с зеркалом) и поместить журнал туда. Проверьте " ext4: внешние предупреждения журнала "
   • Попробуйте переключить режим журнала в режим «все данные регистрируются» с помощьюdata=journal
4. Попробуйте переместить файлы за пределы одной области видимости . Например, если у вас есть LVM-2, вы можете создавать тома меньшего размера и использовать их какое-то время, затем, когда он заполнится, создать еще один и так далее.
   • Если у вас нет LVM-2, вы можете попробовать сделать это с / dev / loop, но это не так удобно и, вероятно, менее производительно

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

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

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

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

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

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

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

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

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

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

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

Поэтому мне пришлось вытащить большую булаву. Я добавил два 1 ТБ диска NVME и собрал их в RAID 1. RAID 6, состоящий из 8x 10 ТБ жестких дисков, был разобран на один RAID 1 (состоящий из 2x 10 ТБ жестких дисков, ext4) и один RAID 5 (состоящий из 6x10 ТБ жестких дисков). 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 недель обычной работы).

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