Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 41
А можно графики в большем разрешении?
«Все тесты, кроме последнего (11-го), производились только на выделенных серверах.».
Полагаю что понято что SATA не может быть лучше SSD. Линии разного цвета, просто похожи. Постараюсь исправить этот момент, чтобы было понятнее.
4x SAS, 8x SAS — 2x Xeon E5620 @ 2.40GHz
2x SAS, 2x SSD hw raid — Xeon X3450 @ 2.67GHz
SSD KINGSTON — Intel i7-2600 @ 3.40GHz
Параметры подбирались таким образом чтобы использовалось только 1 ядро процессора и не было загружено на все 100%. Тесты проводились и на других машинах, которые не попали на эти графики, по этому сравнивать есть с чем и я уверен что погрешность от процессора ничтожна.
Операционная система Debian 7, CentOS 6. FreeBSD с осью ZFS не использовал, хоть и была возможность.
автора на разных графиках линиями одного цвета обозначает разные тестируемые юниты.
Полагаю что понято что SATA не может быть лучше SSD. Линии разного цвета, просто похожи. Постараюсь исправить этот момент, чтобы было понятнее.
4x SAS, 8x SAS — 2x Xeon E5620 @ 2.40GHz
2x SAS, 2x SSD hw raid — Xeon X3450 @ 2.67GHz
SSD KINGSTON — Intel i7-2600 @ 3.40GHz
Параметры подбирались таким образом чтобы использовалось только 1 ядро процессора и не было загружено на все 100%. Тесты проводились и на других машинах, которые не попали на эти графики, по этому сравнивать есть с чем и я уверен что погрешность от процессора ничтожна.
Операционная система Debian 7, CentOS 6. FreeBSD с осью ZFS не использовал, хоть и была возможность.
У вас каша из терминов в статье.
SATA, SAS — интерфейс обмена данными
SSD — тип накопителя
По сути тестов: не учитывается прослойка файловой системы, блок ввода-вывода, режимы доступа к RAID-группе (сколько путей например используется единовременно)
Ваши неотвеченые вопросы:
1. о какой конструкции идёт речь? зависит от всего: типа подключения, контроллера, типа рейда.
2. Начните с характера нагрузки.
SATA, SAS — интерфейс обмена данными
SSD — тип накопителя
По сути тестов: не учитывается прослойка файловой системы, блок ввода-вывода, режимы доступа к RAID-группе (сколько путей например используется единовременно)
Ваши неотвеченые вопросы:
1. о какой конструкции идёт речь? зависит от всего: типа подключения, контроллера, типа рейда.
2. Начните с характера нагрузки.
1. Разумеется, но все протестировать нереально. Имел ввиду сравнение одного и того же контроллера, одной и того же модели SSD, но уже в RAID10. Например таких:
- 4x SSD INTEL SC2CT12 Hardware RAID10 8x SSD INTEL SC2CT12 Hardware RAID10 12x SSD INTEL SC2CT12 Hardware RAID10
Но мое субъективное мнение, что результаты не будут такими как при SAS.
2. Если эти VDS используются не для личных целей, а для сдачи в аренду, то характеры нагрузок будут разными.
1. Вы увеличиваете длину страйпа со всеми вытекающими. Тут стоит обратить уже внимание на длину очереди интерфейса, например. Многое зависит от алгоритма работы контроллера, дисков, путей. Правило «больше==лучше» работает далеко не всегда. В общем, я бы спрогнозировал ростущую с длинной страйпа нелинейность характеристик массива во времени.
2. Собираетесь сдать в аренду сервер с диском без избыточности?
2. Собираетесь сдать в аренду сервер с диском без избыточности?
Да еще и рандомно вместо случайно.
Вот Вам SSD с SAS интерфейсом. Вы путаете интерфейсы подключения и технологию хранения данных.
Как вы отделяете результаты работы файловых кешей от работы дисков?
Именно по этому, кроме тестирования с помощью sysbench, выполнил первые три теста, которые исключают такую возможность.
Если вы можете предложить тест интереснее я рад вас выслушать.
Если вы можете предложить тест интереснее я рад вас выслушать.
Первые три не исключают кеширование.
«Интереснее» можно придумать много чего, но с практической точки зрения честным будет только тесты с directio.
«Интереснее» можно придумать много чего, но с практической точки зрения честным будет только тесты с directio.
немного смутило
Массивы как бы изначально (имхо) используют для резервирования железа, а скорости чтения/записи на них это уже второе. Именно потому и существуют различные варианты объединения в массивы (0,1,5,10 и т.д.), что бы железо было зарезервировано и приемлемые скорости записи/чтения были.
Поэтому тут вопрос не в том что SSD в массиве почти не отличаются по производительности, а в том нужно ли резервирование. Соответственно итог по данному пункту как то странно смотрится.
А так статья интересная, спасибо.
Обобщая все вышесказанное, для большинства задач лучше использовать большие массивы (>=8) из SAS или Hardware RAID из SSD. Но для некоторых задач корректнее будет использовать одинарные SSD.
Массивы как бы изначально (имхо) используют для резервирования железа, а скорости чтения/записи на них это уже второе. Именно потому и существуют различные варианты объединения в массивы (0,1,5,10 и т.д.), что бы железо было зарезервировано и приемлемые скорости записи/чтения были.
Поэтому тут вопрос не в том что SSD в массиве почти не отличаются по производительности, а в том нужно ли резервирование. Соответственно итог по данному пункту как то странно смотрится.
А так статья интересная, спасибо.
тесты не корректны. Нет изначальной спецификации: модель массива, настройки кеша массива, интерфейсы подключения, файловые системы, опции монтирования, опции sysctl. Тесты не исключают кеширования, вам об этом выше сказали, используйте пжлста, была тут статья от amarao об использовании утилиты fio. На самом деле важны только IOPSы, Throughput и latency. SSD проверять надо при заполнености >60% и более 24-48 часов.
Да.
Те данные, что мне известны я указал.
Все разделы ext4, defaults.
Sysctl по умолчанию.
Первые два теста — откуда кэш, если данные не повторяются?
fio выдает результаты на SSD непредсказуемые. Один тест высокие результаты, второй низкие, третий что то среднее. По другим накопителям все понятно и без таких колебаний в результатах.
Кингстоны размером в 60 Гб, раздел 48 Гб. Тесты sysbench выполнялись на 10 и 30 Гб.
Все разделы ext4, defaults.
Sysctl по умолчанию.
Первые два теста — откуда кэш, если данные не повторяются?
fio выдает результаты на SSD непредсказуемые. Один тест высокие результаты, второй низкие, третий что то среднее. По другим накопителям все понятно и без таких колебаний в результатах.
Кингстоны размером в 60 Гб, раздел 48 Гб. Тесты sysbench выполнялись на 10 и 30 Гб.
> Первые два теста — откуда кэш, если данные не повторяются?
Кеш операционной системы.
> fio выдает результаты на SSD непредсказуемые.
Этим и плох ssd. Для физических hdd все рассчитывается просто.
> Кингстоны размером в 60 Гб, раздел 48 Гб. Тесты sysbench выполнялись на 10 и 30 Гб.
Какой толк, если диски не были заполнены полностью?
habrahabr.ru/post/168711/#comment_5846147
Кеш операционной системы.
> fio выдает результаты на SSD непредсказуемые.
Этим и плох ssd. Для физических hdd все рассчитывается просто.
> Кингстоны размером в 60 Гб, раздел 48 Гб. Тесты sysbench выполнялись на 10 и 30 Гб.
Какой толк, если диски не были заполнены полностью?
habrahabr.ru/post/168711/#comment_5846147
Кеш операционной системы.
В файл abcd.txt пишу 12345, после в файл abcd2.txt пишу 32568. Что здесь кэшировать? В реалиях данные сохраняются также.
Этим и плох ssd. Для физических hdd все рассчитывается просто.
Полностью поддерживаю. Но если использовать данные от fio, но ничего сравнить вовсе нереально. По этому не использовал.
Какой толк, если диски не были заполнены полностью?
habrahabr.ru/post/168711/#comment_5846147
Заполнение более 60% это не так мало. В реальности редко кто допускает большее заполнение, делается запас. Все тесты выполнялись без таймаута, за один подход. Т.е. нагрузка была разной, но была в течении всех тестов. «Отдохнуть» не было когда. Полностью все тесты занимали около 3-х часов.
> В файл abcd.txt пишу 12345, после в файл abcd2.txt пишу 32568. Что здесь кэшировать?
У вас потрясающе низкий уровень знаний в этой области.
Такие записи отлично кешируются в памяти и сбрасываются реально на диск на многие милисекунды/секунды позже, чем операционная система возвращает успешный код возврата операции. Запись, в отличии от чтения, кешируется проще всего, сохранили в памяти, набрали несколько блоков, записали их одной транзакцией.
> Заполнение более 60% это не так мало.
> Кингстоны размером в 60 Гб, раздел 48 Гб. Тесты sysbench выполнялись на 10 и 30 Гб.
10 и 30 это меньше 60% для диска 60гб.
У вас потрясающе низкий уровень знаний в этой области.
Такие записи отлично кешируются в памяти и сбрасываются реально на диск на многие милисекунды/секунды позже, чем операционная система возвращает успешный код возврата операции. Запись, в отличии от чтения, кешируется проще всего, сохранили в памяти, набрали несколько блоков, записали их одной транзакцией.
> Заполнение более 60% это не так мало.
> Кингстоны размером в 60 Гб, раздел 48 Гб. Тесты sysbench выполнялись на 10 и 30 Гб.
10 и 30 это меньше 60% для диска 60гб.
Спасибо за тесты, но почему вы проводите тесты на разных серверах и с разными оборудования? Надо было взять один сервер и все винты протестировать на ней, после чего взять другой сервер.
Смысл статьи:
Давайте сравним вертолет и подводную лодку.
А именно измерим их длину и скажем что самокат быстрее летает в гелии.
SAS, SATA, SSD, RAID, все смешалось
Давайте сравним вертолет и подводную лодку.
А именно измерим их длину и скажем что самокат быстрее летает в гелии.
SAS, SATA, SSD, RAID, все смешалось
глаза можно сломать. половина цветов в легенде выглядит одинаково. хотя бы квадратики-треугольнички бы добавили
еще порядок в легенде не сопоставляется с порядком линий, в одних графиках лучше — больше, в других лучше — меньше, к тому же сравниваются сильно разные вещи — сложно сделать какие-то выводы.
С другой стороны, в таком зоопарке можно делать выводы только о выборе конфигурации из нескольких имеющихся для конкретной цели, возможно это автору и требовалось.
С другой стороны, в таком зоопарке можно делать выводы только о выборе конфигурации из нескольких имеющихся для конкретной цели, возможно это автору и требовалось.
в одних графиках лучше — больше, в других лучше — меньше
Ну переворачивать ось Y верх ногами тоже неверно, согласитесь.
Чтобы сделать более корректные выводы нужен «зоопарк», как вы выразились, раз в 10 хотя бы больше. Ведь у каждой конкретной модели накопителя свои особенности.
Я бы сказал так, — поверхностный тест в целом и довольно определенный по конкретным моделям, массивам. Хотелось бы сделать больше, но возможности ограничены. Надеюсь и эти данные будут полезны сообществу.
Ну и каша, при чём не только в тексте статьи видимо.
Уважаемый WapGraf,
вы проделали полезную и полагаю непростую работу, учитывая что железо не ваше. Но замеры проводились в не совсем корректных по сути условиях для подобного тестирования, что вносит значительную и совершенно непрогнозируемую погрешность в результаты. Очень сложно определить где заслуга/вина дисков, а где контроллера, где отработали буфера, а где железо. Где производительность достигнута грамотной буферизацией или полным write-back а где контроллер загнобил диски на random access, хотя потенциал был значительно выше, т.д. и т.п.
Основная проблема оценки производительности дисковой подсистемы в большом количестве слоев, где на каждом слое своя специфика — кеши, буфера, узкие места. Тестировать производительность сквозь все слои абстракции наобум можно конечно, но и результат вы получаете не претендующий на какую-либо точность — по сути лишь общее впечатление так сказать от практического использования.
Тестировать низкоуровневые вещи, работая с блочными девайсами и direcio можно, и получить высокой точностьи и репродуцируемости результаты легко. Но тут станет вопрос применимости этих показателей на практике. Ваш workload, реальная нагрузка ложащаяся на систему, как правило не соответствует тестовой и результаты снова не очень.
Поэтому для класса задач сравнения производительности (а не просто тестирования на посмотреть) принято или тестировать оба подхода, или использовать репродуцируемые тесты aka benchmark'и. Кроме того проф. сообщество обычно плохо относится к тестированию неспециализированным софтом, самопальными SQL запросами итд итп. Не столько потому что они априори плохие, а потому что эти тесты выхватывают лишь малую долю возможных ворклоадов и таком образом бесполезны для понимаия всей картины. Здорово знать что массив из дисков имеет XXX MByte/s на линейной перезаписи блоками по 4К и XX MByte/s на рандом чтении. Но не сказать чтобы это было хорошим параметром для сравнения. Кроме того много стандартных ворклоадов вываливается в массивный random access и критично важно знать что на 5k IOPS этот массив вообще вывалится в latency=5s и утянет за собой в iowait всю операционку. С базой приятно знать что как быстро делается выборка по ключу или синтетической нагрузке, но не зная какие будут результаты на 4, 8, 16 и 32 паралельных потоках эта информация не слишком полезна.
Если мерять перфоманс «в жизни» — из-под файловой системы, кеша в оперативке, дебиановского io шедулера, рейд-контроллера с неуказанымы настройками кешей, на диски с неуказанным объёмом кеша итд итп — то лучше использовать софт типа iozone и bonnie++. Он позволяет и быстро увидеть разницу производительности на cache-hit / cache-miss / buffer etc и стандартными замерами покрыть запись чтение перезапись перечтение рандомы итд итп
Если мерять низкоуровневую производительность с массой разных ворклоадов «из жизни» то пожалуй самой популярной утилитой будет IOmeter, на него есть масса готовых конфигураций на любой вкус.
Если интересуют результаты на разных обывательских ворклоадах (а-ля файлсервер, вебсервер, СХД итд итп) — тут полезен может быть Phoronix Test Suite — это фреймворк тестирования производительность с большим числом встроенных тестов. В том числе есть парочка неплохих для дисковой нагрузки
Если вы уже тестируете базу данных, то рекомендую использовать стандартные тесты индустрии — и замерять проще, и сравнивать легче, и результаты по разным ворклоадам достоверные и сравнимваемые. Есть тесты и в вышеупомянутом Phoronix Suite, есть очень уважаемые в индустрии TPC-H, TPC-D, TPC-*
В общем я бы вам рекомендовал в будущем оптимизировать подход к тестирвоанию — получите за то же время намного большерезультатов для аналитики и репродуцируемость для сравнения ну и полагаю хабру более достоверные данные прийдутся по вкусу.
P.S. тестируя диски в массивах всегда очень хочется видеть и тест одиночного диска, «на глазок» оценить прирост-потерю на контроллере
вы проделали полезную и полагаю непростую работу, учитывая что железо не ваше. Но замеры проводились в не совсем корректных по сути условиях для подобного тестирования, что вносит значительную и совершенно непрогнозируемую погрешность в результаты. Очень сложно определить где заслуга/вина дисков, а где контроллера, где отработали буфера, а где железо. Где производительность достигнута грамотной буферизацией или полным write-back а где контроллер загнобил диски на random access, хотя потенциал был значительно выше, т.д. и т.п.
Основная проблема оценки производительности дисковой подсистемы в большом количестве слоев, где на каждом слое своя специфика — кеши, буфера, узкие места. Тестировать производительность сквозь все слои абстракции наобум можно конечно, но и результат вы получаете не претендующий на какую-либо точность — по сути лишь общее впечатление так сказать от практического использования.
Тестировать низкоуровневые вещи, работая с блочными девайсами и direcio можно, и получить высокой точностьи и репродуцируемости результаты легко. Но тут станет вопрос применимости этих показателей на практике. Ваш workload, реальная нагрузка ложащаяся на систему, как правило не соответствует тестовой и результаты снова не очень.
Поэтому для класса задач сравнения производительности (а не просто тестирования на посмотреть) принято или тестировать оба подхода, или использовать репродуцируемые тесты aka benchmark'и. Кроме того проф. сообщество обычно плохо относится к тестированию неспециализированным софтом, самопальными SQL запросами итд итп. Не столько потому что они априори плохие, а потому что эти тесты выхватывают лишь малую долю возможных ворклоадов и таком образом бесполезны для понимаия всей картины. Здорово знать что массив из дисков имеет XXX MByte/s на линейной перезаписи блоками по 4К и XX MByte/s на рандом чтении. Но не сказать чтобы это было хорошим параметром для сравнения. Кроме того много стандартных ворклоадов вываливается в массивный random access и критично важно знать что на 5k IOPS этот массив вообще вывалится в latency=5s и утянет за собой в iowait всю операционку. С базой приятно знать что как быстро делается выборка по ключу или синтетической нагрузке, но не зная какие будут результаты на 4, 8, 16 и 32 паралельных потоках эта информация не слишком полезна.
Если мерять перфоманс «в жизни» — из-под файловой системы, кеша в оперативке, дебиановского io шедулера, рейд-контроллера с неуказанымы настройками кешей, на диски с неуказанным объёмом кеша итд итп — то лучше использовать софт типа iozone и bonnie++. Он позволяет и быстро увидеть разницу производительности на cache-hit / cache-miss / buffer etc и стандартными замерами покрыть запись чтение перезапись перечтение рандомы итд итп
Если мерять низкоуровневую производительность с массой разных ворклоадов «из жизни» то пожалуй самой популярной утилитой будет IOmeter, на него есть масса готовых конфигураций на любой вкус.
Если интересуют результаты на разных обывательских ворклоадах (а-ля файлсервер, вебсервер, СХД итд итп) — тут полезен может быть Phoronix Test Suite — это фреймворк тестирования производительность с большим числом встроенных тестов. В том числе есть парочка неплохих для дисковой нагрузки
Если вы уже тестируете базу данных, то рекомендую использовать стандартные тесты индустрии — и замерять проще, и сравнивать легче, и результаты по разным ворклоадам достоверные и сравнимваемые. Есть тесты и в вышеупомянутом Phoronix Suite, есть очень уважаемые в индустрии TPC-H, TPC-D, TPC-*
В общем я бы вам рекомендовал в будущем оптимизировать подход к тестирвоанию — получите за то же время намного большерезультатов для аналитики и репродуцируемость для сравнения ну и полагаю хабру более достоверные данные прийдутся по вкусу.
P.S. тестируя диски в массивах всегда очень хочется видеть и тест одиночного диска, «на глазок» оценить прирост-потерю на контроллере
Очень благодарю за столь развернутый ответ. Все советы приму в сведению в будущем.
Начал заниматься этим из-за того что не редко наблюдал, как множественные benchmark'и существенно отличаются от результатов на практике. В итоге прогнозируешь одно, получаешь совсем другое. В плане сравнения SATA/SAS еще можно делать кое-какие прогнозы, а вот сравнивать с SSD тяжело.
Еще раз спасибо!
Начал заниматься этим из-за того что не редко наблюдал, как множественные benchmark'и существенно отличаются от результатов на практике. В итоге прогнозируешь одно, получаешь совсем другое. В плане сравнения SATA/SAS еще можно делать кое-какие прогнозы, а вот сравнивать с SSD тяжело.
Еще раз спасибо!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение носителей SATA, SAS, SSD и RAID-массивов с ними