Форум русскоязычного сообщества Ubuntu


Увидели сообщение с непонятной ссылкой, спам, непристойность или оскорбление?
Воспользуйтесь ссылкой «Сообщить модератору» рядом с сообщением!

Автор Тема: Cравнение производительности BTRFS и EXT4 на HDD в Ubuntu 16.04 alpha  (Прочитано 15403 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн thunderamur

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 6846
    • Просмотр профиля
Решил вот лично посмотреть как обстоят дела с разработкой перспективной ФС BTRFS, которую многие уже пробовали ранее, но она была очень сыра, тормозила и разваливалась. Теперь же все указывает на то, что многие проблемы уже решены. Предлагаю вашему вниманию сравнение производительности и эффективности использования дискового пространства 2-мя ФС - основной EXT4FS и перспективной BTRFS.

Тестовый стенд:
Операционная система: Ubuntu 16.04 alpha.
Жесткий диск: Toshiba Deskstar 1TB 7200 32MB
ОЗУ: 8 ГБ DDR3 1333 MHz
Процессор: Intel Core i5-4670
Мат. плата: Asrock Z97 Pro4 (2.20)

*Примечание: Расположены 2 ОС на разных ФС рядом, на одном диске близко к началу диска. EXT4 расположена ближе к началу диска, т.е. находится в чуть более выгодном положении, чем её оппонент BTRFS. Размеры разделов - 20 GiB.

1. Скорость установки ОС.
Довольно хороший тест, т.к. во время установки ОС происходят операции чтения, записи, копирования и удаления файлов.



Как видно на графике разница во времени установки не превышает 5%. Разница очень маленькая, чтобы принимать её в рассчет, все-таки для более точных замеров нужно провести несколько установок, но думаю нам доли процентов не важны.
Также по результатам этого теста можно с уверенностью заявлять, что былые проблемы с производительностью при работе пакетной системы решены.

2. Время загрузки ОС.
Никто не хочет, чтобы ОС загружалась долго. Данный тест показывает скорость чтения с ФС.



Вот здесь уже преимущество BTRFS на лицо, с ней ОС загружается заметро быстрее, особенно при применении алгоритмов сжатия.


3. Эффективность алгоритмов сжатия BTRFS.
EXT4 в данном тесте не участвует т.к. не умеет сжимать данные. Поэтому её результат можно оценить по результату BTRFS без сжатия.



LZO позволяет сэкономить ~35% от размера не сжатого файла.
ZLIB добавляет к ним ещё ~20%, но имеет серьезный недостаток, о нем далее.


4. Время конвертации (с различными алгоритмами сжатия) установленной ОС.
Здесь мы сравниваем эффектиность различных алгоритмов сжатия, чтобы выбрать наиболее подходящий.



А вот и недостаток, скорость работы. Для zlib требуется очень мощный процессор и все равно это не гарантирует того, что производительность в него не упрется.


5. Максимальная нагрузка на ЦПУ во время конвертации.
Особенно важно для слабых ПК и тем более для ноутбуков, работающих от батареи.



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


Вывод:
BTRFS в общем работает быстрее EXT4, особенно при наличии достаточного мощного процессора для включения хотя бы lzo-сжатия. zlib-сжатие считаю уместным лишь в крайне редких случаях, когда нужно экономить место. В общем этот алгоритм в разы медленнее lzo и в разы больше нагружает ЦПУ, а по экономии дискового пространства дает профит всего 20%.
Я считаю, что BTRFS стоит использовать на HDD, т.к. она делает работу с ними быстрее. За исключением случаев хранения ценных данных и т.н. промышленного использования, в силу открытого вопроса по надежности и стабильности новой ФС.
« Последнее редактирование: 13 Ноября 2015, 19:43:02 от thunderamur »

Оффлайн Tamer4

  • Активист
  • *
  • Сообщений: 695
    • Просмотр профиля
Спасибо, буду иметь ввиду в апреле 2016 года.
А можно посмотреть
hdparm -t /dev/sdXну и на каком HDD єто запускалось, Toshiba Deskstar 1TB 7200 32MB?
« Последнее редактирование: 13 Ноября 2015, 20:35:44 от Tamer4 »

Оффлайн thunderamur

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 6846
    • Просмотр профиля
Да, именно этот ЖД, самый обычный.

Оффлайн Tamer4

  • Активист
  • *
  • Сообщений: 695
    • Просмотр профиля
Решил провести простой тест скорости, вЬІделил 100ГБ в конце 2TB WD Red 5400rpm 64MB.
Увеличение скорости btrfs по сравнению с ext4
на Xubuntu 14.04.3 - 10%
на Ubuntu 16.04 - 20%
тест проводил командой
dd if=/dev/sdb3 of=iotestfile bs=1M count=1000Попробую перевести свою файлопомойку на btrfs.

Оффлайн thunderamur

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 6846
    • Просмотр профиля
Tamer4,
Файлопомойку пока очкую, хоть и бекапы в облаке самого важного, все равно пока не уверен.

ты compress использовал? Если да, какой алгоритм lzo или zlib?

Оффлайн Tamer4

  • Активист
  • *
  • Сообщений: 695
    • Просмотр профиля
Tamer4,
Файлопомойку пока очкую, хоть и бекапы в облаке самого важного, все равно пока не уверен.

ты compress использовал? Если да, какой алгоритм lzo или zlib?
Компрессию не использовал, нет надобности - из 2ТБ занимается 500-700ГБ, причем четветь из єтого - временное.
Фалопомойка у меня натуральная :) (натянуто с интернетов всякого), поєтому мне не страшно.
Кстати в 14.04 провел тестЬІ разнЬІми блоками:
4КБ - 208МБ/с
64КБ - 184МБ/с
2МБ - 149МБ/с
Всего записЬІвалось от 1ГБ даннЬІх.
Єх жаль нету у меня уже гигабитного интернета, я бЬІ щас затестил...

Вобщем я немного ох..лаждаюсь от результатов, интересно будет потом поставить на мой системнЬІй WD Velociraptor 10000rpm, которЬІй бЬІл на равнЬІх с OCZ Vertex 2, и єто еще на NTFS.

Оффлайн thunderamur

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 6846
    • Просмотр профиля
ради интереса включи сжатие, потести запись и чтение, только сначала запись, чтобы читать потом сжатые данные

Оффлайн Tamer4

  • Активист
  • *
  • Сообщений: 695
    • Просмотр профиля
ради интереса включи сжатие, потести запись и чтение, только сначала запись, чтобы читать потом сжатые данные
       Без сжатия   lzo       zlib
4КБ -  208МБ/с      195МБ/с   152МБ/с
64КБ - 184МБ/с      158МБ/с   135МБ/с
2МБ -  149МБ/с      122МБ/с   113МБ/с
P.S. делал по 3-4 теста для каждого размера блока и вЬІбирал минимальное значение.
« Последнее редактирование: 15 Ноября 2015, 11:16:04 от Tamer4 »

Оффлайн RUstorm

  • Активист
  • *
  • Сообщений: 701
    • Просмотр профиля
Спасибо, интересно  т.к уже некоторое время присматриваюсь к BTRFS

Оффлайн thunderamur

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 6846
    • Просмотр профиля
Tamer4,
выходит у тебя производительность снизилась, а ЦПУ какой?

Tamer4,
еще влияет какие данные идут, если хорошо сжимаемые, то будет буст, если нет, то наоборот.

Например можешь посмотреть разницу

thunder@thunder-pc:~$ sudo dd if=/dev/sda of=iofile bs=1M count=1000
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 3,25461 c, 322 MB/c

thunder@thunder-pc:~$ sudo dd if=/dev/sdb of=iofile2 bs=1M count=1000
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 3,12292 c, 336 MB/c

thunder@thunder-pc:~$ sudo dd if=/dev/sdb5 of=iofile3 bs=1M count=1000
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 2,03809 c, 514 MB/c

thunder@thunder-pc:~$ sudo dd if=/dev/zero of=iofile4 bs=1M count=1000
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 0,270193 c, 3,9 GB/c

1 - чтение с SSD с windows (это определяет какие файлы лежат, т.е. сжимаемость потока), запись на HDD btrfs lzo.
2 - чтение с SSD c ubuntu
3 - чтение с SSD c не используемого раздела, как видно уперлось в скорость считывание с SSD.
4 - чтение нулей с /dev/zero, сжимаются отлично, поэтому скорость записи 1 гигабайта 3.9 ГБ/с, было бы 10 гигабайт, было бы ещё быстрее, а все потому, что по факту на диск пишутся немного данных. df показывает разницу 35 МБ, т.е. 1 гигабайт нулей, после сжатия, на диске занял в 30 раз меньше места.
« Последнее редактирование: 15 Ноября 2015, 14:49:49 от thunderamur »

Оффлайн Tamer4

  • Активист
  • *
  • Сообщений: 695
    • Просмотр профиля
Процессор Core i5-4670, ну и как я писал вЬІше єто тест на Xubuntu 14.04.3, ядро 3.19.0-33, а в Ubuntu 16.04 alpha - 4.2.0-16.
Допишу пару сотен гигов в файлопомойку попробую и на 16.04. Вечером протестирую - отпишусь. Поидее должна бЬІть разница.
Хотя она несущественна для файлопомойки. И дополнительнЬІе даже 50МБ/с погодЬІ не сделают, потому что в IOPSях ХДД никак не догонит ССД.

Пользователь решил продолжить мысль [time]16 Ноябрь 2015, 03:24:59[/time]:
На Ubuntu 16.04 alpha (core 4.2.0-19):
      Без сжатия   lzo       zlib
4K  - 280МБ/с      237МБ/с   206МБ/с
64K - 217МБ/с      203МБ/с   188МБ/с
2M  - 171МБ/с      165МБ/с   154МБ/с
Потери все же есть. Хотя сначала при 1-1.6ГБ даннЬІх он начал вЬІдавать чуднЬІе резульитатЬІ в районе 400-1600МБ/с. Увеличил обьем даннЬІх до 3.3-4.2ГБ - все пришло в порядок.
Поставил для себя по умолчанию режим без сжатия. Попробовал скопировать с другого ХДД файл 4ГБ - скорость держалась, не падая на 150МБ/с. Вот єто впринципе меня и устраивает в btrfs. Потому как обратно (на WD 10000rpm ext4) єтот файл копировался со скоростью уменьшающейся от 130 в начале до 110МБ/с в конце.

Пользователь решил продолжить мысль 16 Ноября 2015, 07:36:05:
Всвязи с тем, что файлопомойку перенес на btrfs пришлось в плеере удалять старЬІй путь к папке с музЬІкой и добавлять новЬІй. Так плеер обновил библиотеку секунд за 15, на ext4 єто бЬІло подольше, секунд 40-50. Фонотека 1711 треков 13.8ГБ.
Получается скорость чтения 942МБ/с... ЧЯДНТ? :o
« Последнее редактирование: 16 Ноября 2015, 07:36:05 от Tamer4 »

Оффлайн AnrDaemon

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28349
    • Просмотр профиля
Плеер же не читает файлы целиком. Скорее всего он только расположение считывает.
Так что разница будет за счёт разницы организации самой FS.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн thunderamur

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 6846
    • Просмотр профиля
Tamer4,
Как уже сказал AnrDaemon плеер файлы целиком не читает, только находит их и считывает информацию о треке, а это лишь маленькая часть файла. Быстрее видимо от того, что организация файлов B-TREE позволяет их быстрее находить на диске, чем организация файлов в EXT4. В общем, выходит не зря её пилили :) EXT4 ведь тоже не сразу 4 стала)

Пользователь решил продолжить мысль 16 Ноября 2015, 16:27:12:
Tamer4,
Ах да, еще про то, что со сжатием у тебя медленее. Ты ведь проверяешь на не сжимаемых данных, ФС сначала сжимает проверяет результат - лучше не стало и пишет как есть, в итоге вместо буста некоторое замедленее. Я думаю в этом дело.
« Последнее редактирование: 16 Ноября 2015, 16:27:12 от thunderamur »

Оффлайн Tamer4

  • Активист
  • *
  • Сообщений: 695
    • Просмотр профиля
Ах да, еще про то, что со сжатием у тебя медленее. Ты ведь проверяешь на не сжимаемых данных, ФС сначала сжимает проверяет результат - лучше не стало и пишет как есть, в итоге вместо буста некоторое замедленее. Я думаю в этом дело.
Так буста я и не ожидал, надеялся, что со сжатием потеря будет незначительной. А в итоге тест показал ощутимую разницу в версии btrfs, в Ubuntu 16.04 фс ощутимо бЬІстрее работает нежели в 14.04. Все больше склоняюсь в апреле 16.04 ставить основной именно на btrfs. Потому что такие мелочи как с плеером приятно радуют.
Интересно как будет со старЬІми  заезженеми ХДД, будет ли ощутимЬІй прирост производительности на старЬІх ПК, если на них поставить 16.04 на btrfs.

Оффлайн AnrDaemon

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28349
    • Просмотр профиля
Только за счёт ускорения поиска.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

 

Страница сгенерирована за 0.03 секунд. Запросов: 24.