Сравнение носителей SATA, SAS, SSD и RAID-массивов с ними

А можно графики в большем разрешении?

У вас каша из терминов в статье.
SATA, SAS — интерфейс обмена данными
SSD — тип накопителя
По сути тестов: не учитывается прослойка файловой системы, блок ввода-вывода, режимы доступа к RAID-группе (сколько путей например используется единовременно)

Ваши неотвеченые вопросы:
1. о какой конструкции идёт речь? зависит от всего: типа подключения, контроллера, типа рейда.
2. Начните с характера нагрузки.

Вот Вам SSD с SAS интерфейсом. Вы путаете интерфейсы подключения и технологию хранения данных.

Как вы отделяете результаты работы файловых кешей от работы дисков?

немного смутило

Обобщая все вышесказанное, для большинства задач лучше использовать большие массивы (>=8) из SAS или Hardware RAID из SSD. Но для некоторых задач корректнее будет использовать одинарные SSD.

Массивы как бы изначально (имхо) используют для резервирования железа, а скорости чтения/записи на них это уже второе. Именно потому и существуют различные варианты объединения в массивы (0,1,5,10 и т.д.), что бы железо было зарезервировано и приемлемые скорости записи/чтения были.
Поэтому тут вопрос не в том что SSD в массиве почти не отличаются по производительности, а в том нужно ли резервирование. Соответственно итог по данному пункту как то странно смотрится.

А так статья интересная, спасибо.

тесты не корректны. Нет изначальной спецификации: модель массива, настройки кеша массива, интерфейсы подключения, файловые системы, опции монтирования, опции sysctl. Тесты не исключают кеширования, вам об этом выше сказали, используйте пжлста, была тут статья от amarao об использовании утилиты fio. На самом деле важны только IOPSы, Throughput и latency. SSD проверять надо при заполнености >60% и более 24-48 часов.

Спасибо за тесты, но почему вы проводите тесты на разных серверах и с разными оборудования? Надо было взять один сервер и все винты протестировать на ней, после чего взять другой сервер.

Смысл статьи:
Давайте сравним вертолет и подводную лодку.
А именно измерим их длину и скажем что самокат быстрее летает в гелии.

SAS, SATA, SSD, RAID, все смешалось

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

Ну и каша, при чём не только в тексте статьи видимо.

Уважаемый 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. тестируя диски в массивах всегда очень хочется видеть и тест одиночного диска, «на глазок» оценить прирост-потерю на контроллере