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

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

Файловая система 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

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

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

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

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

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

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

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

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

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

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

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

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