Скорость работы сервера при работе с большими каталогами

Предлагаю обсудить следующую проблему:

1) Есть веб-сервер с большим трафиком (под управлением FreeBSD c Apache).

2) На сервере много картинок, которые лежат в одной папке /images/dir???? (dir0001-dir9999)

Вопрос: Как будет зависеть скорость работы сервера и его загруженность от количества каталогов внутри папки /images ?

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

было бы интересно узнать мнение специалистов по данному вопросу.

Последний раз редактировалось: kit (24/06/05 в 20:07), всего редактировалось 1 раз

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

kit писал:

Предлагаю обсудить следующую проблему: 1) Есть веб-сервер с большим трафиком (под управлением FreeBSD c Apache). 2) На сервере много картинок, которые лежат в одной папке /images/dir???? (dir0001-dir9999) Вопрос: Как будет зависеть скорость работы сервера и его загруженность от количества каталогов внутри папки /images ?

Никак. Я не специалист в файловых системах для FreeBSD, но имхо это не проблема для Linux.
Могу сказать также, для таких задач, как обслуживание больших объёмов статики, лушче попробовать nginx например вместо апача, загрузка значительным образом снизится

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

У меня тоже был похожий случай, тормоза были. Но это в винде. Как там в других операционками - руками не щупал.
Но имхо должны быть, которые сводят эту проблему к минимуму

Тормоза могут быть по двум причинам:
1) Узкий канал, тогда информация о директории, которая будет размером до нескольких мегабайт, будет несколько медленно приходить к Вам. но это не проблемма .
2) Возможности самой связки (сервер+операционка). У меня реально была задача упорядочивания более 100 тыс. файлов на фтп, и конечно при наличии в директории уже 1000+ файлов снижается скорость работы. Под Unix-системами несколько проще, но гемороя не меньше. Работали ночью когда меньше обращений было, так как и это оказывается при таких объемах важно.

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

советую сделать несколько уровней каталогов. например pics/год/месяц. Где год - год дабавления картинки, месяц - соответственно. Можно не привязываться к датам а организовать деление по другим признакам. Проблема отпадет сама собой. Насчет тормозов - при количестве файлов более 100тыс, тормоза начинают быть заметны.

Уточняю: В каталогах лежат галереи. Пока каталогов внутри /images/ около 500, и это уже напрягает при попытке доступа туда по FTP. А вот что делатьЮ, если там будет 5000 подкаталогов?

Альтернативы Apache рассматриваются, если они поддерживают mod_rewrite, mod_gzip, mod_php

kit писал:

Уточняю: В каталогах лежат галереи. Пока каталогов внутри /images/ около 500, и это уже напрягает при попытке доступа туда по FTP. А вот что делатьЮ, если там будет 5000 подкаталогов? Альтернативы Apache рассматриваются, если они поддерживают mod_rewrite, mod_gzip, mod_php

5000 подкаталогов это не так много... Инфа о них не читается при попытке найти inode файла, то есть получить к нему доступ. Что по FTP напрягает -- с этим ничего не поделаешь. Но в общем конечно структуру лучше оптимизировать.
В винде педалит, бо структура FAT линейная.
Альтернативу Апачу, которую я предлагал называется nginx. Поддерживается mod_rewrite (синтаксис отличный от апачевского), mod_gzip. PHP поддерживается как FastCGI. Есть ограничение -- отсутствует функционал .htaccess. Но возможно всё ещё сыроват, но сам использую и очень доволен.

По моим наблюдениям(программинг под разными ос в интрасетях) важно несколько моментов:

1. В корне раздела максимальная минимизация каталогов и файлов, (в идеале один каталог).
2. Древовидная вложенная структура каталогов, с количеством каталогов кратным 8.
3. минимизация имен каталогов, т.е. не "dir0001/dir0001/dir0001", а "a/ab/aab" - количество знаков зависит только от количества каталогов в даном уровне, т.е. если в уровне ожидается 16 каталогов двузначными имена делать никакого смысла нет.
4. При фтп доступе приличное время уходит на собственно загрузку каталога, его объем желательно минимизировать; не делать количество папок в уровне больше 128.