Обновить

Комментарии 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 рабочих дней =)
Есть три типа лжи…
НЛО прилетело и опубликовало эту надпись здесь
Памяти добавить не получится, а ZFS к ней требовательна. С ZFS не работал, читать мануалы нет времени(а по другому не умею =)) Будет оказия обязательно проверю.
НЛО прилетело и опубликовало эту надпись здесь
Пробовали zfs на сервере что раздает файлы (8 винтов, вроде бы), под FreeBSD скорость была очень плохая под нагрузкой. На mdadm raid10 (4+4) сервер гигабит без проблем забивает, под ZFS не добрался даже до 100Мбит вроде бы.
zfs видимо пока что хорошо только под солярис (тестировали месяца 4 назад, может что-то поменялось)
НЛО прилетело и опубликовало эту надпись здесь
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.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации