LINUX.ORG.RU

Производительность файловых систем

 , , , , , ,


0

1

Измерение времён разных видов работы в ext2, ext3, ext4dev, jfs, reiserfs и xfs. Распаковка архива, многократные копирования, сборка ядра, измерение уровня фрагментации.

>>> Подробности

>Хотелось Вам увидеть, что XFS плохая -- Вы это и увидели.

Если только у меня libastral слинковался с libbrain. Повторюсь, я ожидал от xfs только тормозов на удалении. Ибо это, как раз, общеизвестный факт. А тест строился ради jfs и ext4.

KRoN73 ★★★★★
() автор топика

Ясно. ext4 будет рулить :)

Demon37 ★★★★
()

Короче райзер рулит и педалит:)

golodranez ★★★★
()

Перед неачалом каждого теста следовало cделать sync && echo 3 > /proc/sys/vm/drop_caches, время каждого теста замерять вместе с sync. А так имеем очень сильное влияние дискового кеша на результаты, т.е. еще один абсолютно не объективный тест, которых в сети великое множество.

Вообщем, за проделанную работу - похвала, за в корне неверную методику измерений - незачёт.

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

>А у меня за 6 лет эксплуатации ext3 фрагментированность не превышает 5.6%. У меня пиписька больше. ага?

У меня фрагментация на корневом рабочем (10Gb/70%used) reiserfs-разделе - 0% :)

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

Тогда бы стоило добавить нагрузку на систему - потребление ресурсов проца, памяти и т.п., надежность от сбоев.

ИБМ давно провела подобные тесты. Сходите на их сайт и найдите. Да, XFS самая лучшая для больших объемов, но по надежности сохранения данных при зависаниях/резетах и по нагрузке на комп jfs лучше всех - меньшая нагрузка, отличная защита от потери данных при очень даже хороших результатах по скорости. В совокупности получается, что для хранения массивов данных она лучше всех.

А то народ потом кричит: "А чтой-то у нас так все тормозит, когда копируем/сидируем и т.д.". Потому и тормозит, что надо не только обращать внимание на скорость единичных операций, а на совокупность факторов.

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

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

>У меня фрагментация на корневом рабочем (10Gb/70%used) reiserfs-разделе - 0% :)

на корневом - это и так понятно, что фрагментация около 0-2% колеблется.

dikiy ★★☆☆☆
()

И всё-таки слишком малый объем данных использован для тестирования имхо по сравнению с размером ОЗУ. Если бы, скажем, объём ОЗУ была бы 256 Мб, а тестирование производилось бы на объёмах читаемых-записываемых данных 20 Гб, результат был бы интереснее.

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

>еред неачалом каждого теста следовало cделать sync && echo 3 > /proc/sys/vm/drop_caches

Точно поможет? :) Я, как писал уже, вопрос сброса кеша решал копированием во временный каталог 2Гб мелочёвки. Но это - долго...

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

KRoN73 ★★★★★
() автор топика

В общем, готовлю сейчас новую версию теста. Принимаются практические пожелания. Во-первых, в тесте будут vfat, ntfs-3g и, вероятно, reiser4 (занимаюсь его подключением).

Тест будет сугубо практический. Берём из /usr/lib все *.so (1.3Гб) многократно копируем/удаляем в тестовую партицию (имитация обновлений системы) и потом много раз читаем случайные файлы. Вроде как, запуск произвольных программ :)

Т.е. в итоге увидим, какая ФС лучше подходит для /usr

Так вот, собственно, вопрос о пожеланиях - может, что-то ещё включить?

Возможно, если не поломает, реализую параллельное чтение в несколько потоков.

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

>Так вот, собственно, вопрос о пожеланиях - может, что-то ещё включить?

Думаю есть смысл судить о фрагментации измерением скорости записи/чтения перед началом теста на пустом разделе (фрагментация 0 %) и после искуственной фрагментации - а то эти голые цифры из скрипта вообще мало о чем говорят, при этом не забивать раздел под завязку - это во первых далеко от действительности и во вторых даст не совсем справедливые результаты.

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

>Так вот, собственно, вопрос о пожеланиях - может, что-то ещё включить?

время с sync при каждом тесте на запись

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

+ количество занятого места на диске после копирования данных, + результаты reiserfs с notail

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

yes, ext3 does suck-by-design. Always has. (C) Andrew Morton

> Старинный вывод: хотите быть уверенными в сохранности, пользуйтесь ext3

Историю с порчей данных на ext3 на ядрах 2.6.18 -- 2.6.20 все уже забыли, как
я вижу. Что ж, напомню:

http://kerneltrap.org/node/7518

А вот еще:

http://bugzilla.kernel.org/show_bug.cgi?id=9692

И в довесок:

https://bugzilla.mozilla.org/show_bug.cgi?id=421482#c123


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

>Перед каждым измерением при наличии в кеше данных, способных повлиять на результат, я делал «сброс кеша» путём копирования на локальный раздел (не тестируемый) 2Гб мелочёвки с удалённого диска.

А сбросить кеш напрямую а не через жо#у не судьба ?


sync
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches

или

sync
echo 3 > /proc/sys/vm/drop_caches

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

>при этом не забивать раздел под завязку - это во первых далеко от действительности

Ну, у кого как :) 

# df /usr
Файловая система     1K-блоков      Исп  Доступно  Исп% смонтирована на
/dev/sda11            17196972  13024284   4172688  76% /usr

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

>А сбросить кеш напрямую а не через жо#у не судьба ?

Теперь - судьба :) Раньше я этого метода просто не знал.

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

> Так вот, собственно, вопрос о пожеланиях - может, что-то ещё включить?

Открыть на запись несколько (~10 -- 20) файлов, и тупо

sleep -- write -- fsync

(примерно это делает текстовый редактор).

На фоне этого запустить копирование нескольких файлов среднего размера
(> объема RAM).

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

Исп 76% - это нормально :) Еще чисто мое мнение для удобства восприятия сделать один вариант полностью в относительных единицах а за эталон (100%) к которому будут приводится остальные результаты взять любую из тестируемых ФС - какая больше понравится (или не понравится :). Сразу будет видно кто кому сливает :)

koTuk
()

Интересно бы посмотреть результаты reiserfs с notail

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

> jfs лучше всех - меньшая нагрузка,

А кого она волнует?

> отличная защита от потери данных

Не хуже и не лучше, чем у других ФС. За исключением одной назойливой "фичи":
если ФС была нештатно отмонтирована, требуется fsck (journal replay делается
из userspace?).

> при очень даже хороших результатах по скорости.

JFS страдает от фрагментации. Потому с "возрастом" ФС производительность
сильно падает. У свежесозданной ФС скорость записи, измернная по

dd if=/dev/zero of=test.img bs=1M count=4096

была около 65 Mb/сек. Через пол-года использования упала до 8 Mb/sec.
Кроме того, fsync на мелких файлах занимал около минуты. Начал
разбираться -- оказалось, что файлы сильно фрагментированы: у файлов
размера ~10 Mb было по несколько тысяч (!) кусков (extents).
Потому -- ну ее нафиг, тем более что дефрагментатор отсутствует в Природе.

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

И еще немаловажно - нужно чтобы скорость чтения/записи в начале раздела была примерно равна скорости чтения/записи в конце раздела. (например чтобы раздел занимал не более 10% общего объема диска)

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

> Так вот, собственно, вопрос о пожеланиях - может, что-то ещё включить?

Угу. Тест файловой системы UFS2 с опцией noatime.
Либо изменить заголовок с "Производительность файловых систем" на "Производительность файловых систем Linux".

iZEN ★★★★★
()

а btrfs забыли протестить? :)

Adjkru ★★★★★
()

Блин, так:

1. Какой IO Schedulers?

2. Какие настройки в ядре файловых систем?

ЗЫ: например, есть ли "Ext3 extended attributes"

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

> может, что-то ещё включить?

Заполнение раздела под завязку малыми файлами, удаление через одного, заполнение в два раза большими, удаление через два, заполнение большими файлами.

Тестирование выборочного чтения (и других операций) больших файлов.

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

> Либо изменить заголовок

Вдумчиво читаем URL

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

JFS умер, все...

Даже в SLES его убрали из официально поддерживаемых.

А вообще тест конечно абсолютно позорно сделан, и "ниочем" (как максимум - "что лучше для плюгавого домашнего компьютера типа хакера васи пупкина) - XFS например на самом деле рвет всех на больших объемах данных (и учитывать необходимо кучу факторов)- простой пример, той же рейзерфс нужно около 15 минут (!!!) чтобы смонтировать большой раздел размером скажем терабайт 15...
Да и ext3 можно оттюнить по самые помидоры- пачка параметров и оптимизаций есть под разые классы задач...

Короче - реально "автор" просто позорится и показывает свою проф. непригодность.

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

>Короче - реально "автор" просто позорится и показывает свою проф. непригодность.

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

ЗЫ: так какой schedules?

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

>простой пример, той же рейзерфс нужно около 15 минут (!!!) чтобы смонтировать большой раздел размером скажем терабайт 15...

On-demand bitmap loading уже в оф.ядре с версии 2.6.19, вылазь из танка

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

>Короче - реально "автор" просто позорится и показывает свою проф. непригодность.

Он старается как знает/может, а ты ничего конкретного не предлагаешь

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

>> народ, а почему xfs так себя плохо показала ?

> Я сам удивился. Не люблю эту ФС,

Может, у вас это взаимно?

eugine_kosenko ★★★
()

В нагрузку (взято с opennet.ru): тестирование ext2, ext3, ext4, reiserfs, reiser4, jfx, xfs, btrfs в iozone, postmark, dbench, maildir и file creation benchmarks на 4-головом Xeon с 4гб памяти и 10k scsi seagate диском 300гб на Adaptec AIC7902 Ultra320:

http://tservice.net.ru/~s0mbre/old/?section=projects&item=fs_contest2

Для Ъ: в postmark рулит btrfs и reiser4, неплохо ext4. iozone random write: ext3/reiser4, read: reiser4, write: reiser4 и btrfs, dbench: ext2 с огромным отрывом, затем ext3 и ext4, file creation: ext2.

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

>JFS умер, все...

JFS оффициально не развивается (да и не поддерживается) уже несколько лет в ядре. Т.е. только багрепорты по нему фиксятся, но настолько медленно, что проще переползти на xfs.

anonymous
()

В общем, готовы две серии данных по новому тесту, уже сугубо практическому - параллельное случайное чтение *.so из /usr/lib. Результаты интересные, особенно в области фрагментирования.

Теперь стоит вопрос визуализации. (Пока вожусь - глядишь, и третья серия подоспеет).

В доке по gnuplot не нашёл подходящего формата диаграмм. Чтобы для каждой ФС по N измерениями построить столбик диаграммы с минимальным, средним и максимальным значением. В MS Excel и OOo Calc таких диаграмм не нашёл тоже :)

В общем, нужно как-то это визуализировать теперь...

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

>А вообще тест конечно абсолютно позорно сделан, и "ниочем"

Ещё раз рекомендую прочитать, о чём же тест. Там всё подробно расписано. Настолько, что твои реплики выдают пока или неумение/нежелание читать, или неспособность к умозаключениям. Глобальные задачи, которые ты почему-то тут видишь, при тесте не ставились. В общем, у Вас галлюцинации...

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

> Смонтированная с параметром ro

Не факт. Дело в том, что журналируемые ФС делают journal replay, несмотря
на ro. Что вполне может привести к потере данных (например, если
половинку с RAID1 массива подмонтировать).

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

>А говорили, что reiser быстрее ext2...

правильно говорили

anonymous
()

Всё конечно хорошо, НО! размонтировался ли после каждой операции раздел дабы сбросить файловый кеш?

Какой планировщик?

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

Абсолютно согласен, я аж удивился, как все тут с серьезными лицами обсуждают результаты этого "теста". 2ГБ - это очень странный объем для такого тестирования. У меня в ноуте трехлетней давности - оперативной памяти 1ГБ. Автор, что Вы измеряли?

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

>А говорили, что reiser быстрее ext2...

Во втором тесте он на случайном чтении *.so из /usr выполняет всё за 71,2-71,3 сек. против 74,5-75,6 сек. у ext2 (три измерения, точнее, третье заканчивается, остались vfat и xfs). В общем, паритет. Для сравнения, такого же порядка величины у jfs, xfs и reiserfs (от 62,6 до 76,8 сек.). А вот reiser4 выполняет тест за 54,9-55,0сек; ntfs-3g за 125,4-125,6сек.

Интересны результаты по уровню фрагментации:

xfs: 0,02-0,03
ntfs-3g: 0,85-1,85
reiser4: 2,18-2,51
ext2: 4,3-5,9
reiserfs: 6,9-8,9
ext3: 14,1-21,1
jfs: 34,0-37,2
vfat: 39,2-40

Фрагментация для ext4dev, как писал ранее, не определяется.

...

Как бы б результаты эти визуализовать... Разброс значений явно не позволяет задействовать простые диаграммы, нужно с тремя значениями... Хотя, конечно, можно их и ручками вписать, с другой стороны. Их всего-то три :)

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