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

Question

[Пума Тайланд]

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

Куда идти и как жить?
Был у меня опыт с монго грид фс, но оно работает ещё медленее, но зато масштабируется, но опять такие покупать 20 серверов, когда все влезает на один как то немного не оправдано финансово.
Кто что использует из файловых систем для хранения мелких файлов?
Как вы тюните файлуху для этого?

Comments

[AlikDex]

Надеюсь увидеть здесь решение проблемы. Потому как в перспективе маячит похожее.
Мне все же кажется оптимальнее будет раскидывать по N дешевым серверам хранения. Заодно использовать их оперативку под кеш картинок. Но это только кажется. Как на деле будет даже не представляю )

[Пума Тайланд]

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

[AlikDex]

Пума Тайланд: "разносить максимально все на разные файлухи"
Это нужно создавать небольшие партиции и раскидывать по ним? Или имеется в виду 1 диск ntfs, другой ext4, третий ext3 ;D Такой вариант как-то нелепо звучит.

[Пума Тайланд]

AlikDex: ну конечно нет ,надо просто много ext4

[AlikDex]

Пума Тайланд: тогда возникает вопрос о нештатных ситуациях. Что если 1 винт навернется? Бекапов, как я понимаю, нет. У нас была ситуация, когда навернулся рейд на 2тб. Но был бекап. Новые диски синковались потом неделю на рабочем сервере. С 20тб будет тот еще гемор.

[Пума Тайланд]

AlikDex: ну берете второй такой сервер если нужна высокая доступность в целом все решаемой

[Vi]

а как по поводу BD + raw disk ?

[Пума Тайланд]

Vi: это такое бд + рав диск?
если это имеется ввиду база данных то она практически по умолчанию медленее.

Answer 1

[65536]

я вот так раскладываю

заодно идентичные можно хранить 1 раз

когда хранил все в одной папке в нее просто не зайти было, а если зайдешь то нечего делать. и это не терабайты были а какие-нибудь 10 гб

Comments

[Пума Тайланд]

Да я тоже в три уровня раскладываю никак не помогает

[65536]

Пума Тайланд: мб есть (разумный) предел для количества файлов в одной папке. 30к думаю точно слишком. может лучше в глубину запихать

[Пума Тайланд]

65536: да 30 000 я для примера сказал там обычно не более 4000

[Александр Рябцев]

Пума Тайланд: не более пары-тройки сотен

[Александр Рябцев]

Попробуйте еще один уровень добавить

Answer 2

[Александр Рябцев]

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

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

Одно дело, читать папку, в которой 256 объектов, другое дело - когда несколько десятков тысяч, скорость работы изменится на порядки.

Comments

[alexander sm1ly]

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

Answer 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

Comments

[Пума Тайланд]

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

[Алексей Черемисин]

С количеством файлов растут и задержки. Мы все пространство побили на 20 дисков (и будем еще бить по мере надобности), так FS менее тормозит...

Answer 4

[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
Сама фс как бы и не тормозит. Там правда всего несколько миллионов файлов на несколько гигабайт.

Сотни миллионов файлов на одном разделе я в общем-то не видел, но может быть дело не в ФС?

Answer 5

[Дмитрий]

По опыту работы (с меньшим количеством), но тем не менее, ежедневная работа ~15 человек по сети с рекламной свалкой издательства. Мы специально прогоняли тесты в течение недели с реальным содержимым - то есть клонировали полностью всю свалку и меряли производительность.
reiserfs 3 для мелких файлов до сих пор ничем заменить нельзя.
xfs, jfs - очень хороши для больших файлов, т.е. медиаконтент, xfs немного быстрее с ними.
Дальше - можно оптимизировать только железо. Аппаратные raid1 на SSD + ручное планирование по типам файлов, если это возможно.

Comments

[Пума Тайланд]

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

[Дмитрий]

$ mkfs.reiserfs -V
mkfs.reiserfs 3.6.24

$ uname -a
Linux avgust 4.2.2-1-ARCH #1 SMP PREEMPT Tue Sep 29 22:21:33 CEST 2015 x86_64 GNU/Linux

У меня работает.
ЧЯДНТ?

[Пума Тайланд]

Дмитрий: ну а теперь тоже самое на убунту или центосе.

[Дмитрий]

У меня ванильное ведро. Если там что-то выпилили эти недолинуксы, это их проблемы. )

# cat /etc/debian_version
7.8

# apt-get install reiserfsprogs
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
НОВЫЕ пакеты, которые будут установлены:
reiserfsprogs

Answer 6

[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 контроллерами).

Answer 7

[Эльдар Мусин]

А файлы не имеют ничего схожего меджу собой? Ну например структуру, хедеры всякие...

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

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

Comments

[Пума Тайланд]

это картинки мало чего схожего

Answer 8

[ilnarb]

Как минимум, надо монтировать noatime!

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

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

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

Второй трюк: раз в полгода перезаливать данные. Если несколько разделов, перебрасываешь по кругу, переформатируя. Если один большой раздел, но нужен свободный сервер.

Answer 9

[Оптимус Пьян]

Может я неправ, но:

$phar = new Phar('images.phar');
$phar->addFile('img.jpg', 'img.jpg');
echo file_get_contents('phar://images.phar/img.jpg');

Ну вы поняли ))

Comments

[Пума Тайланд]

Нет не понял.

[Оптимус Пьян]

Пума Тайланд: создаём phar-архив, закатываем в него хоть 100 тыс. хоть миллион картинок, на месте где должна быть картинка на странице подключаем её из архива, в разы сокращается фрагментация диска, без сжатия архива системные ресурсы не жрёт. Обновить, удалить картинку из архива можно. Ну да, потестировать надо на ваших объёмах, если бы я сейчас делал свой проект на я бы попробовал

[Пума Тайланд]

Дмитрий: ну оно же на пхп, и изначально не заточенно под высокие нагрузки и много файлов
посмотрел формат его файла
4 bytes Number of files in the Phar
4 байта на количество файлов в архиве, а это всего 4 миллиарда файлов
думаю оно даже на миллионе файлов будет ворочаться еле еле
по сути это такой аналог тара или зипа
дефрагментация никуда не девается, все удаленные картинки будут порождать дефрагментацию.

Answer 10

[Александр Мелеховец]

С vfs_cache_pressure шаманить пробовали?

Comments

[Пума Тайланд]

по умолчанию стоит 100, смысл с ним игратьто ? меньше хуже, больше сделать нельзя.

[knutov]

мы, кстати, пробовали играться, в контексте шаред хостинга. Измеримых или хоть как-то видимых изменений нет, ибо памяти в сервере, допустим, 128, 256 или даже 512 гигабайт, а дисков в таком сервере на несколько терабайт. Т.е. любая свободная память рано или поздно уходит под дисковый кеш (и это хорошо).

[Пума Тайланд]

knutov: а смысл играться ну есть свободная память пусть юзается под кеш

[knutov]

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

[Александр Мелеховец]

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

Answer 11

[Nadz Goldman]

xfs

Comments

[Николай Ковалев]

она на мелких чуть медленнее работает, вы бы анализ что-ли для начала почитали

[Nadz Goldman]

Николай Ковалев: вы бы не анализы читали, а в тестах попробовали.
Ну или как-нибудь поработали бы с чем-нибуь, кроме extX.
Для объемов вопрошающего нужна либо xfs, либо zfs.
Но для последней на таких пространствах памяти нужно от 32 и выше - только тогда будет выигрыш.

[Пума Тайланд]

Nadz Goldman: xfs хороша для больших файлух с большими файлами, когда сервера по 100 тб места были юзал её было норм, но для мелкихфайлов она же ад.

[Николай Ковалев]

Nadz Goldman: сначала тесты, потом анализ )) у вас по-другому? склонен доверять ребятам из редхат

[Николай Ковалев]

Пума Тайланд: да она и на мелких выступает неплохо, не критично хуже. именно поэтому ее поставили по дефолту в центос 7.

[Пума Тайланд]

Николай Ковалев: в центос 6 она была критично хуже
по дефолту у людей нет таких проблем
по дефолту с большими файлами неплохо и екст4 работает я бы сказал сейчас не хуже xfs

[d'Ivan]

Где-то читал, что XFS хорош только для работы с большими блоками информации.

[Николай Ковалев]

Пума Тайланд: это правда! вообще хорошо что в центос 7 взяли наконец под крыло редхат, а то форк, да форк ))

[Пума Тайланд]

Николай Ковалев: в центос 6 она была прямиком из редхата и то что центос под редхатом xfs лучше не стала

[Николай Ковалев]

Пума Тайланд: релизы теперь быстрее выкатываются, мне нравится. да и наконец centminmod на моем горизонте появился. к файловой системе это все конечно не относится! // но у меня с переходом на xfs ушли несколько периодически возникающих проблем на инет-магазе, где и куча мелких кеш файлов, статика, кеш сессий и пр. шалупень ))

[Пума Тайланд]

Николай Ковалев: ну все остальное то конечно стало в центосе оперативнее + непрерывный репо сделали и прочие плюшки на инфраструктуре и ресурсах редхата.

[Пума Тайланд]

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

[Николай Ковалев]

да? ну ок )) тестовые ощущения - это как? я лично забыл что такое fsck на xfc, то же мотивация знаете ли. меня скорее волнует скорый переход на php7, чем возврат на ext4 ))

[Пума Тайланд]

Николай Ковалев: как минимум копирование там шустрее в два три раза.
сказать честно у меня так редко перегружаются сервера что я даже не помню никогда про fsck
хотя апдейты ядра конечно нужны иногда

[Николай Ковалев]

Пума Тайланд: принято! вижу (https://jeremytinley.wordpress.com/2014/10/08/more... скорость монтирования в 2 раза, выше у ext4. на самом деле я бы и не стал менять ext4, но поскольку перешел на центос7, то менять дефолтную ФС не стал, на том и порешил )) использую под инет-магаз и контент проект, под хостинг-услугу (хочу замутить) еще подумаю на чем, там шифрование нужно стойкое ))

Answer 12

[Павел]

А разве БД не для этого придумали?

Comments

[Александр Варакосов]

Если файлы бинарные, то от БД никакого толка. Большие объёмы данных в полях убивают производительность.

[Пума Тайланд]

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

[Павел]

SSD RAID ?

[Пума Тайланд]

Павел: а давайте ещё золотом выложим сервер и попа закажем. Во первых выйдет дорого, во вторых увеличение в пять раз производительности совершенно не решает проблему того что оно все равно чертовски медленно.

[Павел]

Пума Тайланд: Может дешевле переписать софт?

[Пума Тайланд]

Павел: ну а переписывание софта то как ускорит файловую систему. Ну перенес я картинки в БД, ну стало в десять раз медленнее , ну купил я в десять раз больше серверов чтобы стало чуть получше, потом заплатил программистам чтобы софт на БД переделали. В итоге имею в десять раз больше кап и оп расходов и туже самую проблему с производительностью

[Павел]

Пума Тайланд: Вот не угадал я что это картинки.... думал что-то еще.... тема с производительностью очень интересная... Правильно ли я понимаю, во время чтения директории - IOPS зашкаливает?
events.linuxfoundation.org/slides/2010/linuxcon201...
основная мысль - это очень дорого...

[Пума Тайланд]

Павел: наверно одна из лучших презентаций которую я видел про эту проблему, всего лишь сказали что решений нет и все медленно.

[Павел]

Пума Тайланд: тут нужно понять масштаб задачи...
чаще читаете или пишете?
есть ли возможность менять софт?
сколько оперативной памяти на СХД?
какой уровень RAID ?

И из чистого любопытства - а как вы бэкапы делаете?

[Пума Тайланд]

Павел: масштаб задачи погонять тестовые вещи на одной машине с максимальной производительность
там по моему штук 6-9 винтов в рейде 5 или 6
чаще читаю и ищу или смотрю сколько места занимают или какое количество так как картинки
софт пишется
32 или 64 гб это не схд это линукс сервер

не делаю с финансовой точки зрения проще перекачать все файло заново с интернетов чем делать бекапы хоть с каким то версионированием.
то есть на активной стадии разработки с бекапами я просто разорюсь.

[Павел]

Пума Тайланд: первое что я начал бы делать - перестроить массив на тот, в котором больше нулей, например собери страйп из зеркал.
а если данные не особо важны и при потере одного диска ты готов всё потерять - собирай нулевой, это даст максимум производительности.
а 6 уровень всегда медленнее чем пятый. на мой взгляд имеет смысл использовать когда кол-во шпинделей более 40.

[Пума Тайланд]

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

[Павел]

Пума Тайланд: Скорее ту всё в кучу, и недостатки ФС, и недоработки ПО, и не оптимизированное хранилище.
естественно задачу нужно решать всесторонне. но я не очень понимаю
это именно тестовая задача?
и именно крутить ФС нужно?
и именно много файлов в одной папке?
или возможны отступления?

Насчёт БД - мне кажется что на определённом количестве файлов в одной директории будет более чем оправдано.

[Пума Тайланд]

Павел: разделение на файлухи ускоряет в десять раз.
это тестовый продакшен
ну конечно если фс тормозит я же не могу её вечно ускорять супервинтами и увеличением шпинделей.
не много файлов в одной папке, файлы я могу как угодно расположить.
бд явно тут быстрее не будет уже проходили, мускул вообще с триллионом записей живет плохо так же как плохо живет с тысячами таблиц.
Кстати тесты показали после всех оптимизаций файлух с мелкими файлами ext4 в пару раз быстрее чем xfs.

[Павел]

Пума Тайланд: Раз уж пошла такая пьянка, можете еще и ZFS проверить? интересно посмотреть на цифры... только дедубликацию не включайте.

[Пума Тайланд]

Павел: сорри нет ресурсов на это нынче, погряз в работе.

Answer 13

[irvinzz]

По поему опыту мелкими файлами хорошо рулит именно reiserfs

Comments

[ilnarb]

мелкими для reiserfs считаются меньше одного блока

[poige]

reiserfs отличная в плане space use — tail packing. Но она дикий тормоз при одновременной записи — lock'и

Answer 14

[Сергей Каменев]

reiserfs 3

Answer 15

[mirosas]

SSD эту проблему еще не решили?

Comments

[Пума Тайланд]

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

[mirosas]

Пума Тайланд: не учел... На малых объемах используют SSD, на средних SSD-кэш. На больших... хм.. может поставить побольше оперативки и закэшировать всю файловую систему в оперативку? В виндоусе знаю фаловый кэш работает без учета особенностей магнитных блинов, так что там не вышло бы, в юникс-подобных может получше с этим.

А свой драйвер к файловой системе сложно написать? Чтобы она нормально все кэшировала? Обычно системы кэширования не учитывают особенности блинчиковой системы. Была такая мысль, но оставил ее, поняв что расходов на сосздание наверное прилично, а продать не получится)).

[Пума Тайланд]

mirosas: много оперативки это сколько раз по 64 гб ставить надо ? Это тоже очень дорого будет, сейчас стоит то ли 64 гб то ли 128 гб.
Тут надо не драйвер писать а файловую систему, да это сложно и дорого. Если будет очень хорошая продать непроблема.

[mirosas]

Пума Тайланд: она просто может оказаться практически никому не нужна)), и тогда продать будет сложно. Для обычной задачи SSD кэш выглядит намного привлекательней, и стоит дешевле десятки кликов по некоторым тематикам)).

Файловая система в 64 гига не помещается? хм..

Answer 16

[poige]

Правильный ответ — агрегация. Ни одна файловая система POSIX-семантики не будет нормально работать с таким кол-вом файлов.

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

P. S. Скорее всего, за прошедший год, topic starter в этом убедился. :)

Answer 17

[neochar]

be-n.com/spw/you-can-list-a-million-files-in-a-dir...