Pull to refresh

Comments 57

помоему вы провели сравнение файловых систем UFS и EXT3, а не програмных рейдов(да еще и RAID1, где идет тупое дублирование инфы и нагрузка минимальна). может конечно я и не прав, посмотрим по коментам:-)
согласен, но все же реализации програмных рэйдов, сравниваемых ОС, накладывают свой отпечаток на результат. EXT3 и UFS были выбранны, как «стандартные», дефолтные для Linux и FreeBSD =)
я практически уверен что «отпечаток от реализации програмных рэйдов» в данном случае укладывается в пределы погрешности данных тестов. Если же хотите более правильный результат получить то нужно использовать одинаковые версии тестовых утилит и одинаковую файловую систему на рейде. Но даже в этом случае на результат больше повлияет реализация работы с выбранной фс в ос, чем программный RAID1(в других вариантах рейдов разница может быть более существенна). Ну и как уже сказали ext3 уже устарела, по дефолту теперь ext4 которая будет пошустрее.
говорите в пределах… что же, позволю себе еще немного цифр =)
dd if=/dev/zero of=testfile bs=4k count=262144

1073741824 bytes transferred in 74.390626 secs (13,7 Mbytes/sec)

dd if=testfile of=/dev/null bs=4k count=262144

1073741824 bytes transferred in 11.570257 secs (88,5 Mbytes/sec)

dd if=/dev/zero of=testfile bs=64k count=16384

1073741824 bytes transferred in 50.989816 secs (20,08 Mbytes/sec)

dd if=testfile of=/dev/null bs=64k count=16384

1073741824 bytes transferred in 10.295204 secs (99,4 Mbytes/sec)

dd if=/dev/zero of=testfile bs=1m count=1024

1073741824 bytes transferred in 16.124883 secs (63,5 Mbytes/sec)

dd if=testfile of=/dev/null bs=1m count=1024

1073741824 bytes transferred in 3.163722 secs (323,7 Mbytes/sec)


Это тест одного диска с UFS. Вот вам и разница. Как видно скорость упала в разы.
«1073741824 bytes transferred in 3.163722 secs (323,7 Mbytes/sec)» улыбнуло. не встречал я еще настолько быстрых сата2 винтов.
Ради интереса запустил ваши тесты у себя на домашнем сервере c linux/xfs
dd if=/dev/zero of=testfile bs=4k count=262144
1073741824 bytes (1,1 GB) copied, 10,1205 s, 106 MB/s

dd if=testfile of=/dev/null bs=4k count=262144
1073741824 bytes (1,1 GB) copied, 10,4522 s, 103 MB/s

dd if=/dev/zero of=testfile bs=64k count=16384
1073741824 bytes (1,1 GB) copied, 9,91808 s, 108 MB/s

dd if=testfile of=/dev/null bs=64k count=16384
1073741824 bytes (1,1 GB) copied, 10,367 s, 104 MB/s

dd if=/dev/zero of=testfile bs=1M count=1024
1073741824 bytes (1,1 GB) copied, 9,98771 s, 108 MB/s

dd if=testfile of=/dev/null bs=1M count=1024
1073741824 bytes (1,1 GB) copied, 10,3657 s, 104 MB/s

При этом винт забит(последовательно) на 98% тоесть запись шла на конец пластин.
Единственное с чем могу согласится так это с тем что скорость чтения в случае «зеркала» может зависеть от программ, но думаю они обе читают паралельно с двух винтов.

Еще заметил интересный момент, у вас возле графиков везде Kb/sec тоесть килобиты в секунду, но тогда у вас очень медленные винты:) Также в сравнении данных DD вы для фри цифры указываете в мбитах, а для линукса в мбайтах — думаю нужно исправить
В результатах DD я перевел полученные результаты(в FreeBSD) в мегабайты в секунду, так что исправлять здесь ничего не нужно.
хм… возможно я допустил неточность в обозначении, но на графиках у меня именно Килобайты в секунду =)
я вот об этом
FreeBSD: 49,02 Mb/s
Linux: 23,9 MB/s
Читаем этот файл блоками по 4 Kb
FreeBSD: 342,7 Mb/s
Linux: 788 MB/s

Mb/s
само отправилось:(
Mb/s — мбиты
MB/s — мбайты
Правильно вообще:

— мбайт в сек == Mb/s
— мбит в сек
тьфу

mbps == мбит в сеk
mb/s == мбайт в сеk
вы не правы в таких абревиатурах маленькая b означает биты, большая B означает байты.

mbps(megabit per second) == Mb/s
mBps(megabyte per second, хотя такой абревиатуры в использовании я не встречал) == MB/s

en.wikipedia.org/wiki/MB
ух. впервые усомнился в адекватности википедии =)
не прав. да

судя по всему правильно MB/s и Mbit/s. А всё остальное — хлам =/
а как же mbps? :) Мне так нравилось это mpbs… :))
я подозреваю что mbps это просто текстовая абревиатура, а MB/s и Mbit/s единицы измерения из системы С, например.
При этом винт забит(последовательно) на 98% тоесть запись шла на конец пластин.


На самом деле при таком количестве уровней абстракции, которые есть в современных программно-аппаратных системах (сам винт с его firmware и reallocate, мэппинги блоков на уровне контроллера, адресация на уровне драйвера, расположение на уровне файловой системы) прогнозировать, куда будет записан физически тот или иной блок, практически невозможно.
>> Единственное с чем могу согласится так это с тем что скорость чтения в случае «зеркала» может зависеть от программ, но думаю они обе читают паралельно с двух винтов.

Программы-то натурально не читают с винтов, драйвер raid1 распределяет запросы по дискам.

Я как-то смотрел насчет чтений с рейда — «последовательное чтение, по крайней мере в один поток на sw raid1 в линупсе выдаёт скорость одного диска» — mytechspam.livejournal.com/7879.html#cutid1

Я не понимаю зачем вы вообще используете файловые системы. Пишите напрямую в раздел рейда через DD. Другое дело что нужно заморочиться с очень быстрым устройством /dev/zero или /dev/random…
/dev/random сверхмедленное устройство
/dev/urandom немного быстрее
/dev/zero наш выбор:)
Про минимальную нагрузку не соглашусь — не так давно на достаточно загруженном вебсервере разбирал gmirror на отдельные диски, на один вынес веб, на другой — БД. Нагрузка на диски: «до» — 100%, «после» — 10-20%. BSD 8.0.
Таки ext4 в записи на /dev/md пошустрее ext3-го будет.

И ext3 уже сомнительно дефолтная.
К сожалению сделать корректное сравнение не представляется возможным в связи с использованием разных файловых систем в этих ОС :(

К слову в linux в многих тестах заметно ниже нагрузка на процессор, что часто бывает довольно таки важно.
А какой в этом смысл при разных фс да еще и на дефолтных настройках?
я посчитал что именно так будет нагляднее, безо всякого тюнинга.
ребят, я цифры правда не сам придумал, все полученно в результате тестов :-))
я думаю все это понимают. лично мне эта тема интересна так как сам планирую скинуть все винты с домашних компов на сервак в рейд и юзать по нфс. За то что подняли тему я плюсанул и карму и топик, но всеже хотелось бы более обьективного тестирования. А пока это тестирование очень неоднозначное и некоторые цифры у меня вызывают недоумение(в скорости последовательной записи до 20мбайт/сек на современных винтах не верится).
Думаю что достичь объективности в данном вопросе весьма не просто, как я указал в введении, мой отчет скорее субъективен. А для более детального и всеобъемлющего тестирования требуется на порядок больше времени, которого, как всегда, катасрофически не хватает.
Для более детального и всеобъемлющего тестирования требуется банальное понимание предметной области. В противном случае получается как в старом анекдоте:
— Приборы.
— 20
— Что «20»?
— А что «приборы»?
Кажется вы уже начали догадываться что «тесты» (и интерпретация их результатов) это не так просто, как кажется. ;)
да уж, поначалу мне это показалось делом одного дня, в итоге я «убил» 8 рабочих дней =)
UFO just landed and posted this here
Памяти добавить не получится, а ZFS к ней требовательна. С ZFS не работал, читать мануалы нет времени(а по другому не умею =)) Будет оказия обязательно проверю.
UFO just landed and posted this here
Пробовали zfs на сервере что раздает файлы (8 винтов, вроде бы), под FreeBSD скорость была очень плохая под нагрузкой. На mdadm raid10 (4+4) сервер гигабит без проблем забивает, под ZFS не добрался даже до 100Мбит вроде бы.
zfs видимо пока что хорошо только под солярис (тестировали месяца 4 назад, может что-то поменялось)
UFO just landed and posted this here
8Gb памяти
FreeBSD вроде была 8.0, точно не помню. На тот момент последняя стабильная версия.

Вообще, по рассылке видно, что продукт очень сырой еще, постоянно какие-то баги и патчи выкладываются, которые в общем-то стабильной ФС не должны быть характерны.
пью йад литрами :-))))
проплюсовал другие топы, а оказывается можно было на главную попасть. И смешно и грустно, спасает пятница и пиво =)
на главную и сейчас еще можно попасть, перенесите пост в тематический блог и он появится в главной ленте. ведь рейтинг поста больше 8
карма <3, увы ))
не получится, должен быть >=5
я к сожалению сегодня вас уже плюсануть не смогу. жаль конечно что так вышло, хотелосьбы более активное обсуждение почитать.
быть может НЛО мне поможет =)))
*думаю все таки прорвусь на главную, +16 голосов за топ, осталось лишь +2 кармы )
Спасибо за карму. Перенес в «Операционные системы».
Интересно, если разные chunk size выбирать для mdadm, результаты изменятся сильно?
человеку не понравилась фря и получился данный пост, я б даже сказал пост «anti freebsd»
вы похоже статью читали по диагонали… Эпилог прочтите
«Для меня выбор очевиден — FreeBSD, она бастрее при создании файлов, особенно при создании файлов большого размера. Как раз то, что мне нужно.»
«Хотя я снова не договариваю всей правды. Выбор в пользу FreeBSD был сделан еще до теста. Так как эту ОС я просто знаю намного лучше нежели Linux, и нравится она мне много больше.»
Создадим файл размером 100 Gb из блоков размером 1 Gb
FreeBSD: 31,7 MB/s
Linux: 14,7 MB/s
Читаем этот файл блоками по 4 KB
FreeBSD: 57,48 MB/s
Linux: результат получить не удалось

Что значит «результат получить не удалось»? Отказ дисковой подсистемы в Linux?
Машина не вылезала из свопа. При наличии 1.25GB памяти буффер на гиг туда не всегда влезет.
> debian:/raid# dd of=testfile if=/dev/null bs=1024M count=100

просто перепутал of/if, в итоге автор читал из /dev/null.
когда хром научится на маке рисовать верные буковки вместо кракозямбов?
Пост ни о чём. Даже версию ядра не указали. А это важно. -1
йомайо. Вы словно сравнили поведение машин на разной резине, но при этом одна машинба — мерс, а другая «не мерс».
Тут в чистом виде разница самих фс — ufs vs ext3.

При поиске «хочу быстрее быстрее быстрее» они обе уже не вариант. Ext3 легко меняется на ext4, а ufs сами знаете на что.

Футпринт софтварного рейда мал настолько, что им можно сильно пренебречь. По крайней мере для зеркалки. Хардварный жей RAID0 разорвёт софтварный в пух и прах в любом случае.
может какой-то иостат лучше прогнать? графики демонстрируют только разный дефолтовый кэш у фс.
Аффтар адский сатана. У нас на втором курсе института был такой предмет как «Теория постановки эксперимента» на котором учили не только как правильно провести тесты, но ещё осмыслить результаты. Итак, начнём.

> HDD 2,3(RAID): SATA-II 1,5Tb Western Digital [WD15EARS] (подключены к Promise)
> SATA контроллер: Promise SATA300 TX4 PCI, 4-port SATA300

Пиковая теоритическая пропускная способность PCI — 133MB/s. Забавно при этом видеть какие-то 200MB/s, 300MB/s, 600MB/s ;) Плюс ко всему ваши супербыстрые веники (которые действительно способны отдавать большее 100MB/s на чтение) банально упираются в ваш тормозной контроллер, это очень хорошо видно на графиках для freebsd — ровная полочка записи на ~48MB/s и чтения на ~57MB/s при чтении 100G файла. А на самом деле вы намеряли скорость работы с памятью, и результат 8-ми дневной работы можно спокойно спустить в утиль, толку от тесты нет никакого.
Я искренне рад за вас. Во введении написанно.
«Тест не претендует на абсолютную объективность, скорее он даже субъективен в разрезе используемого аппаратного обеспечения. Но так или иначе, цифры есть цифры.»
Быть может на столько образованный человек как вы предоставит объетивный тест для широкой общественности? ;)
Объективнй тест я продставить не могу из-за отсутствия необходимого кол-ва дисков, но когда-то давно делал тесты из-под FreeBSD для себя, и могу сказать что накладные расходы у рейдов очень небольшие и на скорость влияют очень слабо. Ещё нужно было конечно посмотреть на iops-ы, но меня тогда это слабо волновало.
В dd (по крайней мере в GNU dd) неплохо было бы использовать conv=fsync или conv=fdatasync.
Sign up to leave a comment.

Articles