LINUX.ORG.RU

Ext4 максимальное ускорение в ущерб надежности

 , , ,


1

2

Собственно, сабж.

Есть куча временных данных в виде маленьких файликов (от пары килобайт до мегабайта), общим объёмом 500-600 гигов, данные время от времени (раз в 10-15 минут) перезаписываются. Сохранность этих данных не важна - это такой своеобразный кэш для приложения для увеличения его производительности. В оперативной памяти хранить, понятное дело, не вариант. Под это дело выделен отдельный диск, отформатирован в ext4, журналирование отключено.

Вопрос: как можно максимально увеличить производительность ext4 даже в ущерб надежности? Или использовать другую фс?

P.S: запихнуть в базу эти данные не получится, да и не нужно.



Последнее исправление: Rufus111 (всего исправлений: 1)

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

Такой ssd слишком дорого, да и с регулярной перезаписью такого объёма с ним придется в скорости (через год, а то и меньше) распрощаться.

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

Как бы то ни было - такой объём памяти, это слишком дорого.

Rufus111
() автор топика

убери метки времени (посмотри опции в man mount, я нашёл noatime,norelatime,nodiratime,noinversion,lazytime), кроме этого ничего особо не сделаешь, вроде (но по ману на предмет доп. опций ты глазами всё таки пройдись). Ну и попробуй другую фс, может лучше будет.

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)

кстати, можно использовать raid0. Вроде с него и чтение и запись вдвое быстрее.

да, а почему возник вопрос то? Скорость перезаписи не устраивает? Если да,то какая сейчас и какая нужна. Если нет - в чём проблема ты бы пояснил поподробнее, может кто посоветует чего.

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

Ну, во-первых, спасибо за конструктив, сейчас еще покурю ман по ext4, потом, наверно, попробую reiserFS - говорят, очень хорошо работает с малыми файлами.

Проблема такая - было написано приложение, достаточно давно, на C++. «Кэш» писался на диск, программа постоянно к нему обращалась на чтение и раз в определенное время на перезапись. Пока данных было мало - проблем не было. Как только объёмы начали увеличивать, появились проблемы - слишком большая нагрузка на диск, данные банально не успевают записываться а в некоторые моменты и читаются очень медленно. Большую часть времени диск загружен под 100%, load_average, соответственно, улетает в небеса.

P.S.: приложение скомпилировано, исходного кода нет, приходится изгаляться.

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

Начать с опций. Поглядеть на эффект. Попробовать другую фс.

Но раз диск всё время загружен, то вероятно просто дисковая подсистема не вытягивает. Оно ж пишет(исходя из твоих слов) не всё время, чаще читает. Т.е. по большому счёту и читать не успевает.

Я бы предложил докинуть такой же диск. И сделать raid0 (ну или 1 попробовать). И на него сверху фс которая лучше себя покажет (если такая будет, или пробовать менять фс уже на раиде). Все упомянутые опции + отключить журналирование, конечно.

PS. да, ну и я бы прост сказал начальнику что нужен ssd. Это решило бы все вопросы. Не так уж это и дорого. Только бери нормальную модель причём с запасом по объёму, типа интела или самсугна, с гарантией, вроде такого (гарантия вроде 10 лет). А то виноват останешься что диск полетел через 3 месяца.

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)

у нас под такое reiserfs3 использовался, очень и очень не плохо работал. extX под это очень плохо подходит.

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

Спасибо, сейчас рэйд попробую сначала.

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

Благодарю, тоже смотрел в эту сторону

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

Больше ничего сделать нельзя, разве что noatime выставить в опциях монтирования. Быстрее файлух, чем ext4 без журнала, вы всё равно не найдёте.

Deleted
()

Какое-то стрёмное решение, если честно. Оператива нынче дешёвая. Кроме того, ещё же page-cache есть в ядре, через него данные будут так или иначе в памяти оседать (частично, конечно). Юзайте in-memroy key-value хранилища по типу REDIS и будет счастье.

i82 ★★
()

nobarrier в опции монтирования.

Deleted
()

Можно ещё глянуть в сторону bcache. Сделать рейд из hdd и bcache на ssd

onlybugs ★★
()
/dev/sda8 /tmpfs ext4 defaults,noatime,nodiratime,data=writeback,commit=120 0 0

+ при создании (mkfs.ext4) выключен журнал

zaz ★★★★
()

ext4 ненужна, ставь надёжную ext2, и будет тебе счастье, минут на пять, ибо фс в линукс это ужас

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

ни хрена себе дешёвая, ddr2 стоит, как целый HDD

anonymous
()

ОП, может тебе стоит купить несколько хдд и объединить их? так то, один диск = одна скорость записи, два диска = вдвое быстрее, не?

shikata_ga_nai
()

куча временных данных в виде маленьких файликов (от пары килобайт до мегабайта)

Рейзер с такими данными справляется лучше, чем ext4.

Deleted
()

Может тогда без ФС писать?

aplay ★★★★★
()

А хорошо ли жмутся твои данные? Если да, то я бы глянул в сторону zram. Возможно, требуемый объём опереративки (с учётом сжатия) войдёт в твой бюджет.

П.с. А БД не вариант использовать под твои задачи?

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

приложение скомпилировано, исходного кода нет

Вопрос снимается.

anonymous
()

барьеры убери, noatime включи, тип журнала смени.

darkenshvein ★★★★★
()

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

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

Это есть в ext4, правда вручную самому включать.

anonymous
()

Сохранность этих данных не важна

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

А вариант с периодической чисткой этого кэша (удалением давно неиспользованных файлов) из cron не подойдёт?

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

Там нет такой опции, там есть упаковка хвостов, это не одно и то же. И с упаковкой хвостов ReiserFS уже несколько лет как приводит к паникам ядра.

Я делал тесты - создавал zram-устройства, на них накатывал разные ФС, и на этом компилировал ядро и проделывал манипуляции с деревом портежа. Ext4 без журнала оказалась самой быстрой, а ReiserFS показала одинаковые результаты с Btrfs без сжатия.

Deleted
()

Большое всем спасибо, опробовал: 1.) ext4 с отключенным журналом, nobarrier и noatime на одном диске 2.) То же самое, но на raid0 из двух дисков 3.) reiserfs3 на одном диске

1 и 3 показали примерно одинаковую скорость, 1 был чуть производительнее. 2 показал, естественно, лучший результат - высокая скорость записи и чтения, если верить atop'у - busy этого массива составляет не более 50% во время пиковой нагрузки.

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

Я делал тесты - создавал zram-устройства

Фейл. Одна из важных проблем при разработке ФС - минимизировать затраты на позиционирование головок. Нет головок - тест не валиден.

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

Ещё подумалось о размере блоков/кластеров, если файлы мелкие.

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

Да ему намного дешевле вариант подойдёт, так как диск нужен всего лишь «для ускорения работы программы», а не «критически важен для её работы».

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

Бесспорно, но таковы реалии отечественного бизнеса - построить конфетку из говна и палок. Как только опять упремся по производительности в диск - выбью денюжку на ssd

Rufus111
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.