-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
На сайте 8000 jpeg-ов, каждый размера не более 5-6 К. Храню их в одном каталоге...
- Автор темы IF
- Дата начала
Gorynych
Посетитель PHP-Клуба
kruglov - не байка, честное слово было 
лет пять назад Новиков экспериментальным путем вывел правило, согласно которому ОС начинает подтормаживать при обращении к файлам, если их в каталоге более 1000. После чего было картинки стали размешать не больше чем по тысяче в одном каталоге.
лет пять назад Новиков экспериментальным путем вывел правило, согласно которому ОС начинает подтормаживать при обращении к файлам, если их в каталоге более 1000. После чего было картинки стали размешать не больше чем по тысяче в одном каталоге.
Gorynych
Посетитель PHP-Клуба
baev
ну ка, ну ка... И сколько у нас различных вариантов реализации файловой системы на самом деле? Садимся поудобнее и начинаем слушать про разные реализации архитектруной организации фаловой системы в существующих и активно эксплуатируемых операционных системах. Ну хорошо, давайте (для особо догадливых), ограничимся семействами Windows / *NIX.
а прежде чем ляпнуть про BSD/Linux или про NFS/NTFS/FTA (ну, кто еще чего умного скажет?) немного подумаем о том, как именно собирается ядро, и че там у нас на самом деле с файловой архитектурой
P.S. да, гонку железа никто не отменял. Я в курсе.
P.P.S. я действительно с удовольствием послушаю в вашем изложении краткий курс файловых систем применительно к чтению информации о содержимом каталога и доступа к файлам. Особенно - в части различий (нет, про систему безопастности и права доступа речь не идет, кстати, а кто у нас занимался разработкой этого для NT 4? Не знаете часом?)
ну ка, ну ка... И сколько у нас различных вариантов реализации файловой системы на самом деле? Садимся поудобнее и начинаем слушать про разные реализации архитектруной организации фаловой системы в существующих и активно эксплуатируемых операционных системах. Ну хорошо, давайте (для особо догадливых), ограничимся семействами Windows / *NIX.
а прежде чем ляпнуть про BSD/Linux или про NFS/NTFS/FTA (ну, кто еще чего умного скажет?) немного подумаем о том, как именно собирается ядро, и че там у нас на самом деле с файловой архитектурой
P.S. да, гонку железа никто не отменял. Я в курсе.
P.P.S. я действительно с удовольствием послушаю в вашем изложении краткий курс файловых систем применительно к чтению информации о содержимом каталога и доступа к файлам. Особенно - в части различий (нет, про систему безопастности и права доступа речь не идет, кстати, а кто у нас занимался разработкой этого для NT 4? Не знаете часом?)
Gorynych
ой сколько Вы всего понаписали!..
Во-первых, нехрен «нукать» — не запрягали.
Во-вторых, если внимательнее приглядеться, я вопросы задал.
Если на самом деле «волшебное число» не зависит ни от ОС ни от файловой системы, достаточно было так и ответить.
А не понтоваться разными умными словами. Я, например, таких слов и не знаю: «реализации архитектруной организации фаловой системы»...
И уж тем более (извините за серость) я не в курсах, кто там у вас «занимался разработкой этого для NT 4».
В-третьих, признаю некоторую некорректность своих вопросов.
Конечно же, начинать надо с вопроса об объективной количественной характеристике взамен субъективной оценки «подтормаживает».
В чём эту «подтормаживаемость» измерять?
Вот создаёт система, к примеру, 100 файлов за 1 секунду, 1000 файлов за 10 секунд, 10000 файлов за 100 секунд.
С какого момента считать систему «подтормаживающей»?
ой сколько Вы всего понаписали!..
Во-первых, нехрен «нукать» — не запрягали.
Во-вторых, если внимательнее приглядеться, я вопросы задал.
Если на самом деле «волшебное число» не зависит ни от ОС ни от файловой системы, достаточно было так и ответить.
А не понтоваться разными умными словами. Я, например, таких слов и не знаю: «реализации архитектруной организации фаловой системы»...
И уж тем более (извините за серость) я не в курсах, кто там у вас «занимался разработкой этого для NT 4».
В-третьих, признаю некоторую некорректность своих вопросов.
Конечно же, начинать надо с вопроса об объективной количественной характеристике взамен субъективной оценки «подтормаживает».
В чём эту «подтормаживаемость» измерять?
Вот создаёт система, к примеру, 100 файлов за 1 секунду, 1000 файлов за 10 секунд, 10000 файлов за 100 секунд.
С какого момента считать систему «подтормаживающей»?
AndreyKl
Новичок
Мда... у меня на линуксе около полумилиона файлов в одном каталоге. Не тормозит. ФС - XFS. Раньше на венде стояло всё это добро (файлов было около 300000 в каталоге или меньше, фс - нтфс, естесственно) - там да, притормаживало и падало регулярно, а в каталог лучше было вообще не заходить, если по ошибке зашёл - перегружай машину...Автор оригинала: Gorynych
kruglov - не байка, честное слово было
лет пять назад Новиков экспериментальным путем вывел правило, согласно которому ОС начинает подтормаживать при обращении к файлам, если их в каталоге более 1000. После чего было картинки стали размешать не больше чем по тысяче в одном каталоге.
-~{}~ 06.09.06 02:17:
По теме, если разложить файлы по каталогам, доступ будет быстрее.
Возможно, просто слишком много обращений к диску? Если трафик хороший...
-~{}~ 06.09.06 02:30:
Я не знаю, "как именно собирается ядро, и че там у нас на самом деле с файловой архитектурой", но:
1) как минимум упоминание NFS в этом контексте не в тему однозначно.
2) ext2, ext3, HPFS, UFS, NTFS, FAT, reiserfs, reiserfs4, XFS, JFS, ZFS.... как собак нерезаных на самом деле. Из вышеперечисленных немного попарно похожи(по архитектуре) ext2 и ext3 (братья родные, но тесты производительности, есстесственно, разнятся) и HPFS and NTFS.. Тоже похожи.. идейно вроде, правда я не профи в этом, может быть кто чуть-чуть знаком с темой? остальные - ничего общего, совершенно разная архитектура. Тесты дают результаты, иногда в разы отличающиеся, в зависимости от размеров/количества файлов, мощности прцессора (критично для reiser, (reiser4 вроде бы тоже требовательна к поцессору, но не так, да и вроде оптимизируют её..)) наличия апаратного кеша записи и т.д. Это если ограничиваться тем, что я помню на вскидку (а это далеееко не всё что есть) для win/nix, а если вспомнить vax, plan9 и т.д. ...
3) Вы пукнули в лужу, громко и отчётливо...
AndreyKl
Новичок
У тебя не винда, чтоб тормозило, винду поставь и в каталог этот зайди эксплорером. Всё получится
-~{}~ 06.09.06 13:59:
А для того, чтобы фрибсд на 50000 затормозила, я не знаю, что надо делать... Хотя есть идея - написать специальный пач на php и сделать его модулем ядра. Радикально, конечно, и сложно - но другого решения я не вижу
ЗЫ. Ну и от железа, конечно, зависит, и от общей нагрузки на дисковую подсистему... может на сервере у чела просто диск не справляется, а мы тут ...
-~{}~ 06.09.06 13:59:
А для того, чтобы фрибсд на 50000 затормозила, я не знаю, что надо делать... Хотя есть идея - написать специальный пач на php и сделать его модулем ядра. Радикально, конечно, и сложно - но другого решения я не вижу
ЗЫ. Ну и от железа, конечно, зависит, и от общей нагрузки на дисковую подсистему... может на сервере у чела просто диск не справляется, а мы тут ...
440hz
php.ru
только что разруливал подобную систуацию.
до изменений апач висел на 255 процессах и ему не хватало.
1. поставил перед апачем nginx. апач на 127.0.0.1
2. сделал что б nginx отдавал картинки, а скрипты рулил апачу.
3. сейчас у апача висит 2-3 процесса.
4. average упал с 15 до 0.50.
5. клиент счастилв.
до изменений апач висел на 255 процессах и ему не хватало.
1. поставил перед апачем nginx. апач на 127.0.0.1
2. сделал что б nginx отдавал картинки, а скрипты рулил апачу.
3. сейчас у апача висит 2-3 процесса.
4. average упал с 15 до 0.50.
5. клиент счастилв.