LINUX.ORG.RU
Форум — Admin  

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

 , ,


1

6

Здравствуйте. Подскажите, куда смотреть и можно ли что-то сделать (подтюнить) ext4 или сразу мигрировать на что-то вроде ZFS или xfs. Имеется разветвленная структура файлов и каталогов, всего около 40-50 млн файлов небольшого размера (до 100-200 Кб), в основном бинарные файлы: шрифты, рисунки в векторных форматах (остатки от работы CAD и пр.). Все это нужно держать как есть, сжать не выйдет, так как старый проприентарный софт именно так это и хочет видеть. Можно размазать по 2-3 дискам, но толку мало. В чем проблема: при наличии уже около 20-30 млн мелких файлов файловая система ext4 начинает дико тормозить при записи, скорость обмена падает до 6-7 Мб/с. Чтение тоже замедляется примерно до тех же величин. Диск 100% исправен. inodes занято около 15%, свободного места - и того больше, пара ТБ точно есть. Понятно, что такое обилие файлов вызывает тормоза - поясните, а что именно вызывает? Какой механизм, я хочу понять где узкое место в случае миллионов файлов возникает? И что можно сделать? Понятно, что перенести, но нет денег и не предвидится (пока). Поможет ли XFS/ZFS в таком случае? Всякие там atime/adirtime убраны в fstab в ноль, а что еще можно подтюнить? Спасибо


 ← 1 2 →

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

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

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

anonymous
()

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

antech ☆
()
Последнее исправление: antech (всего исправлений: 1)
Ответ на: комментарий от stave

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

netvis
() автор топика
Ответ на: удаленный комментарий

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

netvis
() автор топика
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()

Нашел интересное сообщение: 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
netvis
() автор топика
Ответ на: комментарий от netvis

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

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

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

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

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

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

stave ★★★★★
()

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

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

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

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

legolegs ★★★★★
()
Ответ на: комментарий от legolegs

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

d ★★★★
()
Ответ на: комментарий от HE_KOT

Наверное как-то же ворочается, если они ещё 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() а не сменой фс.

anonymous
()
Ответ на: комментарий от anonymous

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

HE_KOT
()

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

ahnenerbe
()
Последнее исправление: ahnenerbe (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от anonymous

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

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от legolegs

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

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

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

bugfixer ★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от ahnenerbe

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

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

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

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

anonymous
()
Ответ на: комментарий от bugfixer

Оценить возможности конкретной железки очень просто.
Быстрый НЕразрушающий тест случайного чтения, например,
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 процессами, а затем суммировать, когда будет достигнут потолок.

anonymous
()
Ответ на: комментарий от anonymous

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

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

bugfixer ★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от bugfixer

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

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

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

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

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

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

anonymous
()

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

ahnenerbe
()
 ← 1 2 →
Admin