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

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

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

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

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

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

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

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

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

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

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

Затем смонтируйте файловую систему.

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

Лучшее решение - создать иерархию каталогов, например:

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

Это не имеет значения, пока вы не достигнете предела ext3 в 32 000 имен на каталог. Обновление до ext4 может обойти это, а также другие преимущества ext4.

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

Когда вы получаете много файлов в каталоге, время открытия файла начинает страдать. Файловый ввод-вывод - нет. Также страдает время удаления файла. Однако на ext4 это не так уж и медленно. Впрочем, под ext3 это заметно. XFS и ext4 довольно быстро справляются с этим.

Когда я в последний раз смотрел на XFS и взвешивал преимущества и недостатки использования XFS по сравнению с ext4, я обнаружил сообщения о потере данных с XFS. Не уверен, что это все еще проблема или была ли она когда-либо, но я достаточно нервничал, чтобы держаться подальше. Поскольку ext4 является файловой системой по умолчанию в Ubuntu, она легко выиграла у XFS.

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

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

Преимущество ext4 в том, что вы можете смонтировать том ext3 в ext4, чтобы попробовать. Видеть: Миграция живой системы с файловой системы ext3 на ext4

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

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

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

У этого ОПРЕДЕЛЕННО будут некоторые последствия. Первичным будет чтение / запись ввода-вывода. Помимо этого, это просто очень пугающий способ работы с данными такого типа (в таком масштабе).

В прошлом я использовал 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 проводит большую часть времени.

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

Следует также отметить, что по мере увеличения количества каталогов использование кэша inode и dentry будет расти, что означает потребление большего объема оперативной памяти. Это относится к блочной памяти, поэтому, если вашему серверу не хватает памяти, это еще один момент для размышлений.

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

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

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

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