sonyps4.ru

RAID из SSD - находка или бессмыслица? Тестируем массив из SSD на RAID-контроллерах нескольких поколений.

Когда сегодня заходит речь о производительности системы хранения обычно разговор сразу переходит на современные накопители SSD. При этом лидерами являются устройства с интерфейсом PCIe, способные обеспечить на последовательных операциях скорости на уровне нескольких гигабайт в секунду. Если же говорить о моделях с SATA, то здесь у быстрых устройств можно увидеть производительность до 600 МБ/с. На случайных операциях разница между этими классами тоже есть, но она уже менее заметна.

При этом продукты стандартного формата 2,5’’ с интерфейсом SATA имеют несколько преимуществ – они обычно дешевле, могут работать практически в любой системе нескольких последних поколений, из них удобно делать массивы для обеспечения большой емкости СХД (и/или повышения отказоустойчивости), их можно устанавливать в большом количестве в стандартные корпуса.

Использовать чипсетный RAID не очень интересно, так что в этот раз посмотрим, насколько хорошо аппаратные RAID-контроллеры могут работать в подобных конфигурациях. Заметим, что использованное оборудование преимущественно относится скорее к среднему массовому сегменту, чем к наиболее производительным продуктам. Все-таки на рынке уже есть контроллеры и накопители с интерфейсами SAS и PCIe, но это уже совсем другой ценовой уровень.

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

Конфигурация тестовой системы была следующей:

    материнская плата Asus Z87-A

    процессор Intel Core i7-4770

    32 ГБ оперативной памяти

    отдельный SSD для операционной системы

В роли SSD-накопителей выступали четыре Samsung 850 EVO второго поколения по 1 ТБ. Отметим отдельно, что накопители перед этим отработали около семи месяцев в сервере с Linux и никогда не знали TRIM (и по время проведения данных тестов они этого тоже не узнали). При этом прошлая нагрузка была преимущественно на чтение. Объем проведенной записи не превышал двух емкостей диска. По всем параметрам накопители были в отличном состоянии.

Контроллеров удалось найти сразу пять – четыре модели от Adaptec/Microsemi и один от LSI/Broadcom (на фото попали не все):

    Adaptec ASR-6805

    Adaptec ASR-7805

    Adaptec ASR-81605ZQ

    AdaptecSmartRAID 3152-8i

Первый, конечно, уже морально устарел, однако по факту еще много где используется. Так что будет интересно посмотреть, насколько эффективно он сможет работать с новыми накопителями. Второй уже имеет 6 Гбит/с порты и работает на шине PCIe 3.0, так что вполне актуален. Третий представляет собой последнее поколение «классических» решений Adaptec и поддерживает 12 Гбит/с интерфейс для дисков SAS. Реализованную в данной модификации технологию maxCache в этой статье мы использовать не будем. SmartRAID был представлен в конце прошлого года и относится к актуальному поколению RAID-решений компании. К сожалению, он использует новую разметку и схему хранения конфигурации и поэтому не может быть использован для замены прошлых моделей с сохранением данных на дисковых томах. MegaRAID 9361-16i можно считать представителем актуальной линейки продуктов LSI для массивов с накопителями SATA и SAS.

SSD подключались через обычный бекплейн с раздельными каналами для каждого диска. От бекплейна к контроллеру шел один стандартный кабель SAS на четыре канала.

На контроллерах, если не указано обратное, были активированы кэши на чтение и на запись. Все контроллеры имели резервные батареи. Том создавался заново на каждом контроллере, хотя по факту серии 6-7-8 у Adaptec позволяют переносить его без потери данных «в любом направлении».

Поскольку мы ходим протестировать в основном контроллеры, то в качестве основной конфигурации для дискового массива был выбран RAID0 с блоком 256 КБ. При этом надо отметить, что подобное решение может быть использовано и на практике, когда хочется иметь относительно большой и быстрый массив на небольшие деньги. Конечно при условии, что есть резервные копии и время простоя не критично. Да и заявленные производителями цифры по надежности SSD все-таки внушают доверие.

В качестве тестового пакета выступал уже очень немолодой, но все еще пользующийся популярностью IOMeter. Прежде всего, отметим, что опций по выбору конфигураций как массива, так и собственно теста слишком много. С этой стороны это хорошо – вы можете подобрать их исходя из требований своих приложений. С другой – это делает бессмысленно долгим их перебор в рамках одной статьи. Так что были выбраны шесть вариантов шаблонов – три (чтение, запись, 50% чтения и 50% запись) на последовательные операции блоками по 256 КБ (совпадающим с размером блока массива) и три на случайные операции с блоками 4 КБ (наиболее часто используемый размер). В первой группе будем ориентироваться на МБ/с, во второй – на IOPS. Во время тестов использовался один worker, в настройках указывалось для Outstanding I/O значение 32. Тесты проводились на неразмеченном «сыром» томе.

BIOSы, драйвера и программное обеспечения для контроллеров использовались последний версий на момент проведения тестов.

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

Итак, один диск показывает скорость линейного чтения около 400 МБ/с и линейной записи около 160 МБ/с. На случайных операциях получается примерно 95 000 IOPS на чтении и 7 500 IOPS на записи. Для «использованных» устройств это, пожалуй, неплохие результаты. Напомним, что если оценивать современные жесткие диски, то можно рассчитывать примерно на 150-250 МБ/с на линейных операциях и 100-200 IOPS на случайных.

На следующих графиках представлены результаты тестирования массива со стандартными для дисковых массивов настройками контроллеров – когда для тома используется и кэш самого контроллера. Заметим, что при организации тома на SSD некоторые производители рекомендуют не использовать кэш контроллера для увеличения производительности и снижения задержек. Этот вариант мы рассмотрим далее.

Итак, на линейном чтении мы ожидаемо видим пропорциональный количеству дисков в массиве рост. Все контроллеры показывают около 1 600 МБ/с. А вот на записи и смешанной нагрузке уже можно что-то выбрать исходя из своих требований и возможностей. Даже немолодой Adaptec ASR-6805 смотрится не так уж и плохо в этом сценарии.

А вот случайные операции существенно меняют картину. Здесь уже играют роль возможности установленного на контроллерах процессора и можно увидеть существенные отличия. Старший контроллер Adaptec уже явный аутсайдер. Да и ASR-7805 тоже уже не может обеспечить существенного роста на случайном чтении и записи. Так что если важен именно такой сценарий - стоит смотреть на контроллеры последних поколений. Хотя и они способны только в два раза улучшить IOPS на чтении и записи при использовании четырех SSD. Отметим также, что на смешанной нагрузке заметно лучше других выступили Adaptec SmartRAID 3152-8i и LSI 9361-16i.

Посмотрим теперь, что будет если не использовать кэширование на контроллерах. Для модели Adaptec SmartRAID 3152-8i здесь используется специальный предусмотренный производителем режим SSD IO bypass.

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

Еще более интересно выглядят цифры в сценарии случайных операций. Отключение кэша может существенно увеличить скорость доступа на чтении, но и в два раза снижает IOPS на операциях записи. Так что если не стоит задачи снижения времени отклика на большой нагрузке чтением, лучше оставить кэш включенным.

Заметим, что были протестированы только «крайние» варианты - включение кэшей и на чтение на запись и полное отключение кэширования. В реальности у контроллеров есть независимые настройки на чтение и запись, так что конфигураций можно получить больше. Учитывая, что параметры массива можно менять и «на лету» без потери данных, можно самостоятельно подобрать оптимальный для сценария применения вариант. Кроме того, и сами контроллеры могут иметь множество опций «тонкой настройки», которые стоит хотя бы быстро просмотреть.

Подведем итоги. «Бытовые» SATA SSD при работе с RAID-контроллерами чувствуют себя достаточно хорошо. Для раскрытия их возможностей желательно использовать контроллеры последних поколений, способные обеспечить высокие IOPS на случайных операциях. При этом существенное влияние на результаты оказывают настройки тома на контроллере и очень желательно подбирать их исходя из потребностей задач, поскольку «сделать хорошо» одновременно для всех сценариев невозможно.

В качестве бонуса - результаты тестирования конфигурации RAID5 на контроллере Adaptec ASR-7805 на том же оборудовании.



Приветствую всех, уважаемые читатели блога сайт! В этой статье я вновь затрону тему SSD дисков. Если в 2010 году твердотельных накопителей (SSD) по всему миру продали на сумму 2.3 млрд $, то уже в 2014 эта сумма выросла до 7.2 млрд $. Твердотельные диски применяются не только для создания мощных игровых ПК, их устанавливают в высокопроизводительные рабочие станции - где требуется большая скорость чтения: системы обработки медиаконтента, базы данных.

SSD диск превосходит обычный винчестер (HDD) по скорости чтения и записи блоков размером 4к. А ведь в этом и состоит основная нагрузка операционной системы на диск. Средний HDD при таких операциях выдает скорость около 1 мегабайта в секунду. Средний «твердотельник» окажется быстрее в десятки раз: 20-40 мегабайт в секунду. Но, не всё так хорошо. SSD диск имеет ограничение в количествах раз, когда вы записали или перезаписали данные, после которого он перестанет работать. У обычного HDD это количество раз - намного выше.

Чтобы повысить надежность хранящихся на SSD данных, придумали делать SSD RAID. Интегрированные RAID контроллеры присутствуют на любой «вменяемой» современной материнской плате. Поэтому есть 3 повода, чтобы сделать рейд из таких дисков:

  • для улучшения надежности. За это отвечает RAID 1;
  • для повышения скорости передачи данных. Для этого можно сделать RAID 0;
  • всё и сразу. За это у нас отвечает RAID 10.

Начнем с RAID 0. Повышать скорость и без того высокоскоростного SSD диска - придет в голову не каждому, но уж если пришло, тогда вам надо знать, что улучшения будут заметны лишь при простых файловых операциях, например при действиях с файлами формата avi. В большинстве же приложений производительность обычно ограничивается центральным процессором, причем чаще всего скоростью какого-нибудь одного ядра. Важно, что скорость чтения записи мелких блоков данных все равно не поменяется:

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

Я не поленился и нашел на сайте overclockers график времени загрузки «Crysis Warhead» с рейдом и без него. В данном примере скорость загрузки и вовсе - одинаковая. Куда более важна мощность процессора, из-за которого процесс может затянуться.

И это еще без учета недостатков RAID 0 массива, как такового. Про преимущества и недостатки различных типов RAID массивов я уже рассказывал в статье про , не буду повторяться. Да и сама процедура создания массива из SSD - ничем не отличается от таковой, в случае с обычными жесткими дисками. Поэтому, рекомендую прочитать.

Хорошо, с RAID 0 разобрались. А есть ли смысл делать RAID 1 из SSD накопителей, спросите вы? Тут очень спорная ситуация. Теоретически создание массива первого уровня повысит надежность хранимых на твердотельных дисках данных. Массив RAID 1 спокойно переносит выход из строя любого одного диска, но ведь у SSD дисков ограниченное количество циклов перезаписи!

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

А вот RAID 10 на 4-х SSD (минимальное необходимое количество) нивелирует недостатки предыдущих двух конфигураций. Тут вам и скорость - ничуть не хуже, чем у RAID 0. И надежность - на уровне. Согласитесь, выход из строя одновременно 3-х SSD накопителей в RAID массиве уже менее вероятен. А к поломке любых 2-х из них RAID 10 «относится» спокойно. В случае чего, вы успеете заменить их на исправные.

Какой SSD выбрать для создания массива?

Учитывая особенности массивов с чередованием, наиболее логично будет выбрать какие-нибудь стабильные и испытанные SSD, от которых уж точно можно не ждать неприятных «сюрпризов» в самый неподходящий момент. Таких дисков полно. Можете зайти в «яндекс маркет» и отсортировать их по количеству отзывов. В отзывах о популярных моделях вы с большой вероятностью найдете информацию о том, как ведет себя данный диск в массиве.

Когда делаете рейд, полезно проверять состояние SSD накопителей с помощью параметров SMART, чтобы контролировать появление ошибок в прошивках и контроллерах. Хорошим вариантом будет SSD, основанный на контроллерах SF (SandForce) - эти модели опробовали много пользователей, а ошибки были исправлены на программном и аппаратном уровнях.

SSD, основанные на SF контроллерах, обладают мощным набором параметров SMART, в результате чего вы сможете получить всю необходимую информацию о его состоянии. «Бонусом» также будет наличие большого количества технологий, в том числе «RAISE» и «DuraWrite», которые продляют долговечность флеш-памяти. В общем, по надежности такие SSD будут самым лучшим вариантом.

Могу порекомендовать поискать SSD на контроллере SF-2281. При этом, фирмы-производители могут быть разные. Кто-то предпочитает Intel за их качество, а кому-то придется «по душе» более дешевый Kingston HyperX. Но учтите, что модели с объемом в 480 Гб могут оказаться медленнее тех, что имеют на борту всего 240 Гб. Всё дело в том, что для первых - используется восьмикратное чередование NAND, а это вносит некоторые задержки.

Коллеги с соседнего отдела (UCDN) обратились с довольно интересной и неожиданной проблемой: при тестировании raid0 на большом числе SSD, производительность менялась вот таким вот печальным образом:

По оси X - число дисков в массиве, по оси Y - мегабайтов в секунду.

Я начал изучать проблему. Первичный диагноз был простой - аппаратный рейд не справился с большим числом SSD и упёрся в свой собственный потолок по производительности.

После того, как аппаратный рейд выкинули и на его место поставили HBA, а диски собрали в raid0 с помощью linux-raid (его часто называют "mdadm" по названию утилиты командной строки), ситуация улучшилась. Но не прошла полностью -цифры возросли, но всё ещё были ниже рассчётных. При этом ключевым параметром были не IOPS"ы, а многопоточная линейная запись (то есть большие куски данных, записываемых в случайные места).

Ситуация для меня была необычной - я никогда не гонялся за чистым bandwidth рейдов. IOPS"ы - наше всё. А тут - надо многомногомного в секунду и побольше.

Адские графики

Я начал с определения baseline, то есть производительности единичного диска. Делал я это, скорее, для очистки совести.

Вот график линейного чтения с одной SSD.

Увидев результат я реально взвился. Потому что это очень сильно напоминало ухищрения, на которые идут производители дешёвых USB-флешек. Они помещают быструю память в районы размещения FAT (таблицы) в FAT32 (файловой системе) и более медленную - в район хранения данных. Это позволяет чуть-чуть выиграть по производительности при работе с мелкими операциями с метаданными, при этом предполагая, что пользователи, копирующие большие файлы во-первых готовы подождать, а во вторых сами операции будут происходить крупными блоками. Подробнее про это душераздирающее явление: lwn.net/Articles/428584

Я был уверен в том, что нашёл причину и корень всех проблем и уже готовил язвительное послание (см. подписи на картинке), объясняющее, какое унылое некачественное оборудование класса «удобрение» оказалось на тесте, и многие другие слова, которые лучше не повторять.

Хотя меня смутила версия ядра на стенде - 3.2. По своему предыдущему опыту зная прискорбные особенности LSI, меняющие в драйверах (mpt2sas) от версии к версии буквально всё, я подумал, «а вдруг»?

Немного предыстории. mpt2sas - драйвер LSI для HBA. Живёт невероятно бурной жизнью, начав с версии с версии v00.100.11.15 через версии 01.100.0x.00 дойдя аж до версии 16.100.00.00 (интересно, что означает цифра «100»?). За это время драйвер отличился перестановкой имён букв дисков при обновлении минорной версии ядра, отличающемся от аносируемого биосом порядком дисков, падениями на «неожиданных» конфигурациях LUN"ов, на таймаутах бэкплейна, на неожиданном числе дисков, логгинг ошибок в dmesg со скоростью бесконечного цикла в самом ядре (де-факто это эквивалент зависания системы) и тому подобные весёлые вещи.

Обновились, запустили тест. И этот «вдруг» случился. Вот как выглядит тот же график на 3.14. А ведь я чуть-чуть было не забраковал невинные SSD"шки.

После того, как производительность дисков стабилизировалась, был проведён второй тест: на все диски запустили независимые тесты параллельно. Цель была проста - проверить, нет ли бутылочного горлышка где-то на шине или HBA. Производительность дисков оказалась вполне приличной, «затыка» по шине не было. Основная задача была решена. Однако, график производительности всё-таки отличался. Не сильно, но явно с намёком на хуже чем линейную скорость записи.

Почему запись так себя ведёт по мере увеличения числа дисков в массиве? График (в начале статьи) очень сильно напоминал график производительности многопоточных приложений по мере роста числа потоков, на которые обычно показывают программисты и Intel"овцы, когда говорят о проблемах у взаимных блокировок тредов…

Во время теста в blktop наблюдалось что-то странное: часть дисков загружена в потолок, часть почти простаивает. Причём загружены в потолок те, кто показывает низкую производительность, а «быстрые» диски простаивают. Более того, диски иногда меняются местами - то есть раньше загруженный на 100% диск вдруг показывает бОльшую скорость и меньшую загрузку, и наоборот, диск, который был загружен на 50%, вдруг оказывается загружен на 100% и при этом показывает меньшую скорость. Почему?

И тут до меня дошло.

raid0 зависит от latency худшего из дисков

Если мы пишем много данных, то запись обычно идёт большими кусками. Эти куски разделяются на меньшие куски драйвером raid0, который записывает их одновременно на все диски из raid0. За счёт этого мы получаем N-кратное увеличение производительности. (В raid0 на N дисков).

Но давайте рассмотрим запись подробнее…

Допустим, у нас raid использует chunk"и размером в 512k. В массиве 8 дисков. Приложение хочет записать много данных, и мы пишем на raid кусками по 4Мб.

Теперь следите за руками:

  1. raid0 получает запрос на запись, делит данные на 8 кусков по 512кб каждый
  2. raid0 отправляет (параллельно) 8 запросов на 8 устройств по записи 512кб (каждый своё)
  3. raid0 ожидает подтверждение от всех 8 устройств о завершении записи
  4. raid0 отвечает приложению «записал» (то есть возвращает управление из вызова write())
Представим теперь, что у дисков запись произошла за такое время (в милисекундах):
Диск 1 Диск 2 Диск 3 Диск 4 Диск 5 Диск 6 Диск 7 Диск 8
4.1 2.2 1.9 1.4 1.0 9.7 5.4 8.6

Вопрос: за какое время произойдёт запись блока в 4Мб на этот массив? Ответ: за 9.7 мс. Вопрос: какая будет в это время утилизация у диска №4? Ответ: порядка 10%. А у диска №6? 100%. Заметим, для примера я выбрал наиболее экстремальные значения из лога операций, но и при меньшем расхождении проблема будет сохраняться. Сравните график чтения и записи (привожу ту же картинку ещё раз):


Видите, как неровно гуляет запись в сравнении с чтением?

У SSD дисков latency на запись очень неровная. Связано это с их внутренним устройством (когда за раз записывается блок большого размера, при необходимости, перемещая и перенося данные с места на место). Чем больше этот блок, тем сильнее пики latency (то есть сиюминутные провалы в производительности). У обычных магнитных дисков графики совсем другие - они напоминают ровную линию практически без отклонений. В случае линейного последовательного IO эта линия проходит высоко, в случае постоянного случайного IO - постоянно низко, но, ключевое - постоянно. Latency у жёстких дисков предсказуема, latency у SSD - нет. Заметим, это свойство есть у всех дисков. У самых дорогих latency оказывается смещена (либо очень быстро, либо очень-очень быстро) - но разнобой всё равно сохраняется.

При подобных колебаниях latency производительность у SSD, в среднем, отличная, но в отдельные моменты времени запись может занять чуть больше, чем в другое время. У тестируемых дисков она падала в этот момент до позорных величин порядка 50Мб/с (что ниже, чем линейная запись у современных HDD раза в два).

Когда на устройство запросы идут стопкой и независимо, это не влияет. Ну да, один запрос выполнился быстро, другой медленно, в среднем всё хорошо.

Но если запись зависит от всех дисков в массиве? В этом случае, любой «тормознувший» диск тормозит всю операцию целиком. В результате, чем больше дисков массиве, тем больше вероятность, что хотя бы один диск отработает медленно. Чем больше дисков, тем больше кривая производительности их суммы в raid0 начинает приближаться к сумме производительности их минимумов (а не средних значений, как хотелось бы).

Вот график реальной производительности в зависимости от числа дисков. Розовая линия - предсказания, базирующиеся на средней производительности дисков, синяя - фактические результаты.


В случае 7 дисков различия составили около 10%.

Простое математическое симулирование (с данными по latency реального диска для ситуации множества дисков в массиве) позволило предсказать, что по мере увеличения числа дисков деградация может дойти до 20-25%.

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

Что лучше - HDD или SSD?

Сразу скажу: худшее ожидание от SSD оказывается лучше, чем постоянное от HDD (если прозвучало слишком сложно: SSD лучше, чем HDD).

Другое дело, что массив из 20-30 HDD - это нормально. 30 SSD в raid0 вызовут слюнки у гиков и приступ печёночной колики у финансового отдела. То есть обычно сравнивают множество HDD c несколькими SSD. Если же мы отнормируем цифры по IOPS"ам (охохо), то есть добьёмся от HDD тех же попугаев, что от SSD, то цифры станут, внезапно, другими - массив из большого числа HDD будет сильно обгонять массив из нескольких SSD по скорости записи.

Другое дело, что крупный массив из HDD - это уже экстрим другого рода, и там ждут сюрпризы из-за общего использования шины, производительности HBA и особенностей поведения бэкплейнов.

А raid1/5/6?

Легко понять, что для всех этих массивов проблема с ожиданием «самого медленного» сохраняется, и даже слегка усиливается (то есть проблема возникает при меньшем размере блока и меньшей интенсивности нагрузки).

Заключение

Админское: Не люблю LSI. При обнаружении каких-либо нареканий в работе дисков при участии LSI в системе отладку следует начинать с сравнения поведения разных версий дравйера mpt2sas. Это как раз тот случай, когда смена версии может влиять на производительность и стабильность самым драматичным образом.

Академическое: При планировании высоконагруженных систем с использованием SSD в raid0 следует учитывать, что чем больше в массиве SSD, тем сильнее становится эффект от неравномерной latency. По мере роста числа устройств в raid0 производительность устройства начинает стремиться к произведению числа устройств на минимальную производительность дисков (а не среднюю, как хотелось бы ожидать).

Рекомендации: в случае с подобным типом нагрузки следует стараться выбирать устройства с наименьшим разбросом по latency на запись, по возможности использовать устройства с большей ёмкостью (для уменьшения числа устройств).

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

Все знают, что SSD это здорово. Многие также считают, что RAID массивы – залог высокого быстродействия. А хотели ли вы собрать RAID из SSD? Или может быть прикидывали, что выгоднее: приобрести один большой диск, либо наладить совместную работу нескольких маленьких?

Данный материал должен помочь определиться с выбором.

Участники тестирования

Новых накопителей в этот раз не будет. Все они уже участвовали в . Разница лишь в их количестве.

OCZ Vertex 3 Max IOPS, 128 Гбайт


Одиночный Vertex 3 Max IOPS был протестирован в обзоре Vertex 4 . Здесь он выступает в роли «среднего среди лучших» в весовой категории 128 Гбайт.

Прошивка перед тестированием в массивах была обновлена до версии 2.22. Кстати, CrystalDiskInfo 5.0 научился видеть параметры дисков внутри RAID.

Crucial M4, 64 Гбайта


Данный SSD участвовал в статье о накопителях Plextor и проявил себя как весьма шустрый для такого объема накопитель. Основная задача – проверить, как массив из маленьких дисков справится с одним большим.

Использовалась последняя доступная прошивка, а именно 000F.

WD Caviar Blue, 500 Гбайт


Этот уже в полном смысле слова ветеран был протестирован в обзоре кэширующих SSD , а знакомство с линейкой AAKX состоялось еще в 2010м году. Несмотря на то, что Western Digital уже вовсю осваивает терабайтные «блины», этот жесткий диск еще не снят с производства. Возраст же работающих у людей «винчестеров» достигает десятка лет, многие не меняют их до момента поломки, так что можно утверждать, что модель двухлетней давности будет быстрее среднестатистического диска. Если это ваш случай, можете прикинуть, насколько SSD будут быстрее.

Значения S.M.A.R.T. с момента прошлого знакомства «подросли», тем не менее, накопитель в хорошем состоянии.

Сводная таблица технических характеристик

Модель OCZ Vertex 3 Max IOPS Crucial M4 WD Caviar Blue
Номер модели VTX3MI-25SAT3-120G CT064M4SSD2 WD5000AAKX-001CA0
Объем, Гбайт 120 64 500
Форм-фактор 2.5” 2.5” 3.5”
Интерфейс SATA-III SATA-III SATA-III
Версия прошивки 2.15 0309 15.01H15
Устройство Контроллер SandForce SF-2281
+ Toshiba 34 нм синхр.
Toggle Mode FLASH
Контроллер Marvell 88SS9174
+ Micron 25 нм синхр.
ONFI FLASH
1 пластина 500 Гбайт,
7200 об/мин
+ 2 головки
Кэш, Мбайт Нет 128 16

Тестовый стенд и методика тестирования

Тестовый стенд:

  • Материнская плата: ASRock Z68 Extreme7 Gen3 (BIOS 1.30);
  • Процессор: Intel Core i7-2600K, 4.8 ГГц (100 х 48);
  • Система охлаждения: GELID Tranquillo Rev.2;
  • Оперативная память: G.SKILL Ripjaws Z, F3-17000CL9Q-16GBZH (1866 МГц, 8-10-9-26 1N) 2x4 Гбайта;
  • Жесткий диск: WD Caviar Blue, WD3200AAKX-001CA0, 320 Гбайт;
  • Видеокарта: ASUS GTX 580 DirectCu II, 1.5 Гбайт GDDR5;
  • Блок питания: Hipro HP-D6301AW, 630 Вт.

Запись процесса загрузки системы и внутриигровых видео осуществлялась через HDMI с помощью ТВ-тюнера AVerMedia AVerTV CaptureHD на другом ПК.

Системное ПО:

  • Операционная система: Windows 7 x64 SP1 Ultimate RUS;
  • Обновления операционной системы: все на 08.03.2012, включая Direct X;
  • Драйвер для видеокарты: NVIDIA GeForce 295.73;
  • Драйвер для SATA контроллера: Intel RST 11.1, контроллер работает в режиме RAID.

Методика тестирования

Глобальные настройки:

  • В ОС не установлен никакой антивирус, способный влиять на результаты замеров, Windows Defender отключен.
  • По той же причине отключены служба индексирования файлов, служба обновлений и плановая дефрагментация.
  • Отключен Windows UAC, который делал невозможным работу некоторых тестовых программ.
  • Отключены System Restore и гибернация – экономия места на диске.
  • Отключен Superfetch.
  • Файл подкачки – 1 Гбайт.
  • Профиль электропитания – высокая производительность. Отключать диски – никогда.
  • В момент снятия замеров не используются программы фонового мониторинга типа Crystal Disk info, HWMonitor, счетчиков perfmon и прочих.
  • Кэш записи дисков включен, если не указано иное (в диспетчере устройств в свойствах диска на вкладке «политика» поставлена галка «разрешить кэширование записей для этого устройства»). «Повышенная производительность» не активирована. Включен TRIM (DisableDeleteNotify=0). Обычно диск по умолчанию настроен так, но все же нужно удостовериться.
  • Все накопители подключались к порту SATA-III, если не указано иное.

Набор тестовых приложений следующий:

  • Crystal Disk Mark 3.0 x64. Завоевавший популярность тест, который позволяет измерить скорость диска в восьми режимах: чтение и запись при последовательном доступе, в случайном режиме крупными блоками по 512 Кбайт, мелкими блоками по 4 Кбайта и те же 4-Кбайтные запросы при длине очереди к диску в 32 запроса (проверка эффективности работы NCQ и механизмов распараллеливания нагрузки). Использовались настройки по умолчанию, а именно пятикратный прогон несжимаемых данных на участке 1000 Мбайт.

  • PCMark 7 x64. Последняя версия тестового пакета Futuremark.

  • Intel NAS Performance Toolkit 1.7.1. NASPT – очень мощный тест, сопоставимый по функционалу с IOMeter и разработанный прежде всего для тестирования сетевых накопителей. Вполне пригоден и для тестирования локальных дисков.

  • FC-test 1.0 build 11. Программа работала над двумя NTFS разделами, представляющими собой все доступное для форматирования пространство, разделенное пополам. Перед началом каждого замера компьютер перезагружался, весь процесс полностью автоматизирован.

    В качестве тестовых наборов использовались шаблоны Install (414 файлов общим объемом 575 Мбайт), ISO (3 файла общим объемом 1600 Мбайт) и Programs (8504 файла общим объемом 1380 Мбайт). Для каждого набора измерялась скорость записи всего набора файлов на диск (тест Сreate), скорость чтения этих файлов с диска (Read), скорость копирования файлов внутри одного логического диска (Copy near) и скорость копирования на второй логический диск (Copy far). Агрессивное кэширование записи Windows искажает результаты в тесте Create, а два способа копирования на SSD ничем не отличаются, поэтому ограничусь обнародованием двух оставшихся результатов для каждого шаблона.


  • WinRAR 4.11 x64. В этом и всех последующих тестах накопители были системными: эталонный образ Windows, включающий все необходимые программы и дистрибутивы, заливался с помощью Acronis True Image 12. Тестовым файлом служила заархивированная папка Windows 7. 83 000 файлов суммарным объемом 15 Гбайт были сжаты стандартным способом до 5.6 Гбайт. Измерение показало , что на скорость запаковки диски влияют минимально, поэтому для экономии времени тестировалась только распаковка в соседнюю папку.

  • Microsoft Office 2010 Pro Plus. Измерялось время инсталляции из дистрибутива, представляющего собой ISO копию оригинального DVD, смонтированной в Daemon Tools.

  • Photoshop CS5. Всеми любимый графический редактор инсталлировался из ISO образа, подключенного с помощью Daemon Tools. Устанавливались обе версии (x32 и x64) с английским интерфейсом и замерялось время установки. В качестве бенчмарка использовалась схема с этого специализированного форума, а именно - данный скрипт, создающий изображение 18661x18661 пикселей и выполняющий с ним несколько действий. Замерялось общее время выполнения без пауз между операциями. По-хорошему, для подобных вещей нужен громадный объем оперативной памяти, так что тест накопителей, по сути, сводится к проверке скорости работы с scratch-файлом и файлом подкачки Windows. Photoshop’у было дозволено занимать 90% памяти, остальные настройки оставались по умолчанию.
  • Измерялись три отрезка времени: интервал с момента нажатия кнопки power до появления логотипа Windows, время до появления рабочего стола Windows и время до окончания загрузки приложений: в автозагрузке были расположены Word 2010, Excel 2010, Acrobat Reader X и Photoshop CS5, открывающие соответствующие файлы. Помимо этого, в фоновом режиме стартовали Daemon tools и Intel RST. Окончанием загрузки считалось появление фотографии в Photoshop, остальные приложения запускались раньше.
  • Запуск программ. В уже загрузившейся ОС запускался bat файл, запускающий одновременно вышеупомянутые Word, Excel, Acrobat Reader и Photoshop с их документами, а также WinRAR, открывающий тестовый архив с Windows. Самая долгая операция – чтение файлов в архиве и подсчет их количества.

  • Crysis Warhead. Популярный в прошлом шутер использовался для проверки скорости инсталляции и загрузки (с момента покидания рабочего стола до начала 3D сцены). Ранее выяснилось , что дискозависимость у этой игры одна из самых сильных, поэтому в качестве бенчмарка для накопителей она отлично подходит. Установка производилась из оригинального DVD, распакованного на системный диск в виде набора папок. Запуск осуществлялся через утилиту Crysis Benchmark Tool 1.05 со следующими настройками:
    - Quality Settings: Very High;
    - Display resolution: 1280 x 1024;
    - Global settings: 64 bit, DirectX 10;
    - AntiAliasing: no AA;
    - Loops: 1;
    - Map: ambush flythrough;
    - Time of Day: 9.

  • World of Tanks. Известная MMORPG. Игры подобного рода сильно зависят от скорости сети, поэтому все замеры проводились в будни утром на сервере WOT RU2, когда на нем находились 30-35 тысяч человек. Интернет канал 100 Мбит, пинг в игре 20-30 мс. Загружалась карта Химмельсдорф, позиция 1, тренировочный бой 4-8 человек, танк МС-1. Разрешение 1280 x 1024, сглаживание отключено, качество графики очень высоко.

  • Lineage II. Другая известная и очень дискозависимая MMORPG. Использовалась русская официальная версия Goddess of Destruction: Chapter 1 Awakening и два данных реплея . Методика их воспроизведения взята с форума 4game.ru . Замерялось время установки дистрибутива, а также был проведен анализ журнала Fraps frametimes на основе этой методики. Все настройки, кроме разрешения экрана, сделаны в соответствии с рекомендацией:
    - Разрешение: 1280 x 1024, 32bit, 60 Гц, полноэкранный режим;
    - Текстуры, Детализация, Анимация, Эффекты: Низ.;
    - Местность, Персонажи: Очень широко;
    - Лимит PC/NPS: Макс;
    - Погода, Сглаживание, Отражения, Графика, Тени, Детализация земли, Улучшенные эффекты: нет.

Все знают, что SSD это здорово. Многие также считают, что RAID массивы – залог высокого быстродействия. А хотели ли вы собрать RAID из SSD? Или может быть прикидывали, что выгоднее: приобрести один большой диск, либо наладить совместную работу нескольких маленьких?

Данный материал должен помочь определиться с выбором.

Участники тестирования

Новых накопителей в этот раз не будет. Все они уже участвовали в . Разница лишь в их количестве.

OCZ Vertex 3 Max IOPS, 128 Гбайт


Одиночный Vertex 3 Max IOPS был протестирован в обзоре Vertex 4 . Здесь он выступает в роли «среднего среди лучших» в весовой категории 128 Гбайт.

Прошивка перед тестированием в массивах была обновлена до версии 2.22. Кстати, CrystalDiskInfo 5.0 научился видеть параметры дисков внутри RAID.

Crucial M4, 64 Гбайта


Данный SSD участвовал в статье о накопителях Plextor и проявил себя как весьма шустрый для такого объема накопитель. Основная задача – проверить, как массив из маленьких дисков справится с одним большим.

Использовалась последняя доступная прошивка, а именно 000F.

WD Caviar Blue, 500 Гбайт


Этот уже в полном смысле слова ветеран был протестирован в обзоре кэширующих SSD , а знакомство с линейкой AAKX состоялось еще в 2010м году. Несмотря на то, что Western Digital уже вовсю осваивает терабайтные «блины», этот жесткий диск еще не снят с производства. Возраст же работающих у людей «винчестеров» достигает десятка лет, многие не меняют их до момента поломки, так что можно утверждать, что модель двухлетней давности будет быстрее среднестатистического диска. Если это ваш случай, можете прикинуть, насколько SSD будут быстрее.

Значения S.M.A.R.T. с момента прошлого знакомства «подросли», тем не менее, накопитель в хорошем состоянии.

Сводная таблица технических характеристик

Модель OCZ Vertex 3 Max IOPS Crucial M4 WD Caviar Blue
Номер модели VTX3MI-25SAT3-120G CT064M4SSD2 WD5000AAKX-001CA0
Объем, Гбайт 120 64 500
Форм-фактор 2.5” 2.5” 3.5”
Интерфейс SATA-III SATA-III SATA-III
Версия прошивки 2.15 0309 15.01H15
Устройство Контроллер SandForce SF-2281
+ Toshiba 34 нм синхр.
Toggle Mode FLASH
Контроллер Marvell 88SS9174
+ Micron 25 нм синхр.
ONFI FLASH
1 пластина 500 Гбайт,
7200 об/мин
+ 2 головки
Кэш, Мбайт Нет 128 16

Тестовый стенд и методика тестирования

Тестовый стенд:

  • Материнская плата: ASRock Z68 Extreme7 Gen3 (BIOS 1.30);
  • Процессор: Intel Core i7-2600K, 4.8 ГГц (100 х 48);
  • Система охлаждения: GELID Tranquillo Rev.2;
  • Оперативная память: G.SKILL Ripjaws Z, F3-17000CL9Q-16GBZH (1866 МГц, 8-10-9-26 1N) 2x4 Гбайта;
  • Жесткий диск: WD Caviar Blue, WD3200AAKX-001CA0, 320 Гбайт;
  • Видеокарта: ASUS GTX 580 DirectCu II, 1.5 Гбайт GDDR5;
  • Блок питания: Hipro HP-D6301AW, 630 Вт.

Запись процесса загрузки системы и внутриигровых видео осуществлялась через HDMI с помощью ТВ-тюнера AVerMedia AVerTV CaptureHD на другом ПК.

Системное ПО:

  • Операционная система: Windows 7 x64 SP1 Ultimate RUS;
  • Обновления операционной системы: все на 08.03.2012, включая Direct X;
  • Драйвер для видеокарты: NVIDIA GeForce 295.73;
  • Драйвер для SATA контроллера: Intel RST 11.1, контроллер работает в режиме RAID.

Методика тестирования

Глобальные настройки:

  • В ОС не установлен никакой антивирус, способный влиять на результаты замеров, Windows Defender отключен.
  • По той же причине отключены служба индексирования файлов, служба обновлений и плановая дефрагментация.
  • Отключен Windows UAC, который делал невозможным работу некоторых тестовых программ.
  • Отключены System Restore и гибернация – экономия места на диске.
  • Отключен Superfetch.
  • Файл подкачки – 1 Гбайт.
  • Профиль электропитания – высокая производительность. Отключать диски – никогда.
  • В момент снятия замеров не используются программы фонового мониторинга типа Crystal Disk info, HWMonitor, счетчиков perfmon и прочих.
  • Кэш записи дисков включен, если не указано иное (в диспетчере устройств в свойствах диска на вкладке «политика» поставлена галка «разрешить кэширование записей для этого устройства»). «Повышенная производительность» не активирована. Включен TRIM (DisableDeleteNotify=0). Обычно диск по умолчанию настроен так, но все же нужно удостовериться.
  • Все накопители подключались к порту SATA-III, если не указано иное.

Набор тестовых приложений следующий:

  • Crystal Disk Mark 3.0 x64. Завоевавший популярность тест, который позволяет измерить скорость диска в восьми режимах: чтение и запись при последовательном доступе, в случайном режиме крупными блоками по 512 Кбайт, мелкими блоками по 4 Кбайта и те же 4-Кбайтные запросы при длине очереди к диску в 32 запроса (проверка эффективности работы NCQ и механизмов распараллеливания нагрузки). Использовались настройки по умолчанию, а именно пятикратный прогон несжимаемых данных на участке 1000 Мбайт.

  • PCMark 7 x64. Последняя версия тестового пакета Futuremark.

  • Intel NAS Performance Toolkit 1.7.1. NASPT – очень мощный тест, сопоставимый по функционалу с IOMeter и разработанный прежде всего для тестирования сетевых накопителей. Вполне пригоден и для тестирования локальных дисков.

  • FC-test 1.0 build 11. Программа работала над двумя NTFS разделами, представляющими собой все доступное для форматирования пространство, разделенное пополам. Перед началом каждого замера компьютер перезагружался, весь процесс полностью автоматизирован.

    В качестве тестовых наборов использовались шаблоны Install (414 файлов общим объемом 575 Мбайт), ISO (3 файла общим объемом 1600 Мбайт) и Programs (8504 файла общим объемом 1380 Мбайт). Для каждого набора измерялась скорость записи всего набора файлов на диск (тест Сreate), скорость чтения этих файлов с диска (Read), скорость копирования файлов внутри одного логического диска (Copy near) и скорость копирования на второй логический диск (Copy far). Агрессивное кэширование записи Windows искажает результаты в тесте Create, а два способа копирования на SSD ничем не отличаются, поэтому ограничусь обнародованием двух оставшихся результатов для каждого шаблона.


  • WinRAR 4.11 x64. В этом и всех последующих тестах накопители были системными: эталонный образ Windows, включающий все необходимые программы и дистрибутивы, заливался с помощью Acronis True Image 12. Тестовым файлом служила заархивированная папка Windows 7. 83 000 файлов суммарным объемом 15 Гбайт были сжаты стандартным способом до 5.6 Гбайт. Измерение показало , что на скорость запаковки диски влияют минимально, поэтому для экономии времени тестировалась только распаковка в соседнюю папку.

  • Microsoft Office 2010 Pro Plus. Измерялось время инсталляции из дистрибутива, представляющего собой ISO копию оригинального DVD, смонтированной в Daemon Tools.

  • Photoshop CS5. Всеми любимый графический редактор инсталлировался из ISO образа, подключенного с помощью Daemon Tools. Устанавливались обе версии (x32 и x64) с английским интерфейсом и замерялось время установки. В качестве бенчмарка использовалась схема с этого специализированного форума, а именно - данный скрипт, создающий изображение 18661x18661 пикселей и выполняющий с ним несколько действий. Замерялось общее время выполнения без пауз между операциями. По-хорошему, для подобных вещей нужен громадный объем оперативной памяти, так что тест накопителей, по сути, сводится к проверке скорости работы с scratch-файлом и файлом подкачки Windows. Photoshop’у было дозволено занимать 90% памяти, остальные настройки оставались по умолчанию.
  • Измерялись три отрезка времени: интервал с момента нажатия кнопки power до появления логотипа Windows, время до появления рабочего стола Windows и время до окончания загрузки приложений: в автозагрузке были расположены Word 2010, Excel 2010, Acrobat Reader X и Photoshop CS5, открывающие соответствующие файлы. Помимо этого, в фоновом режиме стартовали Daemon tools и Intel RST. Окончанием загрузки считалось появление фотографии в Photoshop, остальные приложения запускались раньше.
  • Запуск программ. В уже загрузившейся ОС запускался bat файл, запускающий одновременно вышеупомянутые Word, Excel, Acrobat Reader и Photoshop с их документами, а также WinRAR, открывающий тестовый архив с Windows. Самая долгая операция – чтение файлов в архиве и подсчет их количества.

  • Crysis Warhead. Популярный в прошлом шутер использовался для проверки скорости инсталляции и загрузки (с момента покидания рабочего стола до начала 3D сцены). Ранее выяснилось , что дискозависимость у этой игры одна из самых сильных, поэтому в качестве бенчмарка для накопителей она отлично подходит. Установка производилась из оригинального DVD, распакованного на системный диск в виде набора папок. Запуск осуществлялся через утилиту Crysis Benchmark Tool 1.05 со следующими настройками:
    - Quality Settings: Very High;
    - Display resolution: 1280 x 1024;
    - Global settings: 64 bit, DirectX 10;
    - AntiAliasing: no AA;
    - Loops: 1;
    - Map: ambush flythrough;
    - Time of Day: 9.

  • World of Tanks. Известная MMORPG. Игры подобного рода сильно зависят от скорости сети, поэтому все замеры проводились в будни утром на сервере WOT RU2, когда на нем находились 30-35 тысяч человек. Интернет канал 100 Мбит, пинг в игре 20-30 мс. Загружалась карта Химмельсдорф, позиция 1, тренировочный бой 4-8 человек, танк МС-1. Разрешение 1280 x 1024, сглаживание отключено, качество графики очень высоко.

  • Lineage II. Другая известная и очень дискозависимая MMORPG. Использовалась русская официальная версия Goddess of Destruction: Chapter 1 Awakening и два данных реплея . Методика их воспроизведения взята с форума 4game.ru . Замерялось время установки дистрибутива, а также был проведен анализ журнала Fraps frametimes на основе этой методики. Все настройки, кроме разрешения экрана, сделаны в соответствии с рекомендацией:
    - Разрешение: 1280 x 1024, 32bit, 60 Гц, полноэкранный режим;
    - Текстуры, Детализация, Анимация, Эффекты: Низ.;
    - Местность, Персонажи: Очень широко;
    - Лимит PC/NPS: Макс;
    - Погода, Сглаживание, Отражения, Графика, Тени, Детализация земли, Улучшенные эффекты: нет.


Загрузка...