старые » Наука и техника » Компьютерный » Linux и СПО » Очередной бенч. Производительность разных FS для /usr

Очередной бенч. Производительность разных FS для /usr

Теги:компьютеры, Linux, тесты, производительность, benchmark, ext3, jfs, reiser4, reiserfs, xfs
 
Новый опрос Новый фотосет Новая тема Написать сообщение в тему
RU Balancer #13.11.2008 21:27
+
-
edit
 

Balancer

администратор
★★★★★
ext3 benchmark тесты jfs reiser4 reiserfs компьютеры xfs Linux производительность
На днях заметно стал тормозить emerge.

Небольшое исследование быстро показало, что тормозит интенсивный доступ к /usr, который у меня под Reiser4.

В итоге по-быстрому была проведена серия тестов по влиянию разных FS в /usr на скорость запуска программ и время выполнения ldconfig.



Вот, на графике время выполнения ldconfig для разных FS.

(Reiser4 - производительность свежеразвёрнутой Reiser4, Reiser4.old - проработавшей в реальных условиях несколько месяцев).

Таблица с точными цифрами:
ldconfigminiominmaxiomax
ext300:13,8000:13,4000:17,9000:17,40
jfs00:08,6000:08,1000:12,6000:12,10
reiser400:09,1000:08,5000:12,7000:12,10
reiser4.old00:19,5000:18,9000:26,8000:26,20
reiserfs00:15,2000:14,7000:19,9000:19,30
xfs00:08,4000:08,0000:11,3000:10,90


Время ввода-вывода считалось как real-(user+sys).

Измерение проводилось после сброса кеша по
sync && echo 3 > /proc/sys/vm/drop_caches.

Из шести измерений первое отбрасывалось, из последующих пяти брались минимальное и максимальное знаения.

Дальше - практика. Время запуска Firefox:


Firefoxminiominmaxiomax
ext300:06,7000:05,6000:08,3000:07,20
jfs00:07,5000:06,4000:08,9000:07,70
reiser400:06,5000:05,4000:09,7000:08,60
reiser4.old00:08,3000:07,1000:12,5000:11,40
reiserfs00:06,8000:05,7000:10,5000:09,30
xfs00:06,6000:05,5000:07,7000:06,60


SeaMonkey:

SeaMonkeyminiominmaxiomax
ext300:05,2000:04,4000:05,4000:04,60
jfs00:05,3000:04,7000:07,0000:06,40
reiser400:05,2000:04,4000:05,7000:04,80
reiser4.old00:05,9000:05,2000:08,3000:07,60
reiserfs00:04,8000:04,1000:06,6000:05,90
xfs00:03,4000:02,8000:05,9000:05,10


Amarok:

Amarokminiominmaxiomax
ext300:08,8000:07,9000:09,3000:08,50
jfs00:08,4000:07,6000:09,6000:08,80
reiser400:07,0000:06,1000:08,8000:07,90
reiser4.old00:09,0000:08,1000:10,7000:09,90
reiserfs00:07,1000:06,3000:08,3000:07,50
xfs00:06,9000:06,1000:08,2000:07,40


Наконец, до кучи, уровень фрагментации после простого копирования на /usr:
FSфайлов всегофрагментов файловфрагментировано файлов% фраг.в среднем фраг. на файл
jfs73880474495059750,81
reiser4.old738804816187308454,11,1
reiser4739055746858742211
reiserfs739055782529159072,11
xfs7390557391194001


Уровень фрагментации ext3 измерить не удалось, программа выдавала серию ошибок.

ext4dev в тест не попала по причине постоянных падений при попытке копирования на неё данных /usr.

...

Выводы. Однозначными лидерами показали себя свежая Reiser4 и XFS. Но reiser4, как оказалось, не лишён проблемы, с которой началась эта тема. Посмотрим, как будет дело обстоять с длительной эксплуатацией XFS. Её пока и выбрал для /usr :)
 
RU Glebus #14.11.2008 08:06  @Balancer#13.11.2008 21:27
+
-
edit
 

Glebus

новичок
Balancer> На днях заметно стал тормозить emerge.

У меня /home и /usr на xfs с 2002 года, ныне --- несколько десятков машин. На более слабых машинах, выигрыш в производительности был виден сразу и без вариантов.

Заметных проблем не было (пара машин работает с 04 года в режиме 12/7/24, были аварийные отключения питания)
 
RU Balancer #14.11.2008 08:44  @Glebus#14.11.2008 08:06
+
-
edit
 

Balancer

администратор
★★★★★
Glebus> Заметных проблем не было (пара машин работает с 04 года в режиме 12/7/24, были аварийные отключения питания)

Ну, для /usr падения xfs не страшны, он почти всё время в R/O, а вот в /home у меня пропажи при падении питания были. Например, почти всегда накрывается файл сессий Оперы. При чём, не раз уже ругался, чисто XFS-ная фича. Повреждённые файлы не удаляются, не перекидываются куда-то, не усекаются, наконец, а просто забиваются нулями. С виду как живой, а внутри - одни нули :)
 
RU Спокойный_Тип #14.11.2008 09:25
+
-
edit
 

Спокойный_Тип

старожил
★☆
на линухе юзаю только ext2/ext3 :-D
олдскул рулит
 7.07.0
RU Balancer #14.11.2008 12:30
+
-
edit
 

Balancer

администратор
★★★★★
В свою копилку, чтобы потом не подбирать параметры заголовков окон по новой. Как измерялось время запуска:

code text
  1. rm ~/.mozilla/firefox/nv80x0ua.default/{parentlock,XPC.mfasl,sessionstore.js}; time firefox & while [[ $(xwininfo -root -tree|grep 'Mozilla Firefox' |wc -l) == 0 ]]; do echo -n . ; done; killall firefox
  2.  
  3. time seamonkey & while [[ $(xwininfo -root -tree|grep SeaMonkey|wc -l) == 0 ]]; do echo -n . ; done; killall seamonkey-bin
  4.  
  5. time amarok & while [[ $(xwininfo -root -tree|grep amaroK |wc -l) == 0 ]]; do echo -n . ; done; killall amarokapp
 
RU HolyBoy #09.04.2009 21:44
+
-
edit
 

HolyBoy

аксакал
★
Нашлись люди, которые протестировали файловые системы для флешек: [Phoronix] GNU/Linux Hardware Reviews, Articles, & Gaming


Краткий итог: XFS разрывает. :)
 
RU Balancer #14.04.2009 07:45  @HolyBoy#09.04.2009 21:44
+
-
edit
 

Balancer

администратор
★★★★★
HolyBoy> Краткий итог: XFS разрывает. :)

У меня в ядре тут btrfs и ext4 готовы. Надо будет время выкроить, самому новую серию тестов прогнать :)
 
RU HolyBoy #03.05.2009 22:45  @Balancer#14.11.2008 08:44
+
-
edit
 

HolyBoy

аксакал
★
Balancer> Повреждённые файлы не удаляются, не перекидываются куда-то, не усекаются, наконец, а просто забиваются нулями. С виду как живой, а внутри - одни нули :)

Вот, я нашёл обоснование такого поведения:
В ReiserFS неожиданная перезагрузка может иметь результатом попадание в изменяемый файл фрагмента из когда-то удаленного файла. Помимо очевидной потери данных, гипотетически это может иметь более серьезные последствия. В XFS имеется гарантия, что любые "недозаписанные" блоки заполнены нулями. Так как блоки с нулевыми байтами в системных файлах игнорируются, устраняется лазейка в безопасности.
 
© Linux - Advanced filesystem implementor's guide, Part 9


Ну что тут можно сказать... Гениально! :F

Кстати, это XFS отжирает гигов 30 на 400-гиговом диске под журнал?
 
NO Balancer #04.05.2009 09:47  @HolyBoy#03.05.2009 22:45
+
-
edit
 

Balancer

администратор
★★★★★
HolyBoy> Вот, я нашёл обоснование такого поведения: ©

Дык, это давно известно. Только непонятно, повторюсь, почему бы в такой ситуации файлы повреждённые не помечать. Или усекать, или сносить в lost+found :)

HolyBoy> Кстати, это XFS отжирает гигов 30 на 400-гиговом диске под журнал?

На журнал она жрёт намного меньше, чем та же ext3/4. Забитый XFS-раздел не влезает в такого же размера ext3/4. А так - у меня в ряде тестов занятый объём (одними и теми же файлами) указан.
 
RU Balancer #04.05.2009 11:33  @Balancer#04.05.2009 09:47
+
-
edit
 

Balancer

администратор
★★★★★
HolyBoy>> Кстати, это XFS отжирает гигов 30 на 400-гиговом диске под журнал?
Balancer> На журнал она жрёт намного меньше, чем та же ext3/4. Забитый XFS-раздел не влезает в такого же размера ext3/4. А так - у меня в ряде тестов занятый объём (одними и теми же файлами) указан.

Вот, навскидку один из тестов, заполнение /usr:

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

  ext4dev ext3 тесты ntfs jfs компьютеры ntfs-3g reiser4 vfat reiserfs fat32 xfs Linux файловые системы ext2 производительность ext4 Затесался у меня тут раздел пустой на 2Гб и решил я немного побенчить нынешние штатные FS под Linux. Написал скриптик, который пишет в tmpfs ядро Linux, а потом делает проход по циклу по сабжевым FS и: Форматирует раздел под указанную ФС. Распаковывает сорцы ядра из tmpfs на получившийся раздел. Это около 300Мб. Далее заполяет раздел, несколько раз копируя и удаляя каталоги, имитируя работу с диском. // Дальше — www.balancer.ru
 
Остаток свободного места на разделе, Мб
ext2ext3ext4devjfsntfs-3greiser4reiserfsvfatxfs
580,3547,5557,3720,0715,2629,6700,4731,8718,8
 

в начало страницы | новое
старые » Наука и техника » Компьютерный » Linux и СПО » Очередной бенч. Производительность разных FS для /usr
Copyright © Balancer 1997..2018
Создано 13.11.2008
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru