Тормоза ext4

обращении через что?

Через что угодно. sh/bash, php/python/жава.
Я тут потестил немного, при 20к файлов по 100кб тормозит меньше, чем при 1к файлов по 100мб.

В идеале, хочу 100-1000к файлов в одном каталоге держать.

В идеале, хочу 100-1000к файлов в одном каталоге держать.

Зачем?

Хочу. Нельзя?

ну смени ФС, делов то...

На какую? Я думал, может какие то опции монтирования фс помогут в моем случае.

Ну про тюнинг тут. Но это индивидуально... http://www.opennet.ru/opennews/art.shtml?num=37339 а про ФС тут http://wiki.opennet.ru/FSComparison

Но как говориться теория-теорией, а практика критерий истины :)

Я и надеюсь на советы практиков :(

каком именно обращении? ls?

Тред читай, потом отвечай, ок?

reiserfs?

Бенчмарки погоняешь? Да и она вобще не поддерживаемая, насколько я знаю.
Надоели теоретики с локалхоста :(

У меня ext4 на любое движение тормозит.

/usr/lib64 $ dir -1 |wc -l
2976

не тормозит, совсем. 0.4 секунды при 1 обращении. Но файлы разные, большая часть менее 1 мегабайта, так что может у тебя фрагментация либо проблемы с железом или даже софтом. Теперь попробуй то же самое на ntfs. А вообще как бы да, лучше раскидать по подкаталогам.

попробуй XFS

но только с последними ядрами

XFS на маленьких файлах не очень (была), у неё другие задачи.

ReiserFS, BTRFs.

Тормозит ОЧЕНЬ сильно

ОЧЕНЬ это сколько секунд?

Добавлять relatime к опциям монтирования пробовал?

на btrfs если ядро у сервера новее 3.14.1

нтфс уже при 100 файлах в директории чуть живая, ты о чём?

noatime при монтировании, ls вызывать с ключами, исключающими сортировку

time (ls .|wc -l)
10845
( ls . | wc -l; )  0,07s user 0,00s system 96% cpu 0,073 total

Я тут потестил немного, при 20к файлов по 100кб тормозит меньше, чем при 1к файлов по 100мб.

Какие то странные тесты, всё кроме чтения/записи работает с метаданными, размер файла не влияет.

Обращение это пролистать директорию в ls? atime выключен? dir_index включен?

time ls|wc -l
83318

real	0m0.415s
user	0m0.403s
sys	0m0.017s

Если делать stat на каждый файл:

time ls -l|wc -l
83319

real	0m0.951s
user	0m0.723s
sys	0m0.242s

df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       932G  638G  294G  69% /mnt/target

mount -v|grep sdb
/dev/sdb1 on /mnt/target type xfs (rw,noatime)

файловая система создана с дефолтными параметрами, при удалении большого количества файлов может быть медленнее ext4 с dir_index. Диск - один sata hdd 1TB.

Если нужно много файлов для Ext3/4 в директории: всегда надо включать dir_index

Проверять через tune2fs

tune2fs -l /dev/md0|grep -i dir_index
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

Для ext4 с dir_index:

time ls | wc -l
33971

real	0m0.174s
user	0m0.160s
sys	0m0.012s

time ls -l | wc -l
33972

real	0m0.447s
user	0m0.280s
sys	0m0.168s

df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        459G  259G  177G  60% /

mount -v |grep -i md0
/dev/md0 on / type ext4 (rw,noatime,errors=remount-ro)

2k файлов по 200-300 МБ в одной директории на HDD - всё нормально работает, в т.ч. при многопоточном чтении. Из дополнительных опций только noatime, при создании никаких дополнительных опций не указывалось. Debian Sid, ядро 3.14, e2fsprogs 1.42.11. На более старых версиях проблем тоже не было. Версию ядра в студию (в т.ч. примерную версию на момент создания ФС).

диск/массив ?

это точно после сброса кэшей?

Как ext4 может тормозить? Тут же тема была, что она уделывает hfs+ по скорости серьезно, а на маке ничего не тормозит.

так что может у тебя фрагментация либо проблемы с железом

Нет.

Теперь попробуй то же самое на ntfs.

А причем тут ntfs?

Со сбросом дольше.

Кеш после ls -l МИНУС кеш после сброса, но до ls -l занимает 143МБ, полный размер директории 27GB. Обычно метаданные всех файлов в кеше висят (web сервер).

XFS

sync; echo 3 > /proc/sys/vm/drop_caches ; sync ; time ls -l |wc -l
83319

real	0m21.729s
user	0m1.024s
sys	0m1.354s

sync; echo 3 > /proc/sys/vm/drop_caches ; sync ; time ls |wc -l
83318

real	0m0.913s
user	0m0.459s
sys	0m0.033s

Ищем файл в этой директории
sync; echo 3 > /proc/sys/vm/drop_caches ; sync ; time stat xxx.JPG > /dev/null

real	0m0.040s
user	0m0.001s
sys	0m0.003s

ext4 Кеш после ls -l МИНУС кеш после сброса, но до ls -l занимает 22МБ, полный размер директории 2GB. Обычно метаданные всех файлов в кеше висят (web сервер).

sync; echo 3 > /proc/sys/vm/drop_caches ; sync ; time ls -l |wc -l
33972

real	0m3.980s
user	0m0.256s
sys	0m0.352s

sync; echo 3 > /proc/sys/vm/drop_caches ; sync ; time ls |wc -l
33971

real	0m3.095s
user	0m0.164s
sys	0m0.028s

Ищем файл в этой директории
sync; echo 3 > /proc/sys/vm/drop_caches ; sync ; time stat xxx.jpg > /dev/null

real	0m0.454s
user	0m0.004s
sys	0m0.000s

Спасибо.

Железный массив.

я к тому, что несколько секунд на холодную это не так много, ведь никакая конкретная информация не указана.

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

отлично рассказывай дальше. Что за массив/локальный/nfs-iscsi, что у него с io...
ext4 ни разу не тормоз копай в направлении своего массива

говорят, в последних ядрах это исправили

ты btrfs на рейдах используешь?

Бенчмарки погоняешь? Да и она вобще не поддерживаемая, насколько я знаю.

А из чего ты выбирать собрался, чудо в перьях?

Надоели тормоза ext4 при обращении к директории с 1-2к файлов по 300к строк

На одной из виртуальных машин (ubuntu 12.04 сервер) есть папка с 924314 мелких файлов, лежат они на ext4, сама ВМ расположена на zfs-zvol. При первом обращении к папке есть лаг, потом работает быстро.

пока нет, шары файл сервера без рейда, сделал по диску на каждую и хватит.

dir_index включен с дремучих времён на любых ext* по дефолту, болезный

болезный

спасибо, я в порядке.

relatime тоже включен в современных ядрах по-умолчанию, всегда можно наткнуться на древнюю инсталляцию

всегда можно наткнуться на древнюю инсталляцию

debian 7

Я и не собирался выбирать между фс. Подумал, что такое поведение ext4 ненормальное и как-то лечится.

можно наткнуться на древнюю инсталляцию

на которой есть ext4, болезный?

пробуй sysctl -w vm.vfs_cache_pressure=0 или 1