Как количество подкаталогов влияет на производительность чтения / записи диска в Linux?

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

Влияет ли структурирование диска со всеми этими каталогами на производительность чтения / записи диска? Влияет ли это на какой-то другой аспект производительности, о котором я не знаю?

Есть ли что-то неправильное или плохое в структурировании вещей таким образом? Возможно, просто неправильный выбор файловой системы?

Недавно я попытался объединить два диска с данными и понял, что EXT3 ограничен 32 000 подкаталогов. Это заставило меня задуматься, почему. Кажется глупым, что я построил это таким образом, учитывая, что каждый файл имеет уникальный идентификатор, который соответствует идентификатору в базе данных. Увы ...

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

Файловая система XFS лучше для этого типа структуры каталогов. ext4, наверное, сейчас просто отлично. Доступ и операции с каталогом будут просто замедляться по мере увеличения количества подкаталогов и файлов. Это очень заметно под ext3 и не так много на XFS.

Ответ не так прост, как выбор файловой системы. Разумные файловые системы давно перестали использовать линейные списки для каталогов, а это означает, что количество записей в каталоге не влияет на время доступа к файлу ....

кроме случаев, когда это так.

Фактически, каждая операция остается быстрой и эффективной независимо от количества записей, но некоторые задачи включают в себя растущее число операций. Очевидно, что простое выполнение lsзанимает много времени, и вы ничего не увидите, пока все иноды не будут прочитаны и отсортированы. Выполнение ls -U(несортированное) немного помогает, потому что вы можете видеть, что оно не мертво, но не сокращает время восприятия. Менее очевидно, что любое расширение подстановочного знака должно проверять каждое имя файла, и кажется, что в большинстве случаев весь inode также должен быть прочитан.

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

редактировать :

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

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

Например: допустим, у вас есть каталог с миллионами файлов с именами от «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 32 000 имен на один каталог. Обновление до 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.

Итак, в дополнение к предложению Тайлера, которое поможет с точки зрения управления, я предлагаю вам перейти на ext4. Ограничение на каталог составляет 64000 записей с ext4

Другое преимущество заключается в том, что время fsck значительно быстрее. У меня никогда не было проблем с коррупцией.

Хорошая вещь в ext4 заключается в том, что вы можете подключить том ext3 к ext4, чтобы попробовать. См. Миграция работающей системы из файловой системы ext3 в ext4.

Цитата из этой ссылки:

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

Итак, попробуйте и попробуйте. Предложите резервную копию в первую очередь.

Определенно будут некоторые последствия этого. Основным будет IO чтение / запись. Кроме того, это просто очень страшный способ работы с данными такого типа (в таком масштабе).

В прошлом я использовал XFS, чтобы успешно преодолеть ограничения Ext3.

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

Я видел, как администраторы регулярно запускают 'find / somepath 2> & 1> / dev / null' в cron, чтобы поддерживать активный кэш, что приводит к повышению производительности.

У меня есть несколько вопросов и некоторые возможные выводы.

Во-первых, это система 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, и, поскольку вы продолжаете создавать или получать доступ к новым или существующим файлам или каталогам внутри каталогов, время доступа будет увеличиваться. Ядро должно пересечь более обширную иерархию файловой системы, и, следовательно, это, без сомнения, накладные расходы.

Еще один момент, который стоит отметить, заключается в том, что по мере увеличения количества каталогов увеличивается использование кеша inode и dentry, что означает увеличение потребления ОЗУ. Это происходит в режиме slab-памяти, поэтому, если у вашего сервера недостаточно памяти, это еще одна мысль.

Говоря о примере из реального мира, я недавно увидел, что на сильно вложенных ext3 fs создание первого поддиректория занимает около 20 секунд, тогда как на ext4 это занимает около 4 секунд. Это потому, что распределение блоков структурировано в разных файловых системах. Если вы используете XFS или ext4, нет необходимости говорить, что вы получите некоторое повышение производительности, каким бы минимальным оно ни было.

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

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

Но если вы можете себе это позволить, вы можете проверить это.