opium
@opium
Просто люблю качественно работать

Расскажите про ваш опыт с файловыми системами для мелких файлов?

Вот и снова встретился проект с гигантским количеством мелкий файлов, их триллиарды. Они мелкие до мегабайта, а чаще 100кб.
ext4 тормозит безбожно на разделе в 20 ТБ , файлов только на десятку.
Никакой тюннинг ext4 c безжурналирования, бариерами, ноэтаймами никак ситуацию не меняе, скорость дисковый операций дико низкая.
В целом эта ситуация всегда наблюдается при большом количестве файлов , но тут их очень много и бывает каталог открыть с 30 000 директорий это секунду, а то и десятки секунд, что конечно не приемлемо.

Куда идти и как жить?
Был у меня опыт с монго грид фс, но оно работает ещё медленее, но зато масштабируется, но опять такие покупать 20 серверов, когда все влезает на один как то немного не оправдано финансово.
Кто что использует из файловых систем для хранения мелких файлов?
Как вы тюните файлуху для этого?
  • Вопрос задан
  • 7520 просмотров
Пригласить эксперта
Ответы на вопрос 17
65536
@65536
я вот так раскладываю
b445816de05cb28c2fb8990cb11a6b3d.png
заодно идентичные можно хранить 1 раз

когда хранил все в одной папке в нее просто не зайти было, а если зайдешь то нечего делать. и это не терабайты были а какие-нибудь 10 гб
Ответ написан
Можно переместить все файлы в структуру каталога, где на каждом уровне будет 256 поддиректорий.
1-й уровень вложенности - 256 папок
2-ой уровень вложенности -256^2 папок
......
n-ый уровень - 256^n

Можно получать хэш md5 от
md5sum filename - 9673a892a7d8c1c9ac598ebd06e3fb58
затем нарезать путь из директорий, выбирая по 2 символа на подгруппу:
/96/73/a8/filename
Таким образом, для трехуровневой структуры можно разложить порядка 4-х миллиардов файлов, где в конечной папке будет в среднем 256 файлов.
Триллион файлов - сделайте четыре уровня.

Одно дело, читать папку, в которой 256 объектов, другое дело - когда несколько десятков тысяч, скорость работы изменится на порядки.
Ответ написан
leahch
@leahch Куратор тега Linux
3Д специалист. Долго, Дорого, Дерьмово.
О, брат! Ты вошел в зону боли... Она, увы, лучшая :-( unix.stackexchange.com/questions/28756/what-is-the...
Да, ext4 никак не тюним, отключили atime только при маунте.
Можно еще btrfs попробовать, но у нас не полетела...
Вот тесты (не наши), у нас подобное. Тестируем через fio.
Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s
Ответ написан
@neol
А чем и зачем вы открываете эти директории?

Спрашиваю потому что
time ls -f -1 | wc -l
937070

real	0m1.240s
user	0m0.632s
sys	0m0.680s

но
time ls -1 | wc -l
937076

real	0m25.873s
user	0m24.978s
sys	0m0.940s


ext4, из опций только noatime
Сама фс как бы и не тормозит. Там правда всего несколько миллионов файлов на несколько гигабайт.

Сотни миллионов файлов на одном разделе я в общем-то не видел, но может быть дело не в ФС?
Ответ написан
Комментировать
deemytch
@deemytch
linux root, ruby/perl programmer, sql, backend.
По опыту работы (с меньшим количеством), но тем не менее, ежедневная работа ~15 человек по сети с рекламной свалкой издательства. Мы специально прогоняли тесты в течение недели с реальным содержимым - то есть клонировали полностью всю свалку и меряли производительность.
reiserfs 3 для мелких файлов до сих пор ничем заменить нельзя.
xfs, jfs - очень хороши для больших файлов, т.е. медиаконтент, xfs немного быстрее с ними.
Дальше - можно оптимизировать только железо. Аппаратные raid1 на SSD + ручное планирование по типам файлов, если это возможно.
Ответ написан
knutov
@knutov
Если у вас ext4, то проблема происходит от журнала. Если запустить

iotop -oPa

увидите jb2, съедающий всё ио (или iostat -kx 1)

1) можно просто удалить журнал.

tune2fs -O ^has_journal /dev/sdX

где sdX - ваш диск с разделом (т.е. например sda2)/

Вопреки популярным мнениям - в контексте хостинга ничего страшного без журнала не случится (предполагая, что у вас относительно нормальный сервер в относительно нормальном ДЦ).

2) Можно поставить нормальные серверные диски.

Это, например, Intel s3610, но если без очень больших нагрузок, то Intel S3500 или Seagate 600 Pro тоже будет, скорее всего, достаточно (но Seagate 600 Pro не советую, в текущий момент его смысла покупать уже нет).

upd: про 20тб. Проблем в целом не должно быть, если это zfs (raidz2, например), + l2arc cache. Ну или делать на ссд дисках (серверных типа s3610, или обычных, но с LSI контроллерами).
Ответ написан
Комментировать
А файлы не имеют ничего схожего меджу собой? Ну например структуру, хедеры всякие...

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

Как пример docx может хранить инфу в 10Кб, а как только эскпортируешь в pdf, то в увелечение в 10 раз - реально.
Ответ написан
@ilnarb
Как минимум, надо монтировать noatime!

Мы когда-то давно жили на reiserfs (из-за лимита на число inode в ext2), но он был глючен и тормоза усилялись со временем. У reiserfs было преимущество из-за наших файлов меньше 1кб. Пото начали переходить на ext3, в то время уже было много мелких файлов в среднем 1Кб, на ext3 начали ставить размер блока в 1кб и увеличивали число inode. Потом файлы стали бо'льшего размера, да и диски стали более емкие, перестали менять размер блока. Теперь только стоковый ext4 с дефолтными настройками блоков/inode, монитруем defaults,noatime.

Люба ФС, со временем, любая ФС начинает тормозить (привет тем кто считает что дефрагментация не нужна на линухе). Причем, ФС может в тестах даже с реальными объемами показывать одни результаты, а через год работы -- совершенно другое распределение пьедестала.

Там в ядре есть всякие блокировки объектов каталога при лукапах файлов, поэтому, чем больше файлов/каталогов внутри каталога, тем тормознее будет. Решение: разбивать многоуровнево по хешу от имени файла (см. ответ 65536 @65536).

Второй трюк: раз в полгода перезаливать данные. Если несколько разделов, перебрасываешь по кругу, переформатируя. Если один большой раздел, но нужен свободный сервер.
Ответ написан
Комментировать
Может я неправ, но:
$phar = new Phar('images.phar');
$phar->addFile('img.jpg', 'img.jpg');
echo file_get_contents('phar://images.phar/img.jpg');

Ну вы поняли ))
Ответ написан
С vfs_cache_pressure шаманить пробовали?
Ответ написан
@pbt39
А разве БД не для этого придумали?
Ответ написан
@irvinzz
По поему опыту мелкими файлами хорошо рулит именно reiserfs
Ответ написан
inetstar
@inetstar
Автор, алгоритмист, поставщик серверного оборудова
reiserfs 3
Ответ написан
Комментировать
@mirosas
SSD эту проблему еще не решили?
Ответ написан
@poige
Правильный ответ — агрегация. Ни одна файловая система POSIX-семантики не будет нормально работать с таким кол-вом файлов.

В качестве знакового примера можно привести переход Ceph на использование RocksDB — в storage backend "BlueStore".

P. S. Скорее всего, за прошедший год, topic starter в этом убедился. :)
Ответ написан
Комментировать
neochar
@neochar
PHP vs Python
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы