По оси X - число дисков в массиве, по оси Y - мегабайтов в секунду.
Я начал изучать проблему. Первичный диагноз был простой - аппаратный рейд не справился с большим числом SSD и упёрся в свой собственный потолок по производительности.
После того, как аппаратный рейд выкинули и на его место поставили HBA, а диски собрали в raid0 с помощью linux-raid (его часто называют "mdadm" по названию утилиты командной строки), ситуация улучшилась. Но не прошла полностью -цифры возросли, но всё ещё были ниже рассчётных. При этом ключевым параметром были не IOPS"ы, а многопоточная линейная запись (то есть большие куски данных, записываемых в случайные места).
Ситуация для меня была необычной - я никогда не гонялся за чистым bandwidth рейдов. IOPS"ы - наше всё. А тут - надо многомногомного в секунду и побольше.
Вот график линейного чтения с одной 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% и при этом показывает меньшую скорость. Почему?
И тут до меня дошло.
Но давайте рассмотрим запись подробнее…
Допустим, у нас raid использует chunk"и размером в 512k. В массиве 8 дисков. Приложение хочет записать много данных, и мы пишем на raid кусками по 4Мб.
Теперь следите за руками:
| Диск 1 | Диск 2 | Диск 3 | Диск 4 | Диск 5 | Диск 6 | Диск 7 | Диск 8 |
| 4.1 | 2.2 | 1.9 | 1.4 | 1.0 | 9.7 | 5.4 | 8.6 |
Видите, как неровно гуляет запись в сравнении с чтением?
У SSD дисков latency на запись очень неровная. Связано это с их внутренним устройством (когда за раз записывается блок большого размера, при необходимости, перемещая и перенося данные с места на место). Чем больше этот блок, тем сильнее пики latency (то есть сиюминутные провалы в производительности). У обычных магнитных дисков графики совсем другие - они напоминают ровную линию практически без отклонений. В случае линейного последовательного IO эта линия проходит высоко, в случае постоянного случайного IO - постоянно низко, но, ключевое - постоянно. Latency у жёстких дисков предсказуема, latency у SSD - нет. Заметим, это свойство есть у всех дисков. У самых дорогих latency оказывается смещена (либо очень быстро, либо очень-очень быстро) - но разнобой всё равно сохраняется.
При подобных колебаниях latency производительность у SSD, в среднем, отличная, но в отдельные моменты времени запись может занять чуть больше, чем в другое время. У тестируемых дисков она падала в этот момент до позорных величин порядка 50Мб/с (что ниже, чем линейная запись у современных HDD раза в два).
Когда на устройство запросы идут стопкой и независимо, это не влияет. Ну да, один запрос выполнился быстро, другой медленно, в среднем всё хорошо.
Но если запись зависит от всех дисков в массиве? В этом случае, любой «тормознувший» диск тормозит всю операцию целиком. В результате, чем больше дисков массиве, тем больше вероятность, что хотя бы один диск отработает медленно. Чем больше дисков, тем больше кривая производительности их суммы в raid0 начинает приближаться к сумме производительности их минимумов (а не средних значений, как хотелось бы).
Вот график реальной производительности в зависимости от числа дисков. Розовая линия - предсказания, базирующиеся на средней производительности дисков, синяя - фактические результаты.
В случае 7 дисков различия составили около 10%.
Простое математическое симулирование (с данными по latency реального диска для ситуации множества дисков в массиве) позволило предсказать, что по мере увеличения числа дисков деградация может дойти до 20-25%.
В отличие от замены HBA или версии драйвера, в этом случае ничего существенно поменять уже нельзя было, и информацию просто приняли к сведению.
Другое дело, что массив из 20-30 HDD - это нормально. 30 SSD в raid0 вызовут слюнки у гиков и приступ печёночной колики у финансового отдела. То есть обычно сравнивают множество HDD c несколькими SSD. Если же мы отнормируем цифры по IOPS"ам (охохо), то есть добьёмся от HDD тех же попугаев, что от SSD, то цифры станут, внезапно, другими - массив из большого числа HDD будет сильно обгонять массив из нескольких SSD по скорости записи.
Другое дело, что крупный массив из HDD - это уже экстрим другого рода, и там ждут сюрпризы из-за общего использования шины, производительности HBA и особенностей поведения бэкплейнов.
Академическое: При планировании высоконагруженных систем с использованием SSD в raid0 следует учитывать, что чем больше в массиве SSD, тем сильнее становится эффект от неравномерной latency. По мере роста числа устройств в raid0 производительность устройства начинает стремиться к произведению числа устройств на минимальную производительность дисков (а не среднюю, как хотелось бы ожидать).
Рекомендации: в случае с подобным типом нагрузки следует стараться выбирать устройства с наименьшим разбросом по latency на запись, по возможности использовать устройства с большей ёмкостью (для уменьшения числа устройств).
Особое внимание стоит обратить на конфигурации, в которых часть или все диски подключаются по сети с неравномерной задержкой, такая конфигурация вызовет значительно большие затруднения и деградацию, чем локальные диски.
Приветствую всех, уважаемые читатели блога сайт! В этой статье я вновь затрону тему SSD дисков. Если в 2010 году твердотельных накопителей (SSD) по всему миру продали на сумму 2.3 млрд $, то уже в 2014 эта сумма выросла до 7.2 млрд $. Твердотельные диски применяются не только для создания мощных игровых ПК, их устанавливают в высокопроизводительные рабочие станции - где требуется большая скорость чтения: системы обработки медиаконтента, базы данных.
SSD диск превосходит обычный винчестер (HDD) по скорости чтения и записи блоков размером 4к. А ведь в этом и состоит основная нагрузка операционной системы на диск. Средний HDD при таких операциях выдает скорость около 1 мегабайта в секунду. Средний «твердотельник» окажется быстрее в десятки раз: 20-40 мегабайт в секунду. Но, не всё так хорошо. SSD диск имеет ограничение в количествах раз, когда вы записали или перезаписали данные, после которого он перестанет работать. У обычного HDD это количество раз - намного выше.
Чтобы повысить надежность хранящихся на SSD данных, придумали делать SSD RAID. Интегрированные RAID контроллеры присутствуют на любой «вменяемой» современной материнской плате. Поэтому есть 3 повода, чтобы сделать рейд из таких дисков:
Начнем с 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 накопителей с помощью параметров 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"ы - наше всё. А тут - надо многомногомного в секунду и побольше.
Вот график линейного чтения с одной 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% и при этом показывает меньшую скорость. Почему?
И тут до меня дошло.
Но давайте рассмотрим запись подробнее…
Допустим, у нас raid использует chunk"и размером в 512k. В массиве 8 дисков. Приложение хочет записать много данных, и мы пишем на raid кусками по 4Мб.
Теперь следите за руками:
| Диск 1 | Диск 2 | Диск 3 | Диск 4 | Диск 5 | Диск 6 | Диск 7 | Диск 8 |
| 4.1 | 2.2 | 1.9 | 1.4 | 1.0 | 9.7 | 5.4 | 8.6 |
Видите, как неровно гуляет запись в сравнении с чтением?
У SSD дисков latency на запись очень неровная. Связано это с их внутренним устройством (когда за раз записывается блок большого размера, при необходимости, перемещая и перенося данные с места на место). Чем больше этот блок, тем сильнее пики latency (то есть сиюминутные провалы в производительности). У обычных магнитных дисков графики совсем другие - они напоминают ровную линию практически без отклонений. В случае линейного последовательного IO эта линия проходит высоко, в случае постоянного случайного IO - постоянно низко, но, ключевое - постоянно. Latency у жёстких дисков предсказуема, latency у SSD - нет. Заметим, это свойство есть у всех дисков. У самых дорогих latency оказывается смещена (либо очень быстро, либо очень-очень быстро) - но разнобой всё равно сохраняется.
При подобных колебаниях latency производительность у SSD, в среднем, отличная, но в отдельные моменты времени запись может занять чуть больше, чем в другое время. У тестируемых дисков она падала в этот момент до позорных величин порядка 50Мб/с (что ниже, чем линейная запись у современных HDD раза в два).
Когда на устройство запросы идут стопкой и независимо, это не влияет. Ну да, один запрос выполнился быстро, другой медленно, в среднем всё хорошо.
Но если запись зависит от всех дисков в массиве? В этом случае, любой «тормознувший» диск тормозит всю операцию целиком. В результате, чем больше дисков массиве, тем больше вероятность, что хотя бы один диск отработает медленно. Чем больше дисков, тем больше кривая производительности их суммы в raid0 начинает приближаться к сумме производительности их минимумов (а не средних значений, как хотелось бы).
Вот график реальной производительности в зависимости от числа дисков. Розовая линия - предсказания, базирующиеся на средней производительности дисков, синяя - фактические результаты.
В случае 7 дисков различия составили около 10%.
Простое математическое симулирование (с данными по latency реального диска для ситуации множества дисков в массиве) позволило предсказать, что по мере увеличения числа дисков деградация может дойти до 20-25%.
В отличие от замены HBA или версии драйвера, в этом случае ничего существенно поменять уже нельзя было, и информацию просто приняли к сведению.
Другое дело, что массив из 20-30 HDD - это нормально. 30 SSD в raid0 вызовут слюнки у гиков и приступ печёночной колики у финансового отдела. То есть обычно сравнивают множество HDD c несколькими SSD. Если же мы отнормируем цифры по IOPS"ам (охохо), то есть добьёмся от HDD тех же попугаев, что от SSD, то цифры станут, внезапно, другими - массив из большого числа HDD будет сильно обгонять массив из нескольких SSD по скорости записи.
Другое дело, что крупный массив из HDD - это уже экстрим другого рода, и там ждут сюрпризы из-за общего использования шины, производительности HBA и особенностей поведения бэкплейнов.
Академическое: При планировании высоконагруженных систем с использованием SSD в raid0 следует учитывать, что чем больше в массиве SSD, тем сильнее становится эффект от неравномерной latency. По мере роста числа устройств в raid0 производительность устройства начинает стремиться к произведению числа устройств на минимальную производительность дисков (а не среднюю, как хотелось бы ожидать).
Рекомендации: в случае с подобным типом нагрузки следует стараться выбирать устройства с наименьшим разбросом по latency на запись, по возможности использовать устройства с большей ёмкостью (для уменьшения числа устройств).
Особое внимание стоит обратить на конфигурации, в которых часть или все диски подключаются по сети с неравномерной задержкой, такая конфигурация вызовет значительно большие затруднения и деградацию, чем локальные диски.
Один SSD против двух в RAID | Два лучше, чем один?
Всего за несколько лет твердотельный накопитель превратился из дорогого экзотического продукта в один из основных комплектующих высокопроизводительных ПК или ноутбуков. Как уже известно, это было обусловлено двумя основными факторами: во-первых, SSD обладают гораздо более высоким быстродействием, чем жёсткие диски, и на порядок более эффективны. Во-вторых, цена за гигабайт NAND-памяти продолжает снижаться благодаря новым технологическими достижениям и экономии за счет роста производства.
Сегодня можно найти множество моделей ёмкостью 128 Гбайт по цене ниже $100. Переход на носители объёмом 256 Гбайт зачастую означает ещё более выгодную цену за гигабайт (почти всегда менее $1, а иногда и $ 0,60 за Гбайт).
Сейчас твердотельные накопители достигли в своем развитии такого уровня, что компьютерные энтузиасты должны принять важное решение: купить один ёмкий SSD или приобрести пару SSD-накопителей меньшей ёмкости и объединить их в конфигурацию RAID 0. Это в значительной степени вопрос производительности. Мы знаем, что производительность одиночных накопителей ограничена возможностями интерфейса SATA 6 Гбит/с. Но существуют ли задачи, требующие пропускной способности двух совместно работающих SSD (в особенности, при последовательной передаче данных)?
Мы попытаемся ответить на этот вопрос, протестировав производительность современных твердотельных накопителей разных ёмкостей. Компания Samsung предоставила нам шесть своих SSD: две модели Samsung 840 Pro по 128 Гбайт, которые будут противостоять модели ёмкостью 256 Гбайт и еще два накопителя по 256 Гбайт для сравнения с ёмкой моделью 512 Гб.
Если вы хотите более подробно узнать о Samsung 840 Pro , ознакомьтесь с нашим обзором "SSD Samsung 840 Pro: непревзойденная скорость, меньшее энергопотребление" , а также с нашими последними исследованиями в статье "Установка SSD в систему с SATA 3 Гбит/с: Есть ли смысл?" .
Один SSD против двух в RAID | Тестовый стенд и бенчмарки
Чтобы измерить и сравнить производительность различных конфигураций из двух и одного SSD Samsung 840 Pro
, мы использовали наш свежий набор тестов для твердотельных накопителей. Сначала мы протестировали их по отдельности: по одному SSD объёмом 128, 256 и 512 Гбайт. Затем мы объединили два твердотельных накопителя по 128 Гбайт и два по 256 Гбайт в RAID 0 и провели серию тестов этих массивов.
Реалистичные тесты:
Скриптовая последовательность для теста пяти приложений:
Тестовый стенд
| Конфигурация тестового стенда | |
| CPU | Intel Core i7-3770K Extreme Edition (22 нм Ivy Bridge), 4 ядра/4 потока, 3,5 ГГц, кэш L2 4 x 256 Кбайт, общий кэш L3 6 Мбайт, TDP 95 Вт, 3,9 ГГц max. Turbo Boost |
| Материнская плата | Asus P8Z77-V Pro, Chipset: Intel Z77 Express, BIOS: 1805 |
| Оперативная память | 2 x 8 Гбайт DDR3-1600 CL10-10-10-27 (Corsair Vengeance CMZ16GX3M2A1600C10) |
| Системный SSD (тесты ввода/вывода и общей производительности) | Samsung 840 Pro, 256 Гбайт, Прошивка DXM04B0Q, SATA 6 Гбит/с |
| Тестируемые SSD | Samsung 840 Pro, 128 Гбайт, Прошивка DXM04B0Q, SATA 6 Гбайт/с Samsung 840 Pro, 256 Гбайт, Прошивка DXM04B0Q, SATA 6 Гбайт/с Samsung 840 Pro, 512 Гбайт, Прошивка DXM04B0Q, SATA 6 Гбайт/с |
| Питание | Seasonic X-760 760 Вт, SS-760KM Active PFC F3 |
| Тесты | |
| Общая производительность | h2benchw 3.16 PCMark 7 1.0.4 |
| Производительность ввода/вывода | IOMeter 2006.07.27 Fileserver-Benchmark Webserver-Benchmark Database-Benchmark Workstation-Benchmark Линейное чтение Линейная запись Случайное чтение блоков по 4 Кбайта Случайная запись блоков по 4 Кбайта |
| Реалистичные тесты | 3ds Max 2013 Finereader 11 Matlab 2012b Photoshop CS6 Powerpoint 2010 |
| ПО и драйверы | |
| Операционная система | Windows 8 x64 Pro |
| Intel RST | 11.7.0.1013 |
Один SSD против двух в RAID | Результаты тестов
Скорость последовательного чтения и записи
Как и ожидалось, конфигурации из двух SSD на 128 Гбайт и 256 Гбайт в RAID 0 в нашем тесте последовательного чтения с лёгкостью обошли одиночные накопители. По сути, два диска ёмкостью 256 Гбайт с чередованием данных обеспечивают примерно вдвое более высокую производительность, чем один SSD. Два SSD по 128 Гбайт не так сильны в последовательной записи, но этого следовало ожидать, учитывая результат отдельного накопителя Samsung 840 Pro 128 Гбайт.
Согласно характеристикам Samsung, модель Samsung 840 Pro
128 Гбайт демонстрирует меньшую скорость чтения и записи, чем более ёмкие версии. Итак, мы получаем стабильные результаты.
Скорость произвольных операций блоками по 4 Кбайт (AS-SSD)
В настольных системах вы чаще всего сталкиваетесь с низкой глубиной очереди. Все конфигурации в этом случае работают почти одинаково. Фактически объединённые накопители даже немного медленнее, чем одиночные диски. Это происходит потому, что мы заполняем полосу пропускания флэш-памяти NAND. Для распределения нагрузки между несколькими устройствами на нескольких каналах необходим параллелизм.
Сразу после перехода на очень высокую глубину разница между работой обеих конфигураций и одиночными накопителями в RAID 0 становится более заметной. Жаль, что такие условия не характерны для задач, исполняемых на обычных ПК, и такие показатели Samsung 840 Pro
можно наблюдать в основном в корпоративных средах.
Скорость произвольного чтения и записи блоками по 4 Кбайт (Iometer)
Наш тест Iometer очень хорошо демонстрирует связь между глубиной очереди и скоростью произвольного чтения и записи.
Диаграммы ниже отражают зависимость средней скорости передачи данных от глубины очереди, которая может составлять от 1 до 32. Как видно из измерений, в произвольном чтении блоками по 4 Кбайт лидируют две конфигурации RAID 0. С результатами скорости записи ситуация не так очевидна. Samsung 840 Pro
на 512 Гбайт обходит два SSD ёмкостью 128 Гбайт, которые сами по себе лишь немного быстрее, чем одиночный SSD на 256 Гбайт.
Однако график роста производительности на разных глубинах очереди более нагляден. Операции чтения при низкой глубине очереди, похоже, снова ограничены возможностями NAND-памяти, и преимущества RAID 0 проявляются лишь при значительной степени параллелизма конфигурации. Запись даёт более высокую нагрузку: два накопителя по 256 Гбайт едва обходят один SSD на 512 Гбайт, а два Samsung 840 Pro
по 128 Гбайт работают чуть быстрее, чем накопитель на 256 Гб.
Время доступа
Результаты тестов показывают, что все конфигурации с одним накопителем обеспечивают более низкий показатель времени доступа, чем объединённые массивы. Однако различия совсем небольшие.
Тесты различных профилей ввода/вывода (Iometer)
Диаграммы представляют среднюю производительность на глубине очереди от 1 до 32 в трёх тестовых профилях: базе данных (Database), веб-сервере (Web server) и рабочей станции (Workstation).
В тестовом профиле веб-сервера Iometer два массива RAID 0 явно обгоняют одиночные накопители на любой глубине очереди. Угадайте, какая модель доступа преобладает в этом тесте? Правильно, 100% чтение.
Тем не менее, профили базы данных и рабочей станции показывают меньшее масштабирование производительности при глубине очереди до восьми. До этого момента Samsung 840 Pro
ёмкостью 512 Гбайт работает примерно так же, как два SSD по 256 Гбайт в RAID 0. Такая же тенденция прослеживается и для одного SSD на 256 Гбайт и двух объединённых дисков по 128 Гбайт.
Синтетические тесты PCMark 7 и PCMark Vantage демонстрируют практически идентичную производительность всех конфигураций SSD. Более заметные различия наблюдаются при отдельных рабочих нагрузках, но они, похоже, взаимоисключаемы.
PCMark Vantage
Тест копирования AS-SSD и общая производительность
Копирование файлов – это операция, для выполнения которой хорошо иметь производительную систему данных, такую, как SSD в конфигурации RAID. В трёх тестах копирования два SSD в связке превысили ограничения интерфейса SATA 6 Гбит/с, показав более высокую пропускную способность, чем может обеспечить любой накопитель в одиночку.
Общая производительность
Благодаря превосходной производительности массивы RAID 0 выигрывают в ряде синтетических тестов как по общему баллу AS-SSD, так и по производительности в условиях нагрузок, свойственных настольным системам. Но всё не так-то просто: реалистичные тесты рисуют иную картину. Высочайшая пиковая скорость последовательной передачи данных в синтетических тестах не обязательно означает такие же показатели в реальности.
Быстрее всего наша тестовая система под управлением загружается на одном Samsung 840 Pro
256 Гб, за ним следует модель ёмкостью 512 Гбайт. Два массива RAID 0 занимают третье и четвёртое места, а замыкает список один накопитель на 128 Гбайт. Тем не менее, разница между первым и последним местом составляет всего 1,1 секунды.
При выключении , лидирует массив RAID из двух SSD по 128 Гбайт. Опять же, перевес незначительный. Разница между первым и последним местом составляет всего лишь 0,4 секунды.
Наш третий реалистичный тест показывает почти такой же результат, что и первые два. Нет практически никакой разницы между конфигурациями из одного SSD или двух в RAID 0. В данном тесте мы загружаем , запускаем Adobe Photoshop CS6 и загружаем изображение.
Реалистичные тесты: Пять приложений
При проведении четвертого и последнего реалистичного теста мы вновь испытали дежавю. После загрузки мы запустили несколько приложений. Различные конфигурации SSD ведут себя идентично, лишь Samsung 840 Pro
ёмкостью 512 Гбайт показал незначительный отрыв.
Один SSD против двух в RAID | RAID 0 - отличный вариант для тестов, но не в реальном мире
Забавная вещь тестирование SSD. Вы можете целый день запускать синтетические испытания, создавая нереальные рабочие нагрузки, которые раскрывают твердотельные накопители с одной стороны. Затем вы можете провести реалистичные тесты, которые рисуют совсем другую картину.
Для энтузиастов зачастую лучше всего подходит золотая середина. Большинство выполняемых задач действительно включают в себя основные операции, такие как открытие веб-браузера, редактирование изображений, работа с электронной почтой и просмотр видео. Но иногда от наших систем требуется более высокая производительность, например, для компиляции большого проекта, перемещения десятков гигабайт медиафайлов или захвата несжимаемых файлов AVI для анализа FCAT. В таких случаях хочется получить требуемое быстродействие.
Как мы и ожидали, два твердотельных накопителя в массиве RAID 0 демонстрируют феноменальные показатели последовательного чтения и записи. В обоих тестах показатели RAID 0 из двух Samsung 840 Pro по 256 Гбайт достигают почти 1 Гбайт/с. В значительной степени из-за ограничений интерфейса SATA 6 Гбит/с показатели одиночных накопителей достигают чуть более половины этих значений.
Конфигурации на базе RAID, несомненно, лидировали в первом тесте, показывая исключительные результаты в рамках последовательного чтения и записи, однако для одиночных накопителей игра ещё не была проиграна. Отдельные твердотельные накопители отвоевали позиции в последующих тестах, даже показав в некоторых из них лучшие результаты. Хорошим примером является скорость произвольных операций ввода/вывода. Накопители с чередованием данных, безусловно, обеспечивают больше IOPS, но только в случае, если вы даёте более четырёх команд сразу. Очерёдность в 32, 16 или даже 8 команд совсем не характерна для настольных ПК или рабочих станций. В результате на практике разница в производительности выражена гораздо меньше.
Одиночные SSD неоднократно лидировали в проведённых нами тестах. Разницу в производительности при перезагрузке и выключении , а затем при запуске различных приложений в лучшем случае можно назвать минимальной, а на практике она вообще не заметна. Иногда отдельные накопители даже умудрялись превзойти RAID массивы.
Если вы планируете обновление и хотите знать, стоит ли покупать пару SSD по 128 Гбайт и объединять их в RAID 0 или, например, просто купить один накопитель ёмкостью 256 Гбайт, ответ для нас очевиден: один накопитель большей ёмкости лучше. К примеру, в данный момент приобретение пары SSD Samsung 840 Pro по 128 Гбайт обойдется вам в $300. Модель ёмкостью 256 Гбайт стоит $240 (может быть, поэтому её сейчас и нет в наличии). Также встаёт вопрос о надёжности. Если один из дисков в конфигурации RAID 0 даёт сбой – то это касается всего массива. По крайней мере, в качестве основного системного накопителя один SSD является более безопасным вариантом.
Есть, конечно, и исключения. Предел интерфейса SATA 6 Гбит/с в настоящее время составляет 500+ Мбайт/с для чтения и до 500 Мбайт/с для записи. Иногда этого просто недостаточно. В качестве примера возьмите необработанные видеоролики в формате AVI, упомянутые ранее. Чтоб не пропускать кадры, мы используем четыре Crucial m4
в RAID 0. В этом случае RAID 0 – обязательное условие, и тот факт, что в массиве находится только отснятое видео, означает, что сбой массива приведет к относительно поверхностным потерям (за исключением стоимости диска). Если вы используете подобное приложение, то наверняка знаете, что один накопитель большого объёма не справится с такой задачей.
Все знают, что 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 |
Тестовый стенд:
Запись процесса загрузки системы и внутриигровых видео осуществлялась через HDMI с помощью ТВ-тюнера AVerMedia AVerTV CaptureHD на другом ПК.
Системное ПО:
Методика тестирования
Глобальные настройки:
Набор тестовых приложений следующий:
В качестве тестовых наборов использовались шаблоны Install (414 файлов общим объемом 575 Мбайт), ISO (3 файла общим объемом 1600 Мбайт) и Programs (8504 файла общим объемом 1380 Мбайт). Для каждого набора измерялась скорость записи всего набора файлов на диск (тест Сreate), скорость чтения этих файлов с диска (Read), скорость копирования файлов внутри одного логического диска (Copy near) и скорость копирования на второй логический диск (Copy far). Агрессивное кэширование записи Windows искажает результаты в тесте Create, а два способа копирования на SSD ничем не отличаются, поэтому ограничусь обнародованием двух оставшихся результатов для каждого шаблона.
