У мене є сервер резервного копіювання Ubuntu 16.04 з 8x10TB HDD через платформу SATA 3.0. 8 жорстких дисків зібрані в RAID6, використовується файлова система EXT4. Ця файлова система зберігає величезну кількість невеликих файлів з дуже багатьма операціями SEEK, але з низькою пропускною здатністю IO. Насправді існує багато невеликих файлів з різних серверів, які отримують знімок щодня через rsnapshot (кілька INODES безпосередньо в одних і тих же файлах. У мене дуже низька продуктивність, оскільки файлова система (60TB нетто) перевищила 50% використання. На даний момент використання становить 75% та а

du -sch /backup-root/

займає кілька днів (!). Машина має 8 ядер і 16G оперативної пам’яті. Оперативну пам’ять повністю використовує кеш файлової системи ОС, 7 з 8 ядер завжди простоюють через IOWAIT.

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припадає на жорсткі посилання, які спричиняють значне та бурхливе завантаження процесора на додаток до очевидного навантаження на IO.

Ваша повільність пояснюється тим, що метадані файлової системи розташовуються у дуже віддалених (в LBA термінах) блоках, що викликає багато пошуків. Як звичайний 7,2 Кб RPM диск забезпечує приблизно ~ 100 IOPS, ви можете бачити, скільки годин, якщо не днів, потрібно для завантаження всіх метаданих.

Щось, що ви можете спробувати (неруйнівно) покращити ситуацію:

• бути впевнені, що НЕ маючи mlocate/slocateіндексувати ваш /backup-root/(ви можете використовувати об'єкт prunefs , щоб уникнути цього), або метадані кеша громити будуть severly погіршувати ваш час резервного копіювання;
• з тієї ж причини, уникати працює 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, але з низькою пропускною здатністю IO.

🎉

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

1. Опустіться vm.vfs_cache_pressureвниз, скажіть на 1. Це змінить зміщення кешування керування в бік збереження більше метаданих (inode, dentry) замість самих даних, і це має позитивно вплинути на зменшення кількості запитів
2. Додайте більше оперативної пам’яті . Хоча це може здатися дивним для сервера, який не запускає жодних додатків із скарбничками, пам’ятайте: єдиний спосіб зменшити прагнення - зберегти більше метаданих у більш швидкому зберіганні, враховуючи, що у вас є 16 ГБ, тільки здається, що це слід порівняно легко збільшити кількість оперативної пам’яті
3. Як я вже говорив, EXT4 не є найкращим вибором для вашої справи використання, але все ж ви можете використовувати деякі функції, які він створює, щоб заспокоїти біль:
   • зовнішній журнал підтримується, тому ви можете спробувати додати SSD (краще дзеркальний) та розмістити журнал там. Перевірте " ext4: зовнішні застереження журналу "
   • Спробуйте переключити режим журналу на встановлення "всіх даних, що перебувають у дорозі"data=journal
4. Спробуйте перемістити файли за межами однієї області FS . Наприклад, якщо у вас тут LVM-2, ви можете створювати томи меншого розміру та використовувати їх на час, тоді, коли він заповниться, створіть ще один тощо.
   • Якщо у вас немає LVM-2, ви можете спробувати це зробити з / dev / loop, але це не так зручно і, мабуть, менш ефективно

UPD. : оскільки виявилося, що це RAID-6 Linux Software (LSR), тут йде додатковий пункт:

5. LSR має власні параметри настройки, які, здається, багато людей не помічають
   • Кеш смуги , який можна встановити таким чином на максимум: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- Але робіть це обережно (використовуйте менше значення, якщо потрібно), оскільки розмір розміру красний, а залежно від вибраного вами розміру, він займе різну кількість оперативної пам'яті
   • Зовнішній журнал, який також може бути на цих дзеркальних SSD ( але в даний час MD-пристрій, створений без журналу, не може бути перетворений для його використання ).

- Це, мабуть, більшість того, що можна вдосконалити без переробки дизайну.

У мене дуже низька продуктивність, оскільки файлова система (60TB нетто) перевищила 50% використання. На даний момент використання становить 75%

Це дуже серйозне питання, оскільки високий рівень зайнятості дискового простору лише погіршує фрагментацію. А більше роздробленості означає більше прагнень. Більше не дивуйтеся, чому це дало більш-менш прийнятні показники, перш ніж досягти 50%. Багато посібників мають чіткі рекомендації, щоб не дозволяти FSes зростати на відстані 75—80%.

RAID6 не дуже допомагає вам у цьому випадку, щось подібне ZFS може забезпечити набагато швидший метадані та доступ до каталогу, зберігаючи приблизно однакові швидкості.

RAID-6 смуги накопичувачів, тому весь IO йде на всі диски. Це дуже неефективно з багатьма невеликими файлами. Однак це, мабуть, не ваша основна проблема, яка ...

Ext4 не дуже підходить для великих файлових систем з мільйонами файлів. Використовуйте XFS . У мене файлові системи XFS працюють на рівні 1,2 PB і з 1 мільярдом файлів, без проблем. Просто використовуйте XFS .

Дякую всім, хто дав відповідь на моє запитання.

Ось як я це вирішив:

Перш за все, я додав максимальну кількість оперативної пам’яті до плати. На жаль, плата підтримує лише 64 Гб оперативної пам’яті. Я спостерігав за поведінкою після розширення, і це було невтішно. Хоча вся доступна оперативна пам’ять була використана для кешу IO, продуктивність RSNAPSHOT-резервного копіювання не покращилася.

Тож довелося тягнути велику булаву. Я додав два диски NVME 1 Тб і зібрав їх на RAID 1. RAID 6, що складається з 8x 10TB жорстких дисків, розібрали на один RAID 1 (що складається з 2x 10TB HDD, ext4) і один RAID 5 (що складається з 6x10TB HDD). Тепер RAID 1 містить Операційну систему та робочу копію Серверів (які на цей накопичувач 4 рази на день перебувають у стилі синхронізації).

Тепер RAID5 - це пристрій, підтримуваний BCACHE, підкріплений NVME-RAID 1 і відформатований з ext4. Цей привід містить RSNAPSHOT-копії. Щовечора файли перетворюються з RID1 на RAID5, що вдвічі зменшує пропускну здатність IO RAID5 порівняно з колишнім RAID6, який містив робочі копії та резервні знімки. Завдяки BCache, буквально не кожен файл записується на Диски, але всі зміни в одному Блоку записуються один раз, навіть якщо він містить кілька змін одного файлу. Це ще більше знизило IOps на жорстких дисках.

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

Після цих змін (і при згадуванні вище оперативної пам’яті на 64 ГБ) тривалість одного знімка зменшилася з ~ 20 годин до 1,5 години. Пристрої BCache мають коефіцієнт кеш-хітів 82% (після 6 тижнів регулярної роботи).

Місія виконана. Дякую усім вам за ваші думки та внесок.