Падение скорости на ext4 при заполнении

Какой-то бенчмаркинг по фотографии. Возьми да проверь.

Я спрашиваю про теорию, чтобы знать куда смотреть.

40-50 млн файлов небольшого размера

Застрелиться. xfs и zfs точно не спасут. Рейзер умел в кучу мелких файлов, но было это давно и неправда.

В общем, нормального решения нет, потому когда-то базы данных и придумали.

А кто сказал, что проблема с фс? Что на нижнем уровне, шпиндели или ссд? Что с вводом/выводом в иопсах?

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

Брал подобный диск (4ТБ, HDD) и заполнял файлами (/dev/urandom) и наблюдал падение скорости с 60-70 Мб/с до 7-8 Мб/с уже на 15 млн файлах по 200 Кб размером. tps при этом около 250-270

ZFS вообще довольно медленная. XFS — надо проверять. Если это на HDD, то SSD может сильно помочь, но всё равно надо тестировать, чтобы понимать, на сколько именно.

Можно размазать по 2-3 дискам, но толку мало.

Точно? Почему тогда думаешь, что проблема в ФС?

JFS раньше вроде норм была для небольших файлов, но сейчас наверное убрали из ядра. XFS для больших файлов по объему рекомендовали. я ещё в криокамере :)

Именно. Если я соберу даже raid - я все равно упрусь в потолок числа файлов. А так как производитель основного ПО ушел из РФ - обновлений нет (и точно не будет), работаем с тем что есть, БД тоже не вариант. Вот и решил спросить у народа, что посоветуете…

Отключи журнал, должно стать получше. Но не думаю что очень сильно.

JFS раньше вроде норм была для небольших файлов, но сейчас наверное убрали из ядра

Не убрали, но на аппарате жизнеобеспечения.

XFS для больших файлов по объему рекомендовали

Эти рекомендации устарели после 2009-2010, наверное. Сейчас оно для любых файлов работает хорошо. В среднем, возможно, быстрее ext4, но зависит от конкретного приложения. Особо деталями не владею, сам пользователь неторопливой Btrfs.

Где-то читал, что может стать и похуже, это уже совсем не ext3.

Пробовал чуть ли не сразу - не помогло, все также медленно.

Нашел интересное сообщение: https://superuser.com/questions/605622/how-does-the-number-of-files-in-the-same-folder-affect-i-o-performance-in-an-ext?rq=1

Особенно эту часть:

The simplest example of delays is that, obviously, the time to list the entire directory will vary with how big the directory is.

Secondly, depending on the filesystem settings, ext4 uses either linked lists, or a hashed b-tree for directory lookups. You need only look up how those two data structures work, to get some idea of the differences that incorrect configuration might make. The short version is that linked lists are pretty slow, and only suitable for small directories, whereas that hashes are much faster, and much better suited to large directories.

Processing a linked list means going through each and every item in the list, because, most of the time, only item n-1 knows where item n is, so you must read item n first.

Processing a hash tree involves calculating a number in memory, and jumping directly to details based on that number. Although it may have to do this a few times for big directories, it's much faster than processing every node.

Anyway, if you really want to understand the details, all the documentation is available online. You could start here, for instance: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Hash_Tree_Directories

А ты все эти файлы как хранишь? Надеюсь не в одном каталоге?

Нет, там какой-то внутренний аналог кеша - 2-3 уровня и т.д. В каждом еще до сотен уровней.

Брал подобный диск (4ТБ, HDD) и заполнял файлами (/dev/urandom) и наблюдал падение скорости с 60-70 Мб/с до 7-8 Мб/с уже на 15 млн файлах по 200 Кб размером. tps при этом около 250-270

Ну давай посмотрим на цифрах:

• 60 мегабайт/с в файлах по 200 кб - это 300 с копейками файлов в секунду
• кеш у таких дисков примерно 256 мегабайт - в него влазит около тысячи файлов
• Ну и от дисков 5400RPM (скорее всего) не стоит ожидать больше 70 иопс

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

Не сказано что с кешами в ОС и в каком режиме ты тестировал (ты писал или читал?).

Выходит, что потенциально ты можешь выжать максимум 15 мегабайт в секунду на чтение (70 иопс * 200 кб) при большой удаче.

Попробуй XFS

Вообще-то если файлы просто лежат и ты просто в одно лицо их читаешь/пишешь, то тормозов быть не должно. Я делал тесты с созданием 100к файлов в одной директории и не увидел какого-то ощутимого замедления ext4 (на пару с рейзером3 ext4 имела огромный отрыв от всех остальных фс, а xfs на этом тесте вообще умерла). 14 тыс файлов в секунду на НЖМД, куда быстрее-то?

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

Я думаю, что у тебя проблема не в самой ext4. Какая у тебя нагрузка? Может ли быть так, что это прикладная программа читает гигантский список файлов в память и свопится?

В плане советов могу предложить lvmcache на SSD. А также поиграть со swappiness, chache pressure и т.п. Но это скорее по разряду шаманства и камлания.

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

Здесь у ext4: https://events.static.linuxfound.org/slides/2010/linuxcon2010_wheeler.pdf примерно такая скорость и получается (10^9 файлов по 20 кбайт за 4 суток). И она там лучшая. ″iostat -x″ что показывает при записи?

По разным папкам разбей, ext4 уже после 10к файлов в одной начинает тормозить

распихай по каталогам.

Не начинает.

Начинает.

Просто интересно, а как с этим на ntfs?
Что там вообще на серверах в офтопике используется?

Что там вообще на серверах в офтопике используется?

думаешь exfat?

Наверное как-то же ворочается, если они ещё large_dir добавили.

Users who find the current limit of about 10 million files a bit constraining can enable this feature and raise the limit to around 2 billion.

Ещё помню это ускоряли использованием getdents64() а не сменой фс.

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

Проблема явно в вытеснении из RAM-буферов данных и метаданных и относительной медленности HDD.

Нужна FS с расширенными возможностями по кэшированию. Тут из продакшн на ум приходит только ZFS с большим прогретым L2ARC-кэшем на SSD.

Другие варианты: либо дисковый массив на ~100 HDD, либо переход на SSD с бэкапами на HDD.

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

Отключи журнал,

Советы анонимуса как обычно самые правильные. Отключи журнал - и при любом сбое твои миллионы файлов отправятся на свалку истории, а ты получишь быструю пустую систему.

как отсутствие журнала повлияет на бэкап

Не знаю как в вашем мире розовых пони и зеленых соплей, а в реальном мире восстановление с бэкапа помойки с терабайтами файлов это время. В продуктивных системах админ за решения потребовавшие восстановление с бэкапа получает конретных. Если бы в моей конторе админ предложил такое - то был бы уволен сразу причeм с отзывами по коллгам этого клоуна к администрированию не допускать. Если бы сделал - то еще мог бы влететь на иск, поскольку простой прода это всегда убыток. Все знают что shit happens - и делают для этого бэкапы, но ежели причиной этого стали идиотские решения админа то…

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

я бы попробовал еще и btrfs https://www.reddit.com/r/btrfs/comments/zophr0/sane_mount_options_for_billions_of_small_files/

еще плюс что в btrfs не нужно резервировать иноды заранее

Я делал тесты с созданием 100к файлов в одной директории и не увидел какого-то ощутимого замедления

Я не думаю что проблема в этом. Проблема в том что место в директориях (по крайней мере на ext4) никогда не reclame’тся. Попробуйте создать пару миллионов файлов в одной директории, и потом удалить каждые 9ть из 10ти, и потом зачитать эту директорию обратно - вы поймёте о чём я.

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

Проблема в том что место в директориях (по крайней мере на ext4) никогда не reclame’тся.

Не совсем никогда, e2fsck -D

Не совсем никогда, e2fsck -D

Без рута - работает?

Это же fsck, без рута можно при желании, но вот на смонтированной ФС — уже нет, а именно это должно беспокоить.

Проверь на bcachefs, которая недавно была добавлена в ядро. Интересно.

Интересно, не знал

Ну, посчитайте сами. FS размером порядка 10TB. Память машины сколько GB? Сколько из них занимает прикладное ПО? Только остальное может быть использовано под буферы FS. Каков это % от самой FS? А каков % попадания ПО в этот кэш? Т.е. сколько в среднем нужно подчитывать с FS? 98-99%? Конечно, при таком недостатке RAM для кэширования и уже прочитанные данные и метаданные будут вытесняться.

Т.е. даже если файлы ‘хорошо’(т.е. последовательно) разложены на FS, с 1 дешового serial ata HDD получим ~12MBps (~60 * 0.2MB). (C 3-ёх hdd в страйпе в 3 раза быстрее.) Как и указывал stave ранее.

Радикально улучшить ситуацию может только SSD: либо как основной носитель, либо как кэш.

Например, уже обсуждали.

с 1 дешового serial ata HDD получим ~12MBps

Немножко странная цифра: я бы ожидал увидеть 60+ MByte/sec как минимум. На серверном железе - раз в 5-10 больше.

Оценить возможности конкретной железки очень просто.
Быстрый НЕразрушающий тест случайного чтения, например,
SSD:

# ioping -R /dev/sdc

--- /dev/sdc (block device 119.2 GiB) ioping statistics ---
54.0 k requests completed in 2.85 s, 210.8 MiB read, 18.9 k iops, 74.0 MiB/s
generated 54.0 k requests in 3.00 s, 210.8 MiB, 18.0 k iops, 70.3 MiB/s
min/avg/max/mdev = 30.1 us / 52.8 us / 1.22 ms / 32.8 us

HDD:

# ioping -R /dev/sdd

--- /dev/sdd (block device 931.5 GiB) ioping statistics ---
186 requests completed in 3.00 s, 744 KiB read, 62 iops, 248.3 KiB/s
generated 187 requests in 3.01 s, 748 KiB, 62 iops, 248.4 KiB/s
min/avg/max/mdev = 5.42 ms / 16.1 ms / 50.3 ms / 6.61 ms

Т.е. для serial ATA ssd ~ 18900 iops, а hdd ~ 62 iops.
Разница возможности железок в ~300 раз.
Для NVMe этот тест нужно запускать 8-10 процессами, а затем суммировать, когда будет достигнут потолок.

Т.е. для serial ATA ssd ~ 18900 iops, а hdd ~ 62 iops.

Если я ничего не пропустил - изначально речь исключительно про последовательную запись и чтение была, в контексте HDD. Понятно что по IOPS SSD рвёт HDD как Тузик грелку.

Не ‘вообще’ последовательное, а последовательное чтение каждого отдельного файла, запись примерно также: ext4 старается мапировать файл на свободное место, чтобы не разбивать его на части (и другие FS обычно тоже). Ну, не будут же всегда все необходимые для чтения в данный момент файлы лежать на 1 дорожке HDD друг за другом?

Также, со временем и фрагментация файлов только увеличивается. Если каждый файл будет состоять хотя бы из 2 частей, разнесённых по поверхности диска HDD, то на 1 файл будет тратиться 2 iops

• hdd на каждый файл перемещает механически читающий узел 2 раза. Так ведь? Это будет означать снижение MBps в 2 раза. Ну, и так далее при большей фрагментации.

Соответственно в SSD мехеники нет и ожидания поворота диска нет, поэтому и iops высокие.

Помнится, кто-то предлагал принцип хранения высокой плотности в виде волны на поверхности кристалла, где данные вращаются в волне, а не на диске, но что-то эта разработка заглохла. Была бы альтернатива и SSD и HDD, взявшая всё лучшее от них обоих.

Ну, чего нет, того нет, поэтому работаем с тем, что есть.

По рекомендации https://www.phoronix.com/news/Linux-6.5-EXT4 перешел на ядро 6.6 из бекпортов Дебиана и реально скорость возрасла, причем достаточно значительно. Может быть где-то накосячил, пока тестирую, но значительно выросла скорость даже тупого копирования данных с диска на диск ext4.

и это на hdd или ssd ?

Оффтопик:

https://www.phoronix.com/news/Linux-6.5-EXT4

Бесконечная и бессмысленная проверка клаудфлары, обожаю (нет).