» Скорость доспупа к файлу в ext3fs

есть такой сервер
Core2Duo 2,33GHz (Е6550), 4 Gb RAM, 2×750Gb 7200rpm HDD
на нем очень большая нагрузка на винт, которая связана с огромной базой которя постоянно дергается и огромным кол-вом документов которые постоянно скачиваются (тексты,фото)... и на данный момент возник вопрос оптимизации...

добавив еще 4Гб оперативки, перевести полностью базу в оперативку... снизим нагрузку на винт.

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

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

кто из них прав???

Нагрузка на винт не снимается путем добавления оперативки.
Нужен RAID. Желательно hardware.

SysCommander

Цитата:

Нагрузка на винт не снимается путем добавления оперативки.

Они базу в оперативку (ramdisk?) хотят сложить, так что вполне снимет.

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

FuzzyLogic
да базу полностью в оперативку запихать
поиск вообще не ведется!!! и не планируется!
почему програмер прав? более как то подробнее если можно объясни.... мне просто это надо как то попонятнее объяснить админу, чтобы он закрыл вопрос с этим и не катил бочку на то что типа в этом проблема ...
вот тут http://forum.ixbt.com/topic.cgi?id=76:8379#2 тоже запостил, но пока нормального, можно сказать с цифрами и примерами скорости доступа ответа (

THALAMUS
Я не понял в чём проблема, пусть программер возьмёт раздел под ext3, напишет что-нить что сделает на нём несколько миллионов файлов (или сколько там планируется) и продемонстрирует админу скорость. Всё выяснится на месте. Затраты времени на такой тест - минут 10 на написание ну и сколько то-там подождать пока такое кол-во файлов наколбасит.

ну админ сделал следующее:

unknown-3565:/mnt/cache/imgCache# time cp 0000ecd6943919469be746f88cdc4699 /tmp/

real 0m1.070s
user 0m0.004s
sys 0m0.004s
unknown-3565:/mnt/cache/imgCache# time cp /tmp/0000ecd6943919469be746f88cdc4699 /tmp/1

real 0m0.002s
user 0m0.000s
sys 0m0.004s
0.002s - время выполнения команды во втором случае а в первом 1.070s

на что прогер сказал
сравнение некорректо потамучто фал уже скэшировался
nick@unknown-3565:/mnt/cache/imgCache$ time cp zzzz /tmp/
cp: cannot stat `zzzz': No such file or directory

real 0m0.010s
user 0m0.000s
sys 0m0.000s
он понял что нету файл zzzz в папке где дохуя файлов очень-чень быстро

после чего идет переписка с админом:

Мега (21:22:06 16/09/2008) выводы какие моно сделать?
Админ серверов alex (21:23:00 16/09/2008) какие выводы?
Мега (21:24:18 16/09/2008) он понял что нету файл zzzz в папке где дохуя файлов очень-чень быстро. в принципе так же быстро как и ты показывал
Админ серверов alex (21:25:28 16/09/2008) ну а пусть реальный файл прочитает
Мега (21:25:35 16/09/2008) а тот файл возможно быстро загрузился, т.к. был скеширован... ВОЗМОЖНО, не категорично пишу... просто я пытаюсь понять...
Админ серверов alex (21:26:00 16/09/2008) не это мало похоже на правду


поэтому если скорость доступа падает в 100раз, то это не есть гуд. поэтому хочу просто понять механизм ФС почему она так быстро записывает и почему кол-во файлов не имеет значения.

А стоит ли ext3?
Чтиво: http://ubuntu.onego.ru/articles/filesystem/


Добавлено:
И http://ru.wikipedia.org/wiki/Сравнение_файловых_систем

Добавлено:
зы: на производительность еще могут влиять опции монтирования.
при работе с большим количеством файлов процессорное время могут сьесть такие фичи как обновление времени ( atime ) , тип журнала...


Добавлено:
И еще мысль.
На чтение если проверять то можно в /dev/null копировать.

THALAMUS
Файл после первого обращения действительно кешируется в памяти, тут прогер прав, однако опыт подсказывает что в общем более прав админ.

P.S. Интересный вопрос, пожалуй займусь на выходных тестированием на кошках.

2strmaks
плиз сообщи потом результаты....

ext3 может быстро работать с большим количеством файлов в каталоге, если включена опция 'dir_index'. Без этой опции - чем больше файлов, тем больше тормоза.

1. в общем случае, когда разговор идет о _произвольной_ операции с директорией, в которой находится большое количество файлов, прав админ.

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


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


p.s. чтобы разобраться в вопросе:
1) читать про особенности fs;
2) читать про работу стандартного набора команд, которыми работают с файлами и fs;
3) понимать, что делается в программе с этими самыми файлами;

vjunk
можно быстро... быстро насколкьо... это так же быстро как и если бы файлы были разбиты на например на 100 папок по 100.000... если сравнивать с например моим вариантом, когда в одной папке находится 10.000.000 файлов.
или все же скрорось велика, но меньше чем при разбиении на папки.

+ добавился еще такой вопрос, что по папкам тоже надо "лазить" и определять где там находится файл и на это тоже наверное будет уходить время...

в итоге что же быстрее, совсем запутался

Цитата:

что же быстрее

вы понимаете разницу между получением листинга директории, в которой 1 млн. файлов, и открытием конкретного файла из этой директории?

> Нагрузка на винт не снимается путем добавления оперативки.
> Нужен RAID. Желательно hardware.

Нагрузку в виде очереди IO не снять, ты прав. Но некоторые дисковые объекты (часто используемые файлы, среди которых - директории) очень хорошо размещаются в памяти. Я не знаю, насколько хорошо ext3 "дружит" с памятью, но XFS & ZFS используют память "по-полной" и чем ее больше - тем эффективнее работает дисковая система.

Прогнал я ради интереса тест - измерил время открытия файла (без считывания данных, только open) при разных количествах файлов и разной организации дерева.

Первый график в линейном масштабе, второй в логарифмическом.




По горизонтали - количество файлов на файловой системе (от 10,000 до 3,000,000).
По вертикали - время на открытие одного файла в милисекундах.
Три графика с включённой опцией dir_index, три с выключенной.
Цифры 1, 2 и 3 - количество уровней в дереве.
1 - все файлы в одном каталоге, 2 - файлы рабиты на подкаталоги, 3 - файлы разбиты на подкаталоги с подкаталогами.

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

vjunk
код?
как измеряли время?

Скрипт создающий файлы:
[more]
#!/usr/bin/perl

use warnings;
use strict;

my $FORMAT='%07d';

my $DIR=$ARGV[0];
my $COUNT=$ARGV[1];
my $SPLIT=$ARGV[2];

$SPLIT or $SPLIT=1;

chdir($DIR) or die;

my $DIVISOR=int($COUNT**(1/$SPLIT));
my $MAKED=0;

sub mkfiles($)
{
my($path)=@_;

my $name;
for(my $i=0; $i<$DIVISOR; ++$i)
{
$name="$path/".sprintf($FORMAT, $i);
open(F, ">$name") or die;
close(F);
++$MAKED;
$i%100==0 and print STDERR "$name\r";
}
print STDERR "$name\r";
}

sub mklevel($$)
{
my($path, $level)=@_;

--$level;
if($level>0)
{
for(my $i=0; $i<$DIVISOR; ++$i)
{
my $dir="$path/".sprintf($FORMAT, $i);
mkdir($dir) or die;
&mklevel($dir, $level);
}
}
else
{
mkfiles($path);
}
}

my $start_time=time;
mklevel('.', $SPLIT);
my $elapsed=time-$start_time;
print STDERR "\nMaked $MAKED of $COUNT\n";

print "Make time elapsed: $elapsed\n";
print "Files created: $MAKED\n";
print "File creation time: ",$elapsed/$MAKED,"\n";
[/more]
Скрипт читающий файлы:
[more]
#!/usr/bin/perl

use warnings;
use strict;

my $FORMAT='%07d';
my $LIMIT=20;

my $DIR=$ARGV[0];
my $COUNT=$ARGV[1];
my $SPLIT=$ARGV[2];

$SPLIT or $SPLIT=1;

chdir($DIR) or die;

my $DIVISOR=int($COUNT**(1/$SPLIT));

my $start_time=time;
my $elapsed=0;
my $old_elapsed=0;
my $count=0;
do
{
$_='.';
for(my $i=0; $i<$SPLIT; ++$i)
{
my $i=int(rand($DIVISOR));
$_="$_/".sprintf($FORMAT, $i);
}
open(F, "<$_") or die;
close(F);
++$count;
$elapsed=time-$start_time;
if($elapsed!=$old_elapsed)
{
print STDERR "$elapsed ($_)\r";
$old_elapsed=$elapsed;
}
}
while($elapsed<$LIMIT);
print STDERR "$elapsed ($_)\n";

print "Time elapsed: $elapsed\n";
print "Files opened: $count\n";
print "File open time: ",$elapsed/$count,"\n";
[/more]
Запускать ./имя_скрипта имя_каталога количество_файлов глубина_дерева
(оба скрипта с одинаковыми параметрами).

Цитата:

+ добавился еще такой вопрос, что по папкам тоже надо "лазить" и определять где там находится файл и на это тоже наверное будет уходить время...

Если у файлов есть некуий числовой ид, то хорошая мысль - делать название директории как остаток от деления на 1000 (к примеру), тогда сразу ясно где находиться файл.

Reiser fs имхо нада ставить, а не ext3. ext3 - журнализируемая ФС, она занимается не тем чем надо имхо, только для больших файлов. ext2 тоже ничего.... пошустрее будет чем ext3

evgenpev
ext2 на сервере с базой - моветон
reuserfs - журналируемая, неплохо работает при малом числе пользователей, при одновременном обращении нескольких пользователей скорость снижается и безбожно ест процессорное время.