Производительность файловых систем. ext2 vs ext3 vs ext4dev vs jfs vs reiserfs vs xfs.

 
+
-
edit
 

Balancer

администратор
★★★★☆
ext4dev ext3 тесты ntfs jfs компьютеры ntfs-3g reiser4 vfat reiserfs fat32 xfs Linux файловые системы ext2 производительность ext4
Затесался у меня тут раздел пустой на 2Гб и решил я немного побенчить нынешние штатные FS под Linux. Написал скриптик, который пишет в tmpfs ядро Linux, а потом делает проход по циклу по сабжевым FS и:
  • Форматирует раздел под указанную ФС.
  • Распаковывает сорцы ядра из tmpfs на получившийся раздел. Это около 300Мб.
  • Далее заполяет раздел, несколько раз копируя и удаляя каталоги, имитируя работу с диском.
  • Компилирует ядро, предпоследнюю копию при копировании.
  • Делает grep по всем файлам сорцов ядра, ища там определённую последовательность.
  • Далее копирует на раздел 470Мб музыки с домашнего NFS и потом, собственно, что измеряется, делает копию этого каталога на разделе.
  • Смотрит, сколько в конце осталось свободного места.
  • Измеряет уровень фрагментации раздела в конце.
  • Считает время, ушедшее на измерение фрагментации.
  • Удаляет всё, что вышло по rm -rf.

Вот что вышло:



Цифры:
 ext2ext3ext4devjfsreiserfsxfs
Распаковка, сек.30,53331,634,129,565,2
Заполнение, сек./105,18,77,0221,112,8460,23
Компиляция ядра, сек./1066,767,267,867,167,267,7
grep, сек.41,847,245,444,254,742,3
Копирование музыки, сек*109210488108100115
Свободно в конце, Мб.0,0error0,01212837
Фрагментация, %*1013,915n/a25760
Время измерения фрагментации7175,5n/a62,661,861,9
Удаление всего, сек1,53,41,938,15,2197
Общее время, сек./10128,6134,4126,7150,2137,3213,1


Примечения:
  • Железо: P4-3100 no HT, 2Гб RAM, HDD Samsung SP2504C.
  • Система: Gentoo / 2.6.24-r8.
  • Время компиляции было почти во всех случаях идентичным. Эталонная компиляция в tmpfs заняла 668 секунд. Судя по всему, тест упирается в производительность процессора. Позже нужно будет повторить на Core2Duo.
  • Свободное место в тестах ext2 и ext4 в конце, на «музыкальном» тесте было реально равно нулю, а в случае ext3 не влезло несколько файлов. Но переделывать тесты не стал, думаю, это не так принципиально.
  • Фрагментация для ext4 не измерялась, так как скрипт измерения на этой ФС обламывается.

Думаю повторить попозже тест на Core2Duo и, если получится, на 2.6.24 с reiser4.

Точные цифры в архиве лога: http://balancer.ru/files/0806/test.log.bz2
 
+
-
edit
 

Harsky

опытный

хорошие результаты. я года три назад подобный проводил, так что по результатам с тех пор использую ext3 и не мучаюсь проблемой выбора
 
RU Shinkei aka HeoB #12.06.2008 16:28
+
-
edit
 

Shinkei aka HeoB

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

Какой планировщик?
 
RU Balancer #12.06.2008 17:29  @Shinkei aka HeoB#12.06.2008 16:28
+
-
edit
 

Balancer

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

Раздел не размониторвался, кеш сбрасывался копированием 2Гб мелкого мусора в других разделах.

S.a.H.> Какой планировщик?

CFQ.
 
+
-
edit
 

Balancer

администратор
★★★★☆
ntfs-3g vfat fat32 файловые системы производительность компьютеры ext3 Linux jfs reiser4 reiserfs xfs тесты ext2 ext4 ext4dev ntfs
Итак, вторая серия.

Графиков пока нет, так как надо рисовать с диапазонами (я не поленился провести три серии опытов), а я пока это ни в чём не умею, ни в Excel, ни в GNUPlot :)

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

Начну с конца. Чтение, сек.
ext2ext3ext4devjfsntfs-3greiser4reiserfsvfatxfs
74,795,995,776,2125,655,071,3106,071,6
74,585,985,876,7125,454,971,296,362,6
75,695,885,876,8125,554,971,396,371,6



Фрагментация, %
ext2ext3ext4devjfsntfs-3greiser4reiserfsvfatxfs
5,921,1-35,50,852,368,240,00,02
5,514,1-37,21,052,186,939,20,03
4,314,6-34,00,852,518,941,00,02


Остаток свободного места на разделе, Мб
ext2ext3ext4devjfsntfs-3greiser4reiserfsvfatxfs
580,3547,5557,3720,0715,2629,6700,4731,8718,8


И, наконец, первая часть теста - сколько времени отнимала запись раздела, сек.
ext2ext3ext4devjfsntfs-3greiser4reiserfsvfatxfs
232,1249,5238,9250,9261,8208,7207,8261,3318,7
209,0208,9218,7249,7258,7207,9209,0261,3318,8
208,6210,0211,7248,6257,6208,8208,6264,0318,5


Параметры выполнения, как и в первом тесте. Добавлю неотмеченное ранее. Тест проводился в голой консоли, без GUI, после перезагрузки машины, с nice -5. Второй тест, в отличии от первого, проходил при включённом гипертрейдинге процессора. Перед каждым тестом осуществлялся сброс кеша. Число параллельных потоков при чтении/записи - 5. Фрагментирование осуществлялось путём двукратной записи одного и того же файла. Сперва из /dev/zero с половинной длиной, потом - правильным файлом.

Скрипты теста и логи: http://balancer.ru/files/0806/fs-test2.tar.bz2
 
+
-
edit
 

Balancer

администратор
★★★★☆
В общем, по результатам этого теста, я теперь в раздумьях по поводу переползания на reiser4 :) Для /usr - просто рулит...

Одна засада - если припрёт поработать с LiveCD, боюсь, что в той же Бубунте поддержки reiser4 не будет :-/

resierfs (т.е. 3-й) и xfs показали на чтении /usr паритет, но xfs меньше фрагментируется.

ext3, ext4dev и jfs идут на третьем месте. При этом jfs показывает чудовищную фрагментируемость...
 
+
-
edit
 

Harsky

опытный

Balancer> В общем, по результатам этого теста, я теперь в раздумьях по поводу переползания на reiser4 :) Для /usr - просто рулит...
у тебя так активно меняется /usr? ;)
 
+
-
edit
 

Balancer

администратор
★★★★☆
Harsky> у тебя так активно меняется /usr? ;)

Неужели я НАСТОЛЬКО невнятно пишу ЦИФРЫ? :) Речь идёт о случаном многопоточном чтении. Если в таблицу не посмотрел - у reiser4 этот тест выполняется стабильно за 55 секунд. В то время, как следующее за этим лучшее время - 62,6сек. у xfs при типичном - 71,6сек.

Это очень приличный выигрышь. И только на одном чтении (на записи xfs оказывается в полной попе).
 
+
-
edit
 

Harsky

опытный

нет, это я неверно посмотрел. результаты чтения тупо перенес на запись
25% выигрыша по скорости - цифра приличная, но так как ни о какой разнице на порядок речи не идет, то останусь при своем мнении. от добра добра не ищут, ext3 - наше все ;)
тем более что характер нагрузки на тот же /usr таков, что на интегральную производительность компа (да и сервера) это мало скажется.
 
+
-
edit
 

Balancer

администратор
★★★★☆
Harsky> 25% выигрыша по скорости - цифра приличная, но так как ни о какой разнице на порядок речи не идет, то останусь при своем мнении. от добра добра не ищут, ext3 - наше все ;)

Только с ext3 разница выходит не в 25%, а в 70+% :) Т.е. уже почти вдвое. Мой опыт говрит, что начинаешь ощущать заметное ускорение, когда разница составляет около 20%.

Harsky> тем более что характер нагрузки на тот же /usr таков, что на интегральную производительность компа (да и сервера) это мало скажется.

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

На днях попробую поменять /usr на reiser4 и посмотрю, как изменится время загрузки системы :)
 
+
-
edit
 

Harsky

опытный

примерно на +70% -(время восстановления из бэкапа) ;)
странно, почему на чтение между ext3 и ext2 такая разница?
с какими опциями монтировал ext2, ext3 и reiser4?
 
+
-
edit
 

Balancer

администратор
★★★★☆
Harsky> с какими опциями монтировал ext2, ext3 и reiser4?

Исключительно дефолтовые.
 
+
-
edit
 

Harsky

опытный

noatime было или нет?
linux под рукой нет, вот и спрашиваю
 
+
-
edit
 

Balancer

администратор
★★★★☆
Harsky> noatime было или нет?

Не было. noatime - недефолтовая настройка.

Вообще, в логах опции монтирования отмечены:
code text
  1. /dev/sda6 on /mnt/fs-test type ext2 (rw)
  2. /dev/sda6 on /mnt/fs-test type ext3 (rw)
  3. /dev/sda6 on /mnt/fs-test type ext4dev (rw)
  4. /dev/sda6 on /mnt/fs-test type jfs (rw)
  5. /dev/sda6 on /mnt/fs-test type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
  6. /dev/sda6 on /mnt/fs-test type reiser4 (rw)
  7. /dev/sda6 on /mnt/fs-test type reiserfs (rw)
  8. /dev/sda6 on /mnt/fs-test type vfat (rw)
  9. /dev/sda6 on /mnt/fs-test type xfs (rw)
 
+
-
edit
 

Harsky

опытный

попробуй
может быть и менять ничего не потребуется, легкий тюнинг поправит ситуацию. ну и опции журналирования имеет смысл покрутить.
есть еще одна мысль, которая только теперь в голову пришла. если фс можно эксплуатировать в ro, то стоит потестить ее на чтение смонтировав с этой опцией. вдруг там под кеш память по другому распределяется?
 
+
-
edit
 

Balancer

администратор
★★★★☆
usr в r/o - это не лучшее решение :) А noatime несколько ускорит, полагаю, но всех и совсем немного. У меня /usr именно с noatime и смонтирован, но это скорее просто бесплатная припарка. Прибавки в скорости не заметно.
 
+
-
edit
 

Harsky

опытный

Balancer> usr в r/o - это не лучшее решение :)
это почему? на сервере эта фс прямо скажем, не часто меняется. и всегда с подачи оператора
ну что ж, reiser, так reiser... глядишь ганс за казенный счет его начнет улучшать бешеными темпами ;)
 
+
-
edit
 

poige

новичок
[…]
Balancer> Раздел не размониторвался, кеш сбрасывался копированием 2Гб мелкого мусора в других разделах.

Есть такой sysctl — vm.drop_caches (см. Documentation/filesystems/proc.txt)
 
RU Balancer-as-user #13.06.2008 12:15  @poige#12.06.2008 21:21
+
-
edit
 

Balancer-as-user
Balancer-пользователь

старожил
poige> Есть такой sysctl — vm.drop_caches (см. Documentation/filesystems/proc.txt)

Меня уже на ЛОРе научили :) Второй тест пользуется системными средствами сброса кеша.
... чтобы понять рекурсию, нужно сперва понять рекурсию ...  
+
-
edit
 

Balancer

администратор
★★★★☆
Harsky> это почему? на сервере эта фс прямо скажем, не часто меняется.

Не знаю, как в других системах, а в Gentoo /usr обновляется каждый день :) Впрочем, в той же Убунту, в общем, тоже.
 
RU aldebober #13.06.2008 16:00
+
-
edit
 

aldebober

новичок
Вы можете повторить тесты с определенными размерами файлов? Интересует конкретно скорость в МБ/с различными размерами отдельно по 10, 100 и 1000 МБ при линейной записи/чтении, в потоках и смешанные потоки чтения и записи. Думаю xfs оправдается на файлах от 1GB )))
Могу помочь с графиками в gnuplot.
 
+
-
edit
 

Harsky

опытный

Harsky>> это почему? на сервере эта фс прямо скажем, не часто меняется.
Balancer> Не знаю, как в других системах, а в Gentoo /usr обновляется каждый день :) Впрочем, в той же Убунту, в общем, тоже.
дело привычки. по мне - сервер должен работать, а не emerge в кроне пускать каждые 15 минут
 
RU Balancer #13.06.2008 18:31  @aldebober#13.06.2008 16:00
+
-
edit
 

Balancer

администратор
★★★★☆
aldebober> Вы можете повторить тесты с определенными размерами файлов?

Пока только с мелочью. «Бесхозный» раздел только на 2Гб. Ту же торрент-раздачу на таком не сымитируешь. На ЛОРе сейчас отвечал, сюда кросс-пост:

По поводу XFS - думаю тут, не воткнуть ли второй винт, отрезав раздел гигов на 30 и пощупать имитацию торрент-раздачи. Только как - не придумал ещё. В голову приходит заполнить 1.4Гб РИПами, взять потоков 10 и дёргать случайные куски из случайных мест файлов. Насколько такой тест будет адекватным? Вопрос только - как средствами shell правильно обращаться в середину файла? tail/head, полагаю, это не то получится.
 
+
-
edit
 

Balancer

администратор
★★★★☆
Harsky> дело привычки. по мне - сервер должен работать, а не emerge в кроне пускать каждые 15 минут

Да, дело привычки. Уверяю тебя, что после первого же серьёзного взлома через невовремя обновлённую библиотеку, привычки начнут меняться :D А у меня это изменение произошло в 2003-м в шоковом режиме, когда Slapper домашнюю машинку мне взломал и за 4 часа нагенерил трафика больше чем на мою месяяную зарплату :D ($500 тогда)
 
+
-
edit
 

Harsky

опытный

у меня сервера только изнутри ломать можно, а за это служба безопасности спасибо не скажет... ;)
 

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru