Максимальное количество файлов в одном ext3 каталоге при тихом получении приемлемой производительности?
find . -maxdepth 1 -type f -exec rm -f {} \;
это просто занимает слишком много времени (одно должностное лицо комнаты на файл).
этот намного более эффективен:
find . -maxdepth 1 -type f -print0 | xargs -r0 rm -f
поскольку это берет столько же имена файлов сколько аргумент комнате так же, это возможно, затем выполняет комнату со следующей загрузкой имен файлов... это может произойти, которым комнату только называют 2 или 3 раза.
Если у Вас есть дистрибутив, который поддерживает dir_index возможность затем у Вас может легко быть 200 000 файлов в единственном каталоге. Я сохранил бы его приблизительно в 25 000 хотя, только для сейфа. Без dir_index, попытайтесь сохранить его в 5 000.
Я предложил бы, чтобы Вы попытались тестировать различные размеры каталога с инструментом сравнительного тестирования, такие как почтовый штемпель, потому что существует много переменных как размер кэша (и в ОС и в дисковой подсистеме), которые зависят от Вашей конкретной среды.
Мое персональное эмпирическое правило состоит в том, чтобы стремиться к размеру каталога <= 20k файлы, хотя я видел относительно достойную производительность с до 100k файлов/каталога.
http://en.wikipedia.org/wiki/Ext3#Functionality - Это упоминает, что каталог может только иметь приблизительно 32 000 подкаталогов, но не упоминает о файлах.
http://roopindersingh.com/2008/05/10/ext3-handling-large-number-of-files-in-a-directory/
Кроме того, я ненавижу Exchange Экспертов, но я прочитал комментарий к этому вопросу, что это идеально, чтобы иметь меньше чем 10-15 000 на каталог.
По моему опыту, лучший подход не должен сверхпроектировать файловую структуру заранее. Как упомянуто по крайней мере в еще одном ответе, существуют расширения файловой системы, которые имеют дело с концом производительности проблемы вещей.
Проблемой, которую я поражал более часто, является удобство использования на административном конце. Наименьшее количество объема работы, который можно сделать для сокращения числа файлов в каталоге, является, вероятно, подходом, в котором Вы нуждаетесь прямо сейчас.
sqrt (3_000_000) == 1732
Пара тысячи файлов в единственном каталоге звучит разумной мне. Будьте своим собственным судьей для Вашей собственной ситуации. Для достижения этого попытайтесь разделить файлы на единственный уровень каталогов хеша так, чтобы среднее количество файлов на каталог было о том же как количество каталогов.
Учитывая Ваш пример это было бы ./a/abc.ext, ./ab/abc.ext, ./abc/abc.ext, ... .
Распространение файлов будет зависеть в большой степени от фактических имен файлов. Предположите применять эту технику к каталогу миллиона файлов каждый названный foobar???.txt. Существуют способы выполнить более ровное распространение, как хеширование на основе значения конкретного числа битов от суммы MD5 каждого имени файла, но я собираюсь сметь предполагать, что это было бы излишеством для того, что Вы пытаетесь выполнить.
Я думаю, что Вы помещаете слишком много мысли в это. Если бы Вы даже выбрали единственный дополнительный уровень каталогов и смогли сбалансировать вещи равномерно, то у Вас было бы 1732* каталоги и 1 732 файла на каталог.
Если Вы не планируете необходимость в десятках миллиардов файлов, Вы могли в значительной степени выбрать число между 1 000 и 100,000 и получить хорошие результаты.
* квадратный корень 3 миллионов.
Будьте ОЧЕНЬ осторожны при выборе разделения каталога. "a / b / c" звучит для меня как рецепт катастрофы ...
Не создавайте вслепую структуру из нескольких каталогов, скажем, 100 записей на первом уровне, 100 записей на втором уровне, 100 записей в третьем. Я был там, сделал это, получил оболочку и пришлось ее реструктурировать, когда производительность упала с несколькими миллионами файлов. : -)
У нас есть клиент, который делал макет «несколько каталогов» и в итоге помещал от одного до пяти файлов в каталог, и это их убивало. От 3 до 6 часов, чтобы сделать «ду» в этой структуре каталогов. Спасителем здесь был SSD, они не хотели переписывать эту часть своего приложения, а SSD сократили это время с часов до минут.
Проблема в том, что каждый уровень поиска в каталогах требует поиска, а поиск очень дорогостоящий. Размер каталога также является важным фактором, поэтому, если он будет меньше, а не больше, это большая победа.
Чтобы ответить на ваш вопрос о том, сколько файлов в каталоге, 1000, которые я слышал, называются "оптимальными", но производительность на 10 000 вроде бы нормально.
Итак, я бы порекомендовал один уровень каталогов, каждый из которых представляет собой каталог длиной 2 символа, состоящий из прописных и строчных букв и цифр, примерно для 3800 каталогов наверху уровень. Затем вы можете хранить 14 миллионов файлов с этими подкаталогами, содержащими 3800 файлов, или около 1000 файлов на подкаталог для файлов 3M.
Я сделал подобное изменение для другого клиента, и это имело огромное значение.
и ищет очень дорого. Размер каталога также является важным фактором, поэтому, если он будет меньше, а не больше, это большая победа.Чтобы ответить на ваш вопрос о том, сколько файлов в каталоге, 1000, которые я слышал, называются "оптимальными", но производительность на 10 000 вроде бы нормально.
Итак, я бы порекомендовал один уровень каталогов, каждый из которых представляет собой каталог длиной 2 символа, состоящий из прописных и строчных букв и цифр, примерно для 3800 каталогов наверху уровень. Затем вы можете хранить 14 миллионов файлов с этими подкаталогами, содержащими 3800 файлов, или около 1000 файлов на подкаталог для файлов 3M.
Я сделал подобное изменение для другого клиента, и это имело огромное значение.
и ищет очень дорого. Размер каталога также является важным фактором, поэтому, если он будет меньше, а не больше, это большая победа.Чтобы ответить на ваш вопрос о том, сколько файлов в каталоге, 1000, которые я слышал, называются "оптимальными", но производительность на 10 000 вроде бы нормально.
Итак, я бы порекомендовал один уровень каталогов, каждый из которых представляет собой каталог длиной 2 символа, состоящий из прописных и строчных букв и цифр, примерно для 3800 каталогов наверху уровень. Затем вы можете хранить 14 миллионов файлов с этими подкаталогами, содержащими 3800 файлов, или около 1000 файлов на подкаталог для файлов 3M.
Я сделал подобное изменение для другого клиента, и это имело огромное значение.
так что если он будет меньше, а не больше - это большая победа.Чтобы ответить на ваш вопрос о том, сколько файлов в каталоге, 1000, которые я слышал, называются "оптимальными", но производительность на уровне 10 000 кажется вполне приемлемой.
Итак, я бы рекомендовал один уровень каталогов, каждый из которых представляет собой каталог длиной 2 символа, состоящий из прописных и строчных букв и цифр, для примерно 3800 каталогов на верхнем уровне. Затем вы можете хранить 14 миллионов файлов с этими подкаталогами, содержащими 3800 файлов, или около 1000 файлов на подкаталог для файлов 3M.
Я сделал подобное изменение для другого клиента, и это имело огромное значение.
так что если он будет меньше, а не больше - это большая победа.Чтобы ответить на ваш вопрос о том, сколько файлов в каталоге, 1000, которые я слышал, называются "оптимальными", но производительность на уровне 10 000 кажется вполне приемлемой.
Итак, я бы рекомендовал один уровень каталогов, каждый из которых представляет собой каталог длиной 2 символа, состоящий из прописных и строчных букв и цифр, для примерно 3800 каталогов на верхнем уровне. Затем вы можете хранить 14 миллионов файлов с этими подкаталогами, содержащими 3800 файлов, или около 1000 файлов на подкаталог для файлов 3M.
Я сделал подобное изменение для другого клиента, и это имело огромное значение.
d рекомендует - это один уровень каталогов, каждый из которых представляет собой каталог длиной 2 символа, состоящий из прописных и строчных букв и цифр, примерно для 3800 каталогов на верхнем уровне. Затем вы можете хранить 14 миллионов файлов с этими подкаталогами, содержащими 3800 файлов, или около 1000 файлов на подкаталог для файлов 3M.Я сделал подобное изменение для другого клиента, и это имело огромное значение.
d рекомендует - это один уровень каталогов, каждый из которых представляет собой каталог длиной 2 символа, состоящий из прописных и строчных букв и цифр, примерно для 3800 каталогов на верхнем уровне. Затем вы можете хранить 14 миллионов файлов с этими подкаталогами, содержащими 3800 файлов, или около 1000 файлов на подкаталог для файлов 3M.Я сделал подобное изменение для другого клиента, и это имело огромное значение.
Хм, я недавно прочитал эту статью . По сути, вы используете распространение своего любимого алгоритма хеширования. Я начал играть с числами, подписанный MySQL INT имеет максимальное значение 2147483647. Вы также можете изменить желаемое количество файлов для каждого каталога и количество подкаталогов, чтобы установить окончательное количество подкаталогов. / files-per-directory разбивается на заданный набор данных, но трудно найти эмпирические доказательства оптимальной организации каталогов / файлов. Эта статья действительно дает некоторое представление о различиях в производительности файловых систем (некоторые интересные показатели), но ничего не об оптимальной организации.
Я могу подтвердить, что на довольно мощном сервере с большим количеством памяти при приличной нагрузке 70 000 файлов могут вызвать разного рода хаос. Я пошел, чтобы удалить папку кеша с 70k файлами в ней, и это привело к тому, что apache начал создавать новые экземпляры, пока он не достиг максимального значения 255, и система использовала всю свободную память (16 ГБ, хотя виртуальный экземпляр мог быть меньше). В любом случае, держать его ниже 25 000, вероятно, будет очень разумным шагом