Як кількість підкаталогів впливає на ефективність читання / запису диска в Linux?

У мене накопичений формат EXT3 на сервері Linux CentOS Linux. Це привід даних веб-додатків і містить каталог для кожного облікового запису користувача (є 25 000 користувачів). Кожна папка містить файли, які завантажив цей користувач. Загалом цей накопичувач має приблизно 250 ГБ даних.

Чи впливає структурування накопичувача з усіма цими каталогами на ефективність читання / запису диска? Чи впливає це на якийсь інший аспект ефективності, про який я не знаю?

Чи є щось по суті неправильне чи погане в структуруванні речей таким чином? Можливо, просто неправильний вибір файлової системи?

Нещодавно я спробував об'єднати два накопичувачі даних і зрозумів, що EXT3 обмежений 32 000 підкаталогами. Це мене здивувало, чому. Думає, що я створив це таким чином, враховуючи, що кожен файл має унікальний ідентифікатор, який відповідає ідентифікатору в базі даних. На жаль ...

Це легко перевірити варіанти для себе, у своєму оточенні та порівняти результати. Так, негативний вплив на продуктивність збільшується, оскільки кількість каталогів збільшується. Так, інші файлові системи можуть допомогти обійти ці бар'єри або зменшити вплив.

Файлова система XFS краще для цього типу структури каталогів. ext4, напевно, зараз добре. Доступ та операції в каталозі просто сповільнюватимуться, коли кількість підкаталогів та файлів збільшуватиметься. Це дуже яскраво виражено в ext3 і не так сильно на XFS.

Відповідь не такий простий, як вибір файлової системи. Здорові файлові системи перестали використовувати лінійні списки для каталогів, це означає, що кількість записів у каталозі не впливає на час доступу до файлів ....

за винятком випадків, коли це відбувається.

Насправді кожна операція залишається швидкою та ефективною незалежно від кількості записів, але деякі завдання передбачають зростаючу кількість операцій. Очевидно, що робити просто lsпотрібно багато часу, і ви нічого не бачите, доки всі вставки не будуть прочитані та відсортовані. Робота ls -U(несорті) допомагає трохи, тому що ви можете бачити, що вона не мертва, але не скорочує часу. Менш очевидним є те, що будь-яке розширення підстановки має перевіряти кожне ім'я файлу, і, здається, у більшості випадків потрібно читати і всю індею.

Коротше кажучи: якщо ви можете бути впевнені, що жодна програма (включаючи доступ до оболонки) ніколи не використовуватиме жоден wildard, то ви можете отримати величезні каталоги без будь-яких покаянь. Але якщо в коді можуть ховатися якісь підстановки, краще тримайте каталоги нижче тисячі записів у кожній.

редагувати :

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

Але більшість додатків не виконують лише одноопераційні операції. Більшість з них буде виконувати або повний каталог, або підстановку підстановок. Вони повільні, незважаючи ні на що, адже вони передбачають читання всіх записів.

Наприклад: скажімо, у вас є каталог з мільйоном файлів під назвою 'foo-000000.txt' через 'foo-999999.txt' і одним 'natalieportman.jpeg'. Це буде швидко:

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

вони не зможуть, але теж швидко провалюються:

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

вони будуть повільними, навіть якщо вони дадуть дуже мало результатів; навіть ті, які не вдається, виходять з ладу після сканування всіх записів:

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

Спочатку переконайтеся, що на розділі ext3 встановлено dir_indexпрапор.

sudo dumpe2fs /dev/sdaX |grep --color dir_index

Якщо він відсутній, ви можете ввімкнути його. Вам потрібно відключити файлову систему та виконати:

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

Потім змонтуйте файлову систему.

Це не має ніякої різниці, поки ви не натиснете на ext3 32000 імен на ліміт каталогу. Оновлення до ext4 може обійти це, як і інші переваги, які має ext4.

Чим більше записів (файлів і файлів) у вас в одному каталозі, тим повільніше буде доступ. Це справедливо для кожної файлової системи, хоча деякі гірші за інші.

Краще рішення - створити ієрархію каталогів, як це:

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

І якщо вам все ж потрібні кращі показники, ви можете розширити кілька рівнів:

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

Більшість поштових систем використовують цей трюк у файлах черги пошти.

Крім того, я виявив, що з деякими файловими системами, лише маючи в минулому багато записів у каталозі, доступ до цього каталогу буде повільним. Зробіть ls -ldв каталозі, щоб побачити розмір самого запису в каталозі. Якщо це декілька Мб або більше, а каталог відносно порожній, то, можливо, ви отримуєте низьку продуктивність. Перейменуйте каталог у вихідний спосіб, створіть новий з тим самим іменем та дозволами та правом власності, а потім перемістіть вміст старого каталогу в новий. Я багато разів використовував цей трюк, щоб значно пришвидшити поштові сервери, які уповільнила файлова система.

Нещодавно я розробив сервер зберігання, який потребував створення десятків мільйонів файлів і сотень тисяч каталогів. Я порівнював XFS з ext4 та reiserfs. Я виявив, що в моєму випадку ext4 був трохи швидшим, ніж XFS. Райзер був цікавий, але мав обмеження, тому його відмовили. Я також виявив, що ext4 був значно швидшим, ніж ext3.

Коли ви отримуєте багато файлів у каталозі, час відкриття файлів починає страждати. Файлового вводу / виводу немає. Час видалення файлів також страждає. Однак це не надто повільно на ext4. Хоча це досить помітно під ext3. XFS і ext4 досить швидко в цьому.

Коли я востаннє переглядав XFS і зважував переваги та недоліки використання XFS над ext4, я знайшов повідомлення про втрату даних за допомогою XFS. Я не впевнений, що це все-таки проблема або якщо вона колись була, але це змусило мене нервувати, щоб зрозуміти. Оскільки ext4 є Fs за замовчуванням в Ubuntu, він легко виграв XFS.

Отже, на додаток до пропозицій tylerl, які допоможуть з точки зору управління, я пропоную вам оновити до ext4. Ліміт на одну директорію - 64000 записів із ext4

Ще одна перевага - час fsck значно швидше. У мене ніколи не було проблем з корупцією.

Приємна річ у ext4 - це те, що ви можете змонтувати том ext3 до ext4, щоб спробувати. Див.: Міграція живої системи з файлової системи ext3 на ext4

Цитата з цього посилання:

Якщо на вас не впливають обмеження ext3 і ви не бажаєте ризикувати, можливо, це не варто. З іншого боку, після успішного завершення процедури міграції ваша система може працювати швидше, відчувати скорочені перевірки файлової системи та підвищувати надійність без негативних наслідків.

Отже, продовжуйте і спробуйте. Запропонуйте створити резервну копію спочатку

ВИСТАВЛЕНО буде певні наслідки цього. Основним буде IO читання / запис. Крім того, це просто дуже страшний спосіб поводження з таким типом даних (у такому масштабі).

Раніше я використовував XFS, щоб успішно обійти межі Ext3.

Перший перелік вмісту файлових систем займе певний час, поки система не прочитає всю інформацію про каталог / файл. Додаткові операції пройдуть швидше, оскільки ядро ​​тепер має кешовану інформацію.

Я бачив, як адміністратори регулярно виконують керування "find / somepath 2> & 1> / dev / null", щоб підтримувати кеш-пам'ять активними, що призводить до кращої продуктивності.

У мене є деякі питання та кілька можливих висновків із вузьких місць.

По-перше, це система CentOS 5 або 6? Тому що в 6 ми маємо неймовірний інструмент під назвою blktrace, який ідеально підходить для вимірювання впливу в подібних ситуаціях.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

Тоді ми можемо проаналізувати вихідні дані з btt і знайти місце, де вузьке місце, додаток, файлова система, планувальник, зберігання - на який компонент IO витрачає більшу частину часу.

Тепер, теоретично підійшовши до вашого питання, це, очевидно, збільшить кількість входів, і коли ви продовжуватимете створювати або отримувати доступ до нових або існуючих файлів або каталогів всередині каталогів, час доступу збільшуватиметься. Ядро має пройти більш обширну ієрархію файлової системи, а отже, без сумніву, є накладними.

Ще один момент, який слід зазначити, що при збільшенні кількості каталогів використання кеш-пам'яті inode та зубних рядів збільшиться, що означає споживання більшої кількості оперативної пам'яті. Це підпадає під пам'ять, але якщо ваш сервер втрачає пам'ять, це ще одна думка.

Говорячи про приклад із реального світу, я нещодавно побачив, що на сильно вкладеному ext3 fs, створення субдірера вперше займає близько 20 секунд, тоді як для ext4 - це займає близько 4 секунд. Це тому, як структурується розподіл блоків у різних файлових системах. Якщо ви використовуєте XFS або ext4, не потрібно говорити про те, що ви отримаєте деяке підвищення продуктивності, як би це не було мінімально.

Отже, якщо ви просто запитуєте, який правильний вибір файлової системи, ext3 трохи застаріла. Це все, що я можу запропонувати без додаткових даних та орієнтиру.

Це не варіант для CentOS 5, і не впевнений, наскільки це варіант на CentOS 6, але я маю відчуття, що рішення на базі дерева B або B * дерева, тобто BTRFS забезпечить стабільну, якщо не значно кращу ефективність у вашому конкретному випадку Сценарій, якби тільки хтось міг довірити його дорогоцінні дані з чистою совістю (я все одно не хотів).

Але якщо ви можете собі це дозволити, ви можете це протестувати.