Я вынужден иметь эту структуру каталогов / var / www / $ WEBSITE / $ DIR1 / $ DIR2 / $ FILES
на каждый из этих файлов $ FILES приходится примерно 50 000 страниц XHTML.
Я использую Cherokee, в котором есть новая поддержка внешнего кеширования. Но у меня немного ограничена память, поэтому я не могу все это кэшировать. Я считаю, что могу кэшировать только список, а это худшая часть.
Что я могу делать со стороны файловой системы? Обычно я использую ext4 (мой сервер использует ext3), но я знаю, что в таких ситуациях лучше использовать ReiserFS. Я мог бы просто смонтировать этот $ WEBSITE в ReiserFS. Я действительно не собираюсь переделывать вещи и хотел бы поработать над этим.
Могу ли я расположить подкаталоги где-нибудь в файловой системе и просто привязать их все к $ DIR2? Поможет ли это улучшить ситуацию в этой неприятной ситуации и уменьшить боль от ext3?
Мне действительно не нужны какие-либо RDB, я бы рассмотрел вариант NOSQL, если бы я мог каким-то образом создать из него поддельную файловую систему. это был бы такой классный вариант, просто не уверен, что он вообще существует. Возможно, что-то связано с FUSE?
весь сайт уже существует, и в основном это просто причудливый список каталогов. Файлы записываются один раз, а затем просто читаются оттуда. Нет никаких шансов, что количество файлов в каталоге увеличится с этого момента.
Я рекомендую XFS с одним возможным исключением: если вам часто нужно удалить много файлов из этого дерева каталогов, производительность удаления в XFS не так хороша. Это было немного улучшено с новым журнал задержек параметр mount, однако.
В остальном XFS даже не откажется от 50 000 файлов в каталоге.
50 000 файлов должно быть недостаточно, чтобы вызвать серьезную проблему скорости в Linux. Вы упомянули кеширование списка, поэтому я думаю, что вы выполняете некоторую обработку файлов вместо простого обслуживания. Я бы поискал вопросы о том, как вы обрабатываете файлы.
Я нашел решение своей проблемы
Из-за производительности моей FS мне было неудобно всего лишь ~ 5000 файлов, поэтому я разместил этот вопрос. Обычно я бы использовал Ext4 и XFS; который всегда был солидным исполнителем; но у меня уже все было установлено на Ext3.
В Ext4 по умолчанию включены индексы Htree, поэтому это не проблема. Ext3 поддерживает индексы Htree, dir_index; однако он не был включен на моей FS.
# I Checked Ext features, no dir_index
$ tune2fs -l /dev/xvda | grep features
# Enabled dir_index
$ tune2fs -O dir_index /dev/xvda
Мне пришлось выполнить fsck после перезагрузки, но в остальном он успешно включился. Когда я перечислил файлы в этих каталогах, проблемы с производительностью исчезли. Я мог бы избежать реализации VFS на основе NoSQL, gridfs-fuse; и я мог избежать изменения размера / перераспределения на моем полностью выделенном HD.
Что касается изменения моей FS, я хотел по возможности избежать подобных операций с диском.
Вы можете попробовать XFS. У меня большие каталоги, работающие в файловой системе XFS, с хорошими результатами. ls, du и другие файловые операции заметно лучше, чем на ext3. В любом случае, для масштабируемости имеет смысл разработать более чистую структуру каталогов.
[root@bootylicious /data/print]# ls -1 | wc -l
431801