у меня было более 8 миллионов файлов в одной директории и ext3. файл libc readdir() используется find, ls и большинство других методов, обсуждаемых в этом потоке, чтобы перечислить большие каталоги.

причина ls и find медленны в этом случае это readdir() только читает 32K записей каталога за раз, поэтому на медленных дисках потребуется много много чтений, чтобы перечислить каталог. Есть решение этой проблемы скорости. Я написал довольно подробную статью об этом at: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with-ls/

ключ отнять: использовать getdents() непосредственно -- http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html вместо всего, что основано на libc readdir() Так можно указать размер буфера при чтении записей каталога с диска.

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

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

существует ограничение на общее количество файлов в одном каталоге. Кажется, я помню, что он определенно работает до 32000 файлов.

У меня есть каталог с 88,914 файлами в нем. Как ты это используется для хранения эскизов и на сервере Linux.

перечисленные файлы через FTP или функцию php медленно да, но есть также Хит производительности при отображении файла. например www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg имеет время ожидания 200-400 мс. В качестве сравнения на другом сайте у меня есть около 100 файлов в каталоге, изображение отображается после всего ~40 мс ожидания.

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

имейте в виду, что в Linux, если у вас есть каталог со слишком большим количеством файлов, оболочка не сможет развернуть подстановочные знаки. У меня есть эта проблема с фотоальбомом, размещенным на Linux. Он хранит все измененные изображения в одном каталоге. Хотя файловая система может обрабатывать много файлов, оболочка не может. Пример:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

или

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

Я работаю над аналогичной проблемой прямо сейчас. Мы имеем иерархическую структуру каталогов и используем идентификаторы изображений в качестве имен файлов. Например, изображение с id=1234567 расположенный в

..../45/67/1234567_<...>.jpg

используя последние 4 цифры, чтобы определить, куда идет файл.

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

для чего это стоит, я только что создал каталог на ext4 файловая система с 1 000 000 файлов в нем, а затем случайным образом получить доступ к этим файлам через веб-сервер. Я не заметил никакой премии за доступ к ним (скажем), только с 10 файлами.

Это кардинально отличается от моего опыта, делает это ntfs несколько лет назад.

самая большая проблема с которой я столкнулся на 32-битной системе. Как только вы передадите определенное число, такие инструменты, как "ls", перестанут работать.

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

Это действительно зависит от используемой файловой системы, а также некоторые флаги.

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

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

Это абсолютно зависит от файловой системы. Многие современные файловые системы используют приличные структуры данных для хранения содержимого каталогов, но старые файловые системы часто просто добавляют записи в список, поэтому получение файла было операцией O(n).

даже если файловая система делает это правильно, по-прежнему абсолютно возможно, что программы, которые перечисляют содержимое каталога, испортят и сделают сортировку O(n^2), поэтому, чтобы быть в безопасности, я бы всегда ограничивал количество файлов в каталоге не более чем 500.

вопрос сводится к тому, что вы собираетесь делать с файлами.

под Windows любой каталог с более чем 2K файлами имеет тенденцию медленно открываться для меня в Проводнике. Если это все файлы изображений, более 1k, как правило, открываются очень медленно в виде миниатюр.

в одно время, система-ввел лимит был 32,767. Сейчас он выше, но даже это слишком много файлов для обработки одновременно в большинстве случаев.

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

в качестве примера F-Spot хранит файлы фотографий как YYYY\MM\DD\filename.ext, что означает, что самый большой каталог, с которым мне приходилось иметь дело, вручную манипулируя моей ~20000-photo collection, составляет около 800 файлов. Это также делает файлы больше легко просматриваемый из стороннего приложения. Никогда не предполагайте, что ваше программное обеспечение является единственным, что будет доступ к файлам вашего программного обеспечения.

ext3 фактически имеет ограничения размера каталога, и они зависят от размера блока файловой системы. Существует не в каталоге "максимальное число" файлов, а в каталоге "максимальное количество блоков, используемых для хранения записей файлов". В частности, размер самого каталога не может вырасти за пределы b-дерева высотой 3, а разветвление дерева зависит от размера блока. См. эту ссылку для некоторых подробности.

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

Я был укушен этим недавно в файловой системе, отформатированной с блоками 2K, которая необъяснимо получала полные сообщения ядра warning: ext3_dx_add_entry: Directory index full! когда я копировал из другой файловой системы ext3. В моем случае каталог с 480 000 файлов не удалось скопировать в пункт назначения.

Я помню, как запускал программу, которая создавала огромное количество файлов на выходе. Файлы были отсортированы по 30000 в каталог. Я не помню, чтобы у меня были проблемы с чтением, когда мне пришлось повторно использовать полученный результат. Это было на 32-битном ноутбуке Ubuntu Linux, и даже Наутилус отображается содержимое каталога, хотя через несколько секунд.

файловая система ext3: аналогичный код в 64-битной системе хорошо справляется с 64000 файлами в каталоге.

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

Я столкнулся с аналогичной проблемой. Я пытался получить доступ к каталогу с более чем 10 000 файлов в нем. Слишком много времени ушло на создание списка файлов и выполнение команд любого типа в любом из файлов.

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

ниже приведен PHP-скрипт, который я написал, чтобы решить эту проблему.

список файлов в каталоге со слишком большим количеством файлов для На FTP

Как это помогает кто-то

Я предпочитаю так же, как @armandino. Для этого я использую эту небольшую функцию в PHP для преобразования идентификаторов в путь к файлу, который приводит к 1000 файлам в каталоге:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

или вы можете использовать вторую версию, если хотите использовать Альфа-цифру:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

результаты:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

как вы можете видеть на $int-версия каждая папка содержит до 1000 файлов и до 99 каталогов, содержащих 1000 файлов и 99 каталогов ...

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

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

большинство ответов выше не показывают, что нет ответа" один размер подходит всем " на исходный вопрос.

в сегодняшней среде у нас есть большой конгломерат различных аппаратных и программных средств - некоторые из них 32 бит, некоторые 64 бит, некоторые передовые, а некоторые испытаны и истинно-надежный и никогда не меняется. К этому добавляется множество старых и новых аппаратных средств, старых и новых ОС, разных поставщиков (Windows, Unixes, Apple и т. д.) и мириады коммунальных услуг и серверы, которые идут вместе. Поскольку аппаратное обеспечение улучшилось, а программное обеспечение преобразовано в 64-битную совместимость, обязательно была значительная задержка в получении всех частей этого очень большого и сложного мира, чтобы хорошо играть с быстрым темпом изменений.

IMHO нет никакого способа решить проблему. Решение состоит в том, чтобы исследовать возможности, а затем методом проб и ошибок найти то, что лучше всего подходит для ваших конкретных потребностей. Каждый пользователь должен определить, что работает для его системы вместо того, чтобы использовать подход cookie cutter.

У меня, например, есть медиа-сервер с несколькими очень большими файлами. В результате получается только около 400 файлов, заполняющих 3-ТБ диск. Только 1% из inodes использованы но 95% из полного космоса использовано. Кто-то еще, с большим количеством небольших файлов может закончиться inodes, прежде чем они приблизятся к заполнению пространства. (В файловых системах ext4, как правило, для каждого файла/каталога используется 1 индекс.) Теоретически общее количество файлов, которые могут быть содержащийся в каталоге почти бесконечен, практичность определяет, что общее использование определяет реалистичные единицы, а не только возможности файловой системы.

Я надеюсь, что все различные ответы выше способствовали мышлению и решению проблем, а не представляют собой непреодолимый барьер для прогресса.

Не ответ, а просто некоторые предложения.

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

Я думаю, пришло время изменить ваши парадигмы. Поэтому я лично предлагаю использовать распределенная система aware FS, что означает отсутствие ограничений в отношении размера, количества файлов и т. д. В противном случае рано или поздно вы столкнетесь с новыми непредвиденными проблемами.

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

для преодоления аппаратных ограничений можно использовать RAID-0.

нет ни одной цифры, которая "слишком много", если она не превышает пределов ОС. Однако, чем больше файлов в каталоге, независимо от операционной системы, тем больше времени требуется, чтобы получить доступ к любому отдельному файлу, а на большинство ОС, производительность является нелинейной, поэтому, чтобы найти один файл из 10 000 занимает более 10 раз дольше, чтобы потом найти файл в 1000.

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