Сравнение I/O файловых систем Ext4, XFS, JFS

[Дмитрий Беляев]

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

                        Ext4                XFS                JFS
-------------------------------------------------------------------------------
Чтение rnd, default    2.5939 Gb/sec      2.3858 Gb/sec      2.4662 Gb/sec
-------------------------------------------------------------------------------
Чтение rnd, ++          2.6236 Gb/sec      2.4141 Gb/sec      2.4991 Gb/sec
-------------------------------------------------------------------------------
Чтение seq, default    264.05 Mb/sec      258.14 Mb/sec      260.17 Mb/sec
-------------------------------------------------------------------------------
Чтение seq, ++          265.05 Mb/sec      258.21 Mb/sec      259.78 Mb/sec
-------------------------------------------------------------------------------
Запись rnd, default    1.7965 Mb/sec      719.45 Kb/sec      599.78 Kb/sec
-------------------------------------------------------------------------------
Запись rnd, ++          2.8501 Mb/sec      2.6147 Mb/sec      3.5546 Mb/sec
-------------------------------------------------------------------------------
Запись seq, default    81.196 Mb/sec      83.392 Mb/sec      65.594 Mb/sec
-------------------------------------------------------------------------------
Запись seq, ++          89.803 Mb/sec      83.261 Mb/sec      66.166 Mb/sec
-------------------------------------------------------------------------------

Описание тестов здесь: http://www.devbelyaev.ru/index/bench_io_fs

 

[fixxxer]

JFS - nointegrity

Тогда уж сравнивай с ext4 без журнала.

tune2fs -O ^has_journal

 

[Дмитрий Беляев]

Тогда уж сравнивай с ext4 без журнала.

tune2fs -O ^has_journal

Та что ++ она с отключенным журналированием.
А так ext4 фактически идет без журнала по-умолчанию. Журналируется только мета-информация системных файлов.

 

[c0dex]

Переместил сюда.

 

[Дмитрий Беляев]

Вы там видео пишете что-ли на диск? Очень позновательно, пышите исчо.

В контесте проекта на котором это гонятеся - там куча статики типа картинок, иконок и тектовых файлов. От 1К до 100К. И их стало очень много. Порядка 50 млн, где-то. И все бы хорошо, если бы это добро не менялось. Но оно меняется. И быстро и часто.

 

[Дмитрий Беляев]

Еще есть ReiserFS, но не в контексте производительности. Ее фишка в том, что она умеет хранить больше 1 файла на 1 блок. Т.е. занимает меньше места на диске. Но судя по документации производительность резко снижается в таком случае. Как руки дойдут - потестирую, поделюсь.

 

[MiksIr]

В контесте проекта на котором это гонятеся - там куча статики типа картинок, иконок и тектовых файлов. От 1К до 100К. И их стало очень много. Порядка 50 млн, где-то. И все бы хорошо, если бы это добро не менялось. Но оно меняется. И быстро и часто.

Вы не поняли мой вопрос. Вы провели однотредовый тест. У вас один процесс предполагает писать? Конкурентность может польностью поменять картину. Характер работы с диском тоже может быть разным у разных процессов. Sysbench полезная штука, но не дает всей картины, даже если запустите много тредов.. + Драйвера меняются от ядра к ядру и довольно сильно меняют картину. В общем бесполезный, я бы даже сказал - вредный тест, ибо случайные люди могут и не понимать все этого, а тут у вас циферки.

 

[Дмитрий Беляев]

Вы не поняли мой вопрос. Вы провели однотредовый тест. У вас один процесс предполагает писать? Конкурентность может польностью поменять картину. Характер работы с диском тоже может быть разным у разных процессов. Sysbench полезная штука, но не дает всей картины, даже если запустите много тредов.. + Драйвера меняются от ядра к ядру и довольно сильно меняют картину. В общем бесполезный, я бы даже сказал - вредный тест, ибо случайные люди могут и не понимать все этого, а тут у вас циферки.

Смотрите опции, которые были изменены. Совершенно очевидно, что отключение журналирования, увличение время коммита, отключение время доступа и т.п. увеличит скорость записи на диск. Хоть для 1 потока, хоть для 100. Фундаментальный принцип: меньше операций дает большую скорость. И это никогда не изменится. Даже на квантовых компьютерах.
А случайным людям вообще не надо туда лезть. Поставил дефолтную ext4 и радуйся.

 

[MiksIr]

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

 

[Активист]

Ваше сравнение неверно. Во первых разные ФС разные задачи, разные типы данных (множество мелких файлов или скажем хранение больших архивов). В ваших тестах производительность всегда будет приближаться к производительности самих дисков, в реальных условиях иначе, например вот тесты http://zenux.ru/articles/2/ . Отключение журналирования это не выход, это сцуко FAT 32.

 

[Дмитрий Беляев]

Ваше сравнение неверно. Во первых разные ФС разные задачи, разные типы данных (множество мелких файлов или скажем хранение больших архивов). В ваших тестах производительность всегда будет приближаться к производительности самих дисков, в реальных условиях иначе, например вот тесты http://zenux.ru/articles/2/ . Отключение журналирования это не выход, это сцуко FAT 32.

Статья хорошая, но что сразу бросилось в глаза - тест для апача немного странный. Апач флашит данные в лог пачками и с задержкой, что абсолютно логично, чтобы не убивать ио диска. Даже если бы они натравили логи на shared memory результаты теста бы не изменились.
> ФС разные задачи, разные типы данных
И что же такое хотели хранить IBM и Silicon Graphics в своих фаловых системах?
> Отключение журналирования это не выход, это сцуко FAT 32
Отключено не только журналирование, а еще много чего. Для основного диска этого делать не стоит. А вот для статики - в самый раз.

 

[fixxxer]

Отключение журналирования это не выход, это сцуко FAT 32.

Есть случаи, когда это уместно. Например, гугл так делает в своем кластере на серверах, которые не являются постоянным хранилищем. Если ФС повреждена - сервер просто ребутается и ФС разворачивается целиком заново (PXE boot и так далее).

Но, конечно, для случайного пользователя, который загуглил про производительность ФС и головой думать не хочет - это крайне вредный совет.

 

[Активист]

Есть случаи, когда это уместно. Например, гугл так делает в своем кластере на серверах, которые не являются постоянным хранилищем. Если ФС повреждена - сервер просто ребутается и ФС разворачивается целиком заново (PXE boot и так далее).

Но, конечно, для случайного пользователя, который загуглил про производительность ФС и головой думать не хочет - это крайне вредный совет.

Я в ext3 как-то уперся в производительность, не отключал журнал, а настроил сброс журнала через 5 секунд кажется. Один хрен в ЦОДе с 2008 года ни разу сервера не выключали, да и не зависали они)