Максимальное количество файлов в одном каталоге ext3 при сохранении приемлемой производительности?

Будьте ОЧЕНЬ осторожны при выборе разделенного каталога. "A / B / C" звучит как рецепт катастрофы для меня...

Не надо слепо делать несколько глубоких структур каталогов, скажем, 100 записей на первом уровне, 100 записей на втором уровне, 100 записей на третьем. Я был там, сделал это, получил оболочку и должен был ее реструктурировать, когда производительность пошла в крэп с несколькими миллионами файлов.:-)

У нас есть клиент, который выполнил макет "несколько каталогов" и в итоге поместил от одного до пяти файлов в каталог, и это убило их. От 3 до 6 часов, чтобы сделать "ду" в этой структуре каталогов. Спасителем здесь был SSD, они не хотели переписывать эту часть своего приложения, и SSD сократил это время с часов до минут.

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

Чтобы ответить на ваш вопрос о том, сколько файлов в каталоге, 1000, о которых я слышал, говорили, что они "оптимальны", но производительность при 10000 кажется хорошей.

Итак, я бы порекомендовал один уровень каталогов, каждый из которых представляет собой каталог длиной 2 символа, состоящий из прописных и строчных букв и цифр, для примерно 3800 каталогов на верхнем уровне. Затем вы можете хранить 14M файлов в этих подкаталогах, содержащих 3800 файлов, или около 1000 файлов в подкаталоге для файлов 3M.

Я сделал подобное изменение для другого клиента, и это имело огромное значение.

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

Мое личное правило - стремиться к размеру каталога <= 20 тыс. Файлов, хотя я видел относительно приличную производительность до 100 тыс. Файлов / каталог.

У меня все файлы идут в папках вроде:

добавления /[дата]/[час]/yo.png

и не имеет никаких проблем с производительностью.

http://en.wikipedia.org/wiki/Ext3 - здесь упоминается, что каталог может содержать только приблизительно 32000 подкаталогов, но не упоминаются файлы.

http://roopindersingh.com/2008/05/10/ext3-handling-large-number-of-files-in-a-directory/

Кроме того, я ненавижу Experts Exchange, но читаю комментарий по этому вопросу, что идеально иметь менее 10-15 000 на каталог.

На довольно мощном сервере с достаточным объемом памяти при приличной нагрузке я могу подтвердить, что 70000 файлов могут вызвать разного рода разрушения. Я пошел, чтобы удалить папку кеша с 70k-файлами в ней, и это заставило apache начать порождать новые экземпляры, пока она не превысила 255, и система использовала всю свободную память (16 ГБ, хотя виртуальный экземпляр мог быть меньше). В любом случае, держать его под 25000, вероятно, очень разумный шаг

Хм, я недавно прочитал эту статью. По сути, вы используете распределение вашего любимого алгоритма хеширования. Я начал играть с числами, максимальное значение INT, подписанное MySQL, равно 2147483647. Вы также можете варьировать желаемое количество файлов в каталоге и количество подкаталогов, чтобы установить окончательное количество подкаталогов /files- разделение на каталоги для данного набора данных, но трудно найти эмпирические доказательства оптимальной организации каталогов / файлов. Эта статья дает некоторое представление о различиях в производительности между файловыми системами (некоторые интересные метрики), но ничего об оптимальных организациях.

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

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

sqrt (3_000_000) == 1732

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

Учитывая ваш пример это будет ./a/abc.ext, ./ab/abc.ext, ./abc/abc.ext...

Распространение файлов будет сильно зависеть от фактических имен файлов. Представьте себе, что вы применяете эту технику к каталогу из миллиона файлов, каждый из которых называется foobar???.txt, Существуют способы добиться более равномерного распределения, например, хэширование на основе значения определенного количества битов из суммы MD5 каждого имени файла, но я рискну предположить, что это будет излишним для того, что вы пытаетесь выполнить.

Я думаю, вы слишком много об этом думаете. Если бы вы даже выбрали один дополнительный уровень каталогов и смогли сбалансировать вещи равномерно, у вас было бы 1732* каталогов и 1732 файла на каталог.

Если вы не планируете использовать десятки миллиардов файлов, вы можете выбрать число от 1000 до 100 000 и получить хорошие результаты.

* квадратный корень из 3 миллионов.