Linux за българи: Форуми

Имам следната постановка
Програма която на всеки 5мин. се стартира от cron чете данни и записва около 30000 файла.
Файловете са поставени в двойна хеш структура (/root/hash1_id0/hash2_id0/files, /root/hash1_id0/hash2_id1/files)
При приключване на програмата след 4-5 сек. кернела прави синхронизация на файловата система и се генерира доста cpu io wait за колко 40/50 сек.

Нуждая се от съвет за оптимизация. (друга файлова система, отделен HDD ... )

Цитат "...Нуждая се от съвет за оптимизация. (друга файлова система, отделен HDD ... )..."

Ами то изобщо не си казал нито каква ти е текущата ФС, нито дистрибуцията, etc. Пък и 30 000 файла не е шега работа. Все някой ще даде идея, ама дай малко повече инфо.

SAS дискове на 15К.

А каква е основната цел на оптимизацията - скорост, консистентност и пълнота на данните или ...

PC1 и PC2 получават едни и същи данни.
PC1 работа в реално време с клиенти
PC2 води архив по дадено ID file_id всеки запис е с дължина 12 байта, на всеки 5мин. се добавя нов запис към файл с име file_id. Всеки ден fail_id се намира в нова хеш директория.

На PC1 има mount на цялата хеш структура от PC2 през NFS по всяко едно време клиента може да поиска част от архива и тук в този момент, ако PC2 е в състояние io wait клиента чака м/у 0-40 сек.
При тази реализация, ако PC2 не е в wait при заявка от страна на клиента данните му се предоставят мигновено. Преди имах реализирам архив в MySQL при него има по-бързо записване в БД и по-бавно доставяна до клиента.

Цел колкото се може по-бързо доставяна да данните до клиента.

Трябвало е да му сложиш индекси където трябва, твърде вероятно щеше да е обратното.

Правил съм подобен експеримент, да записвам голям брой малки файлове в различни поддиректории (индексирани на две нива по спомени, общият брой директории беше 65535). Пробвал съм с няколко файлови системи - ext2, ext3 и reiserfs. Различни mount опции малко или много помагаха при четенето или писането, но при ext2/3 не много трудно стигах до момента в който изгърмявах всичките inodes възможни за файловата система. Ако я форматираш с дефолтските опции, на около 100 гигабайт-ова ext3 файлова система свършваха още някъде при 30-40 милиона файла, може би по-рано, всичко това по спомени (с reiserfs нямах такива проблеми, там ползват някакъв механизъм за динамично allocate-ване на inodes или някаква подобна щуротия и лимитът е бая висок). Но най-големият проблем идваше при записването на нови файлове, понеже в някои директории файловете ставаха доста, демек не бяха особено балансирани по отношение на индексите и за някоя директория може да имаш десетки хиляди файлове, за друга - стотина. Оказа се че нито една от тези файлови системи не scale-ва много добре когато добавяш нови файлове в "голяма" директория - от един момент нататък производителността се срива брутално и когато искаш да запишеш един малък файл от 32 байта, чакаш доста. Има разни опции при монтиране или създаване на файловата система, които касаят организацията на dentry-тата, примерно в някакви техни дървета там, и те помагат, но до време - винаги от един момент нататък нещата се сговнят доволно добре. reiserfs се държа най-прилично апропо, но и той увяхна не много след ext3. А,да, не искам да звучи като реклама на reiserfs, защото точно по време на тези занимавки успях да скапя точно тази файлова система до невъзможност да я оправя.

Между другото, когато правех "bulk insert"-и, демек наливане на нови файлове, от един момент нататък, проблемът ми не беше точно I/O bandwidth-а, а точно overhead-а от VFS слоя, процесите ми бяха в iowait и утилизацията на cpu-то, доволно добра. Първоначално наливането на нови файлове си беше наистина I/O-интензивна операция, от един момент нататък (когато файловете ставаха прекалено много), повечето време отиваше в сметки в VFS слоя, това и без да гледам sar и top ми беше ясно, по стърженето на харддиска :)

Накрая отебах опитите да се занимавам с файлови системи и реших да ползвам mysql. Но пък един пич след това постигна доста повече (не милиони, а милиарди файлове, но индексите му бяха на 3 нива и изпълнението беше върху NTFS - не знам може пък NTFS да се държи по-добре за такива случаи).

А, при тебе файловата система ти е също и NFS export...ехех :)

При мен индекса е много точен около 100-150 файла в директория на второ ниво хеш

hash1 текущия ден от 1970 до тук (int)(time(null)/86400)
hash1/hash(1,2,3...255) 255*120 ~= 30000
проблема е че при запис аз чета snapshot от паметта и пиша/упдейтвам по 30000 файла всеки път

П.П. А за MySQL проблема беше че тези данни ми трябват в бинарен формат и там индексите си бяха ок но записа беше нещо от рода на DATA=CONCAT(data,char(value1,value2,....)) и към края на месеца писането ставаше по-бавно и тук четенето става много бързо memcpy(buffer, file1,file2 ....) send

П.П2 hash1 не е повече от 30 директории за сега

GeSHi (Bash):
#!/bin/bash
 
cd /var/lib/track-data
 
echo "Start purging tracks"
 
DIRNAME=$[$(date +%s)/86400-31]
 
while [ -d $DIRNAME ]; do
    echo "Delete /var/lib/track-data/$DIRNAME $(date -d@$[$DIRNAME*86400])"
    rm -rf $DIRNAME
    DIRNAME=$[$DIRNAME-1];
done

При мен индекса е много точен около 100-150 файла в директория на второ ниво хеш

....

Според мен имате нещо сбъркано в дизайна на процеса, опитайте да направите нещата с база данни (mysql, postgresql, oracle, db2)

@gat3way - бях чел някъде че не било хубаво под ext2/3 да имаш над 2000 файла в директория защото над тази граница се забавят операциите много

@romeo_ninov - +1

@sandman_7920 - Според мен даже един XML с подходящо форматиране би могъл да ти ускори достъпа. Създаването на много малки файлове по размер в гигантски количества убива всякакъв достъп до файловата система.

RAM Drive  + периодичен backup в/у HDD  :?

Създадох един 30Гб файл на reiserfs и го маунтнах през loop и нещата излетяха от 40-50 сек. за синхронизация при запис сега синхронизира за 2-6сек. (Ако по време на инсталирането си бях заделил един дял само за това, който да е align-ат нямаше да имам такива проблеми)