Пользователь
0,0
рейтинг
1 ноября 2013 в 12:35

Администрирование → Сравнение носителей SATA, SAS, SSD и RAID-массивов с ними из песочницы

Всем известны параметры производительности дисковых подсистем в теории. Но что на практике? Многие задают этот вопрос, некоторые строят свои гипотезы. Я решил провести серию тестов и определить «Who is who». Приступил к тестированию всеми известными утилитами dd, hdparm, далее перешел к fio, sysbench. Также был произведен ряд тестов используя UnixBench и несколько других аналогов. Было построено ряд графиков, но по мере дальнейшего тестирования было обнаружено что большинство этого ПО непригодно для адекватного сравнения разных дисков.
С помощью fio можно было составить сравнительную таблицу или график для SAS, SATA, но при тестировании SSD оказалось, что полученные результаты вовсе непригодны. Я конечно уважаю разработчиков этого всего софта, но в этот момент было принято решение создать ряд не синтетических тестов, а более близких к реальной обстановке.

Сразу скажу, что параметры теста и сами машинки были подобраны таким образом, чтобы результаты теста не были искажены типом процессора, его частотой или другими параметрами.

Тест 1

Создание файлов

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

Из графика видно что большую скорость создания файлов имеют SSD KINGSTON SV300S3 и почти не зависят от их количества. Также стоит отметить что именно эти диски имеют более прямолинейную шкалу
По SAS дискам в Hardware RAID видно что скорость зависит от типа рейда, но совсем не зависит от количества дисков.
Но больше времени тратится не на создание файлов, как оказалось, а на их перезапись. По этому перейдем к второму тесту.

Тест 2

Перезапись файлов

Повторялись те что операции что в первом тесте, но файлы не создавались новые каждый раз, а использовался один и тот же файл, в который записывалась каждый раз новая информация.

Сразу бросается в глаза ужасная картина по дискам SATA 7,200 rpm MB2000GCVBR. Медленная запись и по 2x 300GB SAS SEAGATE. По этому решил выбросить их из графика для наглядности по остальным.

Самой быстрой подсистемой оказался одиночный SSD KINGSTON. Второе и третье место заняли 8x SEAGATE ST3300657SS и 4x SEAGATE ST3300657SS. Также видим что с ростом количества SSD в массиве скорость немного падает.

Тест 3

MySQL. Комбинирование sql-запросов INSERT, SELECT, UPDATE, DELETE

Была создана InnoDB таблица со следующей структурой:
CREATE TABLE `table` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`time` int(11) NOT NULL,
`uid` int(11) NOT NULL,
`status` varchar(32) NOT NULL,
PRIMARY KEY (`id`),
FULLTEXT KEY `status` (`status`)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251;


Одновременно генерировалось несколько запросов:
— INSERT;
— UPDATE с выборкой по PRIMARY KEY;
— UPDATE с выборкой по FULLTEXT (поиск по 4 символам из 24-х): WHERE `status` LIKE '%(string)%';
— DELETE FROM с выборкой по PRIMARY KEY;
— DELETE FROM с выборкой без использования ключа: WHERE `time`>(int);
— SELECT с выборкой без использования ключа: WHERE `time`>(int);
— SELECT с выборкой по PRIMARY KEY;
— SELECT с выборкой по FULLTEXT (поиск по 4 символам из 24-х): WHERE `status` LIKE '%(string)%';
— SELECT с выборкой без использования ключа: WHERE `uid`>(int).


И снова наблюдаем ту же картину что во втором тесте.


В следующих тестах использую утилиту sysbench, которая генерирует файлы большого объема:
128 файлов, общим размером 10 Гб, 30 Гб и 50 Гб.
Размер блока 4 Кб.
Сразу хочу обратить внимание, что на некоторых графиках, по некоторым серверам нету данных на 10 Гб. Это связано с тем что на данных машинах имеется оперативной памяти более 10 Гб и выполняется кэширование данных. Отсутствие некоторых результатов на 50 Гб обусловлено нехваткой дискового пространства, в случае с SSD KINGSTON SV300S3.

Тест 4

Линейная запись (создание файлов)


Видно что лучшие показатели имеются у всех вариациях с SSD KINGSTON SV300S3, а также у 8x SEAGATE ST3300657SS в RAID10. Очень хорошо просматривается рост скорости с увеличение количества дисков SAS.
Здесь тот самый момент, где отлично видно что SSD совершенно разные бывают. Разница в 4 раза!

Тест 5

Линейная запись (перезапись файлов)


Лидеры все те же. Если сравнивать 2x SSD от INTEL и 2x SAS разницы практически никакой.

Тест 6

Линейное чтение


Здесь же видим чуть иную картину. Лидируют 4x SSD KINGSTON RAID10, с минимальным изменением результатов при увеличении объема файлов, и 8x SEAGATE в RAID10, с постепенным спадом скорости, на скоростях 700 Мбит/сек и 600 Мбит/сек.
Линии по 1x SSD KINGSTON и 2x SSD KINGSTON RAID1 совпали. Проще говоря для линейного чтения лучше брать или RAID10 или одиночный диск. Использование RAID1 не оправдано.
Хорошо видно что показали 2x SAS RAID1 и 4x SAS RAID10 очень похожи. Но при увеличении количества дисков в два раза просматривается огромный прирост скорости.
2x SSD Intel RAID1 имеет не малое падение скорости на промежутке 10 Гб — 30 Гб, а далее идут на одной скорости с SATA RAID1.

Тест 7

Рандомное чтение


В лидерах все SSD:
— 4x KINGSTON RAID10;
— 2x KINGSTON RAID1, 2x INTEL RAID1;
— 1 KINGSTON.

Всех остальных скопировал на следующий график для наглядности.

Наивысшую скорость среди этих имеет естественно 8x SAS RAID10, но скорость резко падает. Но исходя из данных по 2x SAS и 4x SAS предположу что с дальнейшем ростом объемом скорость стабилизируется.

Тест 8

Рандомная запись


Отличные показатели имеет 2x 120GB SSD INTEL SSDSC2CT12 Hardware RAID1 SAS1068E со стабильной скоростью 30 Мбит/сек. По KINGSTON с ростом количества дисков скорость, как ни странно, падает. На четвертом месте 8x SAS SEAGATE.

Тест 9

Комбинированные операции рандомного чтения и записи

Все мы знаем, что ни на одном сервере нету только чтения или только записи. Всегда выполняются обе операции. И в большинстве случаев это как раз рандомные операции, а не линейные. И так, посмотрим, что у нас получилось.

За счет отличной скорости записи с большим отрывом идет 2x SSD INTEL, за которым следует SSD KINGSTON. Третье место разделили 2x SSD KINGSTON и 8x SAS SEAGATE.

Тест 10

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

У кого рост скорости, у кого падение, а у 8x SAS RAID10 прямая линия.

Тест 11

Произвел также сравнение больших массивов из SAS дисков, по которому видно, что от скорости диска больше зависит, чем от их количества.


Пришло время подвести итоги.
Машин было много, но не достаточно. К сожалению мне не удалось определить являются ли показатели по SSD INTEL SSDSC2CT12 их особенностью или же особенностью рейдового контроллера. Но полагаю, что таки контроллера.
  1. С ростом количества SAS дисков в массиве все показатели только улучшаются.
  2. Для MySQL медленные подсистемы это SATA RAID1 и SAS RAID1. По остальным отличия есть, но они не столь существенны.
  3. Для линейно записи хороши как большие массивы из SAS дисков в RAID10, так и SSD. Смысла использовать массивы из SSD нет. Стоимость растет, а производительность на месте.
  4. Для линейного чтения хороши любые большие массивы. Но на практике лин. чтение без записи у нас почти не встретить.
  5. Рандомное чтение за SSD одиночными или в Software RAID.
  6. Для рандомной записи лучше использовать Hardware RAID из SSD, хотя не сильно поступаются и одиночные SSD.
  7. Рандомные чтение/запись, то есть один из самых важных показателей, имеют лучшие результаты на Hardware RAID из SSD.
  8. Обобщая все вышесказанное, для большинства задач лучше использовать большие массивы (>=8) из SAS или Hardware RAID из SSD. Но для некоторых задач корректнее будет использовать одинарные SSD.
  9. Исходя из объемов SSD, которые преимущественно предлагаются на нашем рынке, под VDS-ноды стоит использовать максимальной производительности процессоры в паре с большими SAS массивами или же средненькие процессоры и одинарные SSD. Считаю что использование hw raid для двух SSD будет дороговато.
  10. Если вам необходима быстрая система и нет необходимости в большом дисковом пространстве 2x SSD в Hardware RAID будет лучшим выбором. Если желаете немного сэкономить в ущерб производительности, тогда можно взять одинарный SSD или два SSD в софтовом рейде.


Вопросы, которые остались без ответов:
  1. Что происходит при увеличении количества SSD в Hardware RAID?
  2. Что дешевле под виртуальные сервера: дорогие машинки и один большой массив из SAS или же несколько средненьких серверов с одинарными SSD? В этом вопросе также следует учесть надежность/долговечность SAS и SSD, так как по последним ходят разные слухи.


Кроме перечисленных тестов и серверов было еще множество, но они не попали в результаты, так как на них проводилась «калибровка» тестов и многие их них были признаны некорректными.
Также производилось тестирование RAMDisk. Показатели были довольно хорошие, но не лучшие. Вероятно из-за того что это была виртуальная машина.

Все тесты, кроме последнего, производились только на выделенных серверах.

Благодарности:
  1. vds4you за предоставление большого числа виртуальных машин, на основании которых производилась калибровка тестов;
  2. PlusServer за предоставление четырех первых тестируемых машин на SSD/SAS, которые довольно таки продолжительное время тестировались. К сожалению в данные графики они попали. А также двух SATA из текущих тестов;
  3. FastVPS за предоставление всех серверов с SSD KINGSTON;
  4. ServerClub за предоставление машин с SSD INTEL Hardware RAID, а также всех машин с SAS дисками;
  5. всем кто принимал участие в обсуждении первоначальных тестов, в частности на форуме searchengines
Балицкий Андрей @WapGraf
карма
6,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (41)

  • +2
    А можно графики в большем разрешении?
  • +5
    Сначала подумал, что глюки, но потом разобрался — автора на разных графиках линиями одного цвета обозначает разные тестируемые юниты.
    Это совершенно недопустимо, т.к. весь смысл ваших графиков пропадает — если есть ещё возможность, исправьте плиз.
    Так же нет указания на используемое оборудование (процессор), лишь заверения, что всё о'к, и операционную систему (из контекста вроде линукс какой-то).
    Выводы в общем-то очевидны, но возможно кому-то будут и полезным.
    Опа… Благодарности пункт 1: тестирование что, было в виртуальных машиных?!
    • 0
      «Все тесты, кроме последнего (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 не использовал, хоть и была возможность.

      • +3
        Возможно, не очень понятно написал про цвет линий — в пределах графика всё нормально, но вот на одном графике зелёная линия — это 1xSSD Kingston, а на другом графике зелёная линия — это уже 8x300 GB SAS Seagate. Сильно сбивает с толку.
        И что бы два раза не вставать — в русской традиции записи чисел не принято разделять группы разрядов запятыми, в лучшем случае — пробелом: запись «2,000 GB» так же стопорит мозг на десятков секунд, что бы сообразить, что имелось ввиду. Но тут скорее у вас ПО для графиков виновато.
        • 0
          Да, я вас неверно понял. Если найду, как указать цвет вручную вместо автомата, исправлю. Довольно редко пользуюсь таким софтом.
        • +1
          Цвета изменил. И добавил ссылки на полные скриншоты графиков.
  • +14
    У вас каша из терминов в статье.
    SATA, SAS — интерфейс обмена данными
    SSD — тип накопителя
    По сути тестов: не учитывается прослойка файловой системы, блок ввода-вывода, режимы доступа к RAID-группе (сколько путей например используется единовременно)

    Ваши неотвеченые вопросы:
    1. о какой конструкции идёт речь? зависит от всего: типа подключения, контроллера, типа рейда.
    2. Начните с характера нагрузки.
    • 0
      1. Разумеется, но все протестировать нереально. Имел ввиду сравнение одного и того же контроллера, одной и того же модели SSD, но уже в RAID10. Например таких:
      • 4x SSD INTEL SC2CT12 Hardware RAID10 8x SSD INTEL SC2CT12 Hardware RAID10 12x SSD INTEL SC2CT12 Hardware RAID10
        Но мое субъективное мнение, что результаты не будут такими как при SAS.

        2. Если эти VDS используются не для личных целей, а для сдачи в аренду, то характеры нагрузок будут разными.
      • 0
        1. Вы увеличиваете длину страйпа со всеми вытекающими. Тут стоит обратить уже внимание на длину очереди интерфейса, например. Многое зависит от алгоритма работы контроллера, дисков, путей. Правило «больше==лучше» работает далеко не всегда. В общем, я бы спрогнозировал ростущую с длинной страйпа нелинейность характеристик массива во времени.
        2. Собираетесь сдать в аренду сервер с диском без избыточности?
    • 0
      Да еще и рандомно вместо случайно.
      • 0
        По моему это синонимы.
        Смотрите тут и тут
  • +5
    Вот Вам SSD с SAS интерфейсом. Вы путаете интерфейсы подключения и технологию хранения данных.
    • 0
      Согласен, есть ошибка.
  • +2
    Как вы отделяете результаты работы файловых кешей от работы дисков?
    • 0
      Именно по этому, кроме тестирования с помощью sysbench, выполнил первые три теста, которые исключают такую возможность.
      Если вы можете предложить тест интереснее я рад вас выслушать.
      • +2
        Первые три не исключают кеширование.
        «Интереснее» можно придумать много чего, но с практической точки зрения честным будет только тесты с directio.
        • 0
          Пробовал тесты проводить с directio, но накопители SSD показывали результаты существенно ниже SAS. Говорю честно — причину не понимаю.
          • 0
            Да, откройте для себя мир реального железа.
            А потом еще драматическое падение iops при длительном заполнении ssd.
            • +1
              Давайте больше конкретики.
              В тех тестах, где без directio SSD показали скорость 300 Мбит/сек, с этим параметров показывают менее 10. То есть вы считаете, что в реальности SSD настолько уж плохие? Я понимаю что результаты с directio должны быть другими, но не на столько же.
  • +1
    немного смутило
    Обобщая все вышесказанное, для большинства задач лучше использовать большие массивы (>=8) из SAS или Hardware RAID из SSD. Но для некоторых задач корректнее будет использовать одинарные SSD.

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

    А так статья интересная, спасибо.
    • +1
      Согласен со всем.
    • 0
      скорости чтения/записи на них это уже второе

      RAID без резервирования — только нулевой. Во всех остальных случаях забывать про производительность… странно? Я бы сказал что этот вопрос выползает на первое место практически всегда.
      • 0
        Под каждую задачу свои параметры отбора.
  • +4
    тесты не корректны. Нет изначальной спецификации: модель массива, настройки кеша массива, интерфейсы подключения, файловые системы, опции монтирования, опции sysctl. Тесты не исключают кеширования, вам об этом выше сказали, используйте пжлста, была тут статья от amarao об использовании утилиты fio. На самом деле важны только IOPSы, Throughput и latency. SSD проверять надо при заполнености >60% и более 24-48 часов.
    • 0
      Да.
    • 0
      Те данные, что мне известны я указал.
      Все разделы ext4, defaults.
      Sysctl по умолчанию.
      Первые два теста — откуда кэш, если данные не повторяются?
      fio выдает результаты на SSD непредсказуемые. Один тест высокие результаты, второй низкие, третий что то среднее. По другим накопителям все понятно и без таких колебаний в результатах.
      Кингстоны размером в 60 Гб, раздел 48 Гб. Тесты sysbench выполнялись на 10 и 30 Гб.
      • +2
        > Первые два теста — откуда кэш, если данные не повторяются?
        Кеш операционной системы.

        > fio выдает результаты на SSD непредсказуемые.
        Этим и плох ssd. Для физических hdd все рассчитывается просто.

        > Кингстоны размером в 60 Гб, раздел 48 Гб. Тесты sysbench выполнялись на 10 и 30 Гб.
        Какой толк, если диски не были заполнены полностью?
        habrahabr.ru/post/168711/#comment_5846147
        • 0
          Кеш операционной системы.

          В файл abcd.txt пишу 12345, после в файл abcd2.txt пишу 32568. Что здесь кэшировать? В реалиях данные сохраняются также.

          Этим и плох ssd. Для физических hdd все рассчитывается просто.

          Полностью поддерживаю. Но если использовать данные от fio, но ничего сравнить вовсе нереально. По этому не использовал.

          Какой толк, если диски не были заполнены полностью?
          habrahabr.ru/post/168711/#comment_5846147

          Заполнение более 60% это не так мало. В реальности редко кто допускает большее заполнение, делается запас. Все тесты выполнялись без таймаута, за один подход. Т.е. нагрузка была разной, но была в течении всех тестов. «Отдохнуть» не было когда. Полностью все тесты занимали около 3-х часов.
          • +2
            > В файл abcd.txt пишу 12345, после в файл abcd2.txt пишу 32568. Что здесь кэшировать?
            У вас потрясающе низкий уровень знаний в этой области.
            Такие записи отлично кешируются в памяти и сбрасываются реально на диск на многие милисекунды/секунды позже, чем операционная система возвращает успешный код возврата операции. Запись, в отличии от чтения, кешируется проще всего, сохранили в памяти, набрали несколько блоков, записали их одной транзакцией.

            > Заполнение более 60% это не так мало.
            > Кингстоны размером в 60 Гб, раздел 48 Гб. Тесты sysbench выполнялись на 10 и 30 Гб.
            10 и 30 это меньше 60% для диска 60гб.
            • +1
              > сбрасываются реально на диск
              это буферизация
              бывает в операционной системе, в raid-контроллере (обычно если он с батареей) и на контроллере диска.
  • 0
    Спасибо за тесты, но почему вы проводите тесты на разных серверах и с разными оборудования? Надо было взять один сервер и все винты протестировать на ней, после чего взять другой сервер.
    • +1
      Если бы я имел свое оборудование и/или такую возможно непременно так бы и поступил.
      2x SAS SEAGATE ST3300657SS и 2x SSD INTEL — это одна машина, один рейд-контроллер.
  • +3
    Смысл статьи:
    Давайте сравним вертолет и подводную лодку.
    А именно измерим их длину и скажем что самокат быстрее летает в гелии.

    SAS, SATA, SSD, RAID, все смешалось
    • –1
      Смысл статьи не определить кто быстрее: SAS, SATA, SSD. А определить как ведет себя тот или иной носитель себя в рейд-массивах и без них, как зависит скорость чтения/записи от количества дисков в массиве, а также разница между hardware raid и software raid.
  • +3
    глаза можно сломать. половина цветов в легенде выглядит одинаково. хотя бы квадратики-треугольнички бы добавили
    • 0
      еще порядок в легенде не сопоставляется с порядком линий, в одних графиках лучше — больше, в других лучше — меньше, к тому же сравниваются сильно разные вещи — сложно сделать какие-то выводы.
      С другой стороны, в таком зоопарке можно делать выводы только о выборе конфигурации из нескольких имеющихся для конкретной цели, возможно это автору и требовалось.
      • 0
        в одних графиках лучше — больше, в других лучше — меньше

        Ну переворачивать ось Y верх ногами тоже неверно, согласитесь.

        Чтобы сделать более корректные выводы нужен «зоопарк», как вы выразились, раз в 10 хотя бы больше. Ведь у каждой конкретной модели накопителя свои особенности.

        Я бы сказал так, — поверхностный тест в целом и довольно определенный по конкретным моделям, массивам. Хотелось бы сделать больше, но возможности ограничены. Надеюсь и эти данные будут полезны сообществу.
  • +3
    Ну и каша, при чём не только в тексте статьи видимо.
  • +6
    Уважаемый 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. тестируя диски в массивах всегда очень хочется видеть и тест одиночного диска, «на глазок» оценить прирост-потерю на контроллере
    • 0
      Очень благодарю за столь развернутый ответ. Все советы приму в сведению в будущем.

      Начал заниматься этим из-за того что не редко наблюдал, как множественные benchmark'и существенно отличаются от результатов на практике. В итоге прогнозируешь одно, получаешь совсем другое. В плане сравнения SATA/SAS еще можно делать кое-какие прогнозы, а вот сравнивать с SSD тяжело.

      Еще раз спасибо!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.