Файловая система: большое количество файлов в одном каталоге
Хорошо, не такой большой, но мне нужно использовать что-то, где около 60000 файлов со средним размером 30 КБ хранятся в одном каталоге (это требование, поэтому нельзя просто разбить на подкаталоги с меньшим количеством файлов).
Доступ к файлам будет осуществляться случайным образом, но после их создания запись в одну и ту же файловую систему производиться не будет. В настоящее время я использую Ext3, но очень медленно. Какие-либо предложения?
Вам следует рассмотреть XFS. Он поддерживает очень большое количество файлов как на уровне файловой системы, так и на уровне каталогов, а производительность остается относительно стабильной даже при большом количестве записей из-за структур данных B + tree.
Есть страница в их вики к большому количеству статей и публикаций, детализирующих дизайн. Я рекомендую вам попробовать и сравнить его с вашим текущим решением.
Автор этой статьи исследует некоторые проблемы с производительностью файловых систем с большим количеством файлов и делает несколько хороших сравнений производительности различных файловых систем ext3, ext4 и XFS. Это доступно в виде слайд-шоу. https://events.static.linuxfound.org/slides/2010/linuxcon2010_wheeler.pdf
Многие файлы в каталоге на ext3 подробно обсуждались на родственном сайте stackoverflow.com
На мой взгляд, 60 000 файлов в одном каталоге на ext3 - это далеко от идеала, но в зависимости от других требований этого может быть достаточно.
ХОРОШО. Я провел предварительное тестирование с использованием ReiserFS, XFS, JFS, Ext3 (dir_hash включен) и Ext4dev (ядро 2.6.26). Моим первым впечатлением было то, что все было достаточно быстро (на моей мощной рабочей станции) - оказалось, что удаленная производственная машина имеет довольно медленный процессор.
Я испытал некоторые странности с ReiserFS даже при начальном тестировании, поэтому исключил это. Кажется, что у JFS на 33% меньше требований к процессору, чем у всех остальных, поэтому мы проверим это на удаленном сервере. Если он работает достаточно хорошо, я воспользуюсь этим.
Я пишу приложение, которое также хранит много-много файлов, хотя мои файлы больше, и у меня их 10 миллионов, которые я разделю по нескольким каталогам.
ext3 работает медленно в основном из-за реализации по умолчанию "связанного списка". Итак, если у вас много файлов в одном каталоге, это означает, что открытие или создание другого будет происходить все медленнее и медленнее. Существует так называемый индекс htree, доступный для ext3, который, как сообщается, значительно улучшает ситуацию. Но это доступно только при создании файловой системы. Посмотреть здесь: http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/
Поскольку вам все равно придется перестраивать файловую систему и из-за ограничений ext3, я рекомендую вам использовать ext4 (или XFS). Я думаю, что ext4 немного быстрее работает с файлами меньшего размера и быстрее восстанавливается. Насколько мне известно, индекс Htree по умолчанию установлен на ext4. На самом деле у меня нет опыта работы с JFS или Reiser, но я слышал, что люди рекомендуют это раньше.
На самом деле я бы, вероятно, протестировал несколько файловых систем. Почему бы не попробовать ext4, xfs и jfs и посмотреть, какой из них дает лучшую общую производительность?
Что-то, что мне сказал разработчик, что может ускорить работу кода приложения, - это не выполнение вызова "stat + open", а скорее "open + fstat". Первый значительно медленнее, чем второй. Не уверен, что у вас есть контроль или влияние на это.
См. Мой пост здесь, в stackoverflow. Хранение и доступ к 10 миллионам файлов в Linux там есть несколько очень полезных ответов и ссылок.
Использование tune2fs для включения dir_index может помочь. Чтобы узнать, включен ли он:
sudo tune2fs -l /dev/sda1 | grep dir_index
Если он не включен:
sudo umount /dev/sda1
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1
Но у меня такое чувство, что вы можете пойти по неверному пути ... почему бы не создать плоский индекс и не использовать какой-нибудь код для случайного выбора на основе этого. Затем вы можете использовать подкаталоги для более оптимизированной древовидной структуры.
ext3 и ниже поддерживают до 32768 файлов в каталоге. ext4 поддерживает до 65536 в фактическом количестве файлов, но позволит вам иметь больше (он просто не будет хранить их в каталоге, что не имеет значения для большинства пользовательских целей).
Кроме того, в файловых системах ext * каталоги хранятся в виде одного большого списка. В более современных файловых системах (Reiser, XFS, JFS) они хранятся как B-деревья, которые намного эффективнее для больших наборов.
Вы можете хранить inode файлов вместо имен файлов: доступ к номерам inode должен быть намного быстрее, чем разрешение имен файлов.
Вы не хотите запихивать столько файлов в один каталог, вам нужна какая-то структура. Даже если это что-то столь же простое, как наличие подкаталогов, начинающихся с первого символа файла, может улучшить время доступа. Еще одна глупая уловка, которую я люблю использовать, - заставить систему обновлять свой кеш с помощью метаинформации - это регулярно запускать updateb. В одном окне запустите slabtop, а в другом - updateb, и вы увидите, что много памяти будет выделено для кеширования. Так намного быстрее.
Вы не указали тип данных в этих файлах. Но, судя по всему, вы должны использовать какую-то базу данных с индексированием для быстрого поиска.
Файловая система, вероятно, не идеальное хранилище для таких требований. Лучше какое-то хранилище базы данных. Тем не менее, если вы ничего не можете с этим поделать, попробуйте разделить файлы на несколько каталогов и использовать unionfs для монтирования (привязки) этих каталогов в один каталог, в котором вы хотите, чтобы все файлы отображались. Я вообще не использовал эту технику для ускорения, но попробовать стоит.