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

Nvme ssd.

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

tmpfs

tmpfs

500-600 гигов? Это мне суперкомпьютер надо будет арендовать.)

К «полу-игровому» тредриперу можно терабайт озу напихать.

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

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

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

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

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

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

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

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

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

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

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

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

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

Но ведь есть ссд с официальным ресурсом в петабайты и гарантией 5 лет.

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

mkfs.ext4 -O ^has_journal <раздел>

Конечно есть, а еще они стоят как самолет.

Журналирование я уже отключил, смотри оп-пост.

Сейчас попробую, что там ребята предложили

http://www.samsung.com/us/business/products/computing/ssd/enterprise/sm863a-9...


Warranty Product
5 years / 6,160TBW

$679.99

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

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

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

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

/dev/sda8 /tmpfs ext4 defaults,noatime,nodiratime,data=writeback,commit=120 0 0

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

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

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

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

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

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

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

Миф.

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

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

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

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

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

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

Нет, если включить опцию упаковки мелких файлов прямо в inode. На 1 seek меньше общее время чтения, а это 10-30 мс.

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

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

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

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

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

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

Программа сама чистит старый кэш, с этим всё ок, эти данные больше 15 минут не живут

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

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

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

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

Рейзер тоже без журнала?

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

Без журнала

SSD за ~12000р будет куда лучше пердолинга с опциями монтирования FS, имхо. Ну или вот этот вариант за ~20000р, если 500ГБ мало.

+1 такую железку в ЗИП и менять по мере износа.

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

Пока выкрутились с raid0, но возьму на заметку идею с дешевым ssd

Random read у SSD явно лучше должен быть, чем у RAID0 из двух HDD.

Попробуйте nilfs2 она как раз для такого, очень быстра на изменения

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