Тестирование SSD-диска Intel X25-M 160 Гбайт
Результаты тестирования и их анализ
В статье «Особенности работы современных SSD-дисков», опубликованной в этом номере журнала, мы изложили теоретические основы функционирования SSD-дисков на основе NAND флэш-памяти и, в частности, рассмотрели такие явления, как разница в производительности нового и ранее использовавшегося SSD-дисков, а также рассказали о способах повышения производительности SSD-дисков. В этой статье мы постараемся подкрепить изложенные нами теоретические основы практическими примерами на основе рассмотрения результатов тестирования нового SSD-диска Intel X25-M (Gen 2) емкостью 160 Гбайт.
Технические характеристики
Прежде чем приступить к детальному анализу результатов тестирования диска Intel X25-M, давайте рассмотрим его характеристики. Итак, речь идет о втором поколении 2,5-дюймовых SSD-дисков Intel (Gen 2) на основе NAND флэшпамяти c MLC-ячейками (каждая ячейка памяти является четырехуровневой и может хранить два бита информации). Емкость диска составляет 160 Гбайт. Напомним, что в SSD-дисках доступная для использования емкость указывается не в двоичных, а в десятичных гигабайтах, то есть 1 Гбайт = 109 байт. Поэтому емкость этого диска, доступная для применения, составляет примерно 150 двоичных гигабайт.
Если точнее, то реальная емкость диска Intel X25-M действительно составляет 160 двоичных гигабайт, однако часть памяти используется как резервная область диска и недоступна для применения. Собственно, резервная область диска как раз и представляет собой разницу между 160 двоичными и 160 десятичными гигабайтами, в данном случае ее размер равен 11 Гбайт (двоичных).
Диски Intel X25-M второго поколения (Gen 2) выполнены на основе 34-нм микросхем NAND флэшпамяти. Напомним, что в предыдущем поколении SSD-дисков Intel использовались 50-нм микросхемы памяти. Впрочем, изменение техпроцесса производства микросхем NAND флэшпамяти — это не единственное различие между дисками первого и второго поколений. Куда более значительные изменения связаны с самим контроллером SSD-диска, на который ориентированы новые прошивки (Firmware). Благодаря применению нового контроллера и прошивки диск Intel X25-M второго поколения имеет более высокие скоростные показатели в сравнении с дисками первого поколения. Так, в таблице представлены данные результатов теста IOmeter, приводимые в спецификации на диски Intel X25-M. Как видите, в дисках второго поколения увеличена скорость последовательной и выборочной записи. Остальные характеристики дисков практически не отличаются друг от друга, если не считать того обстоятельства, что у новых дисков на порядок снижена частота возникновения ошибки чтения.
Еще одно важное различие между дисками первого и второго поколений заключается в том, что диски Intel X25-M второго поколения поддерживают команду TRIM, в то время как диски первого поколения — нет. В статье «Особенности работы современных SSD-дисков», опубликованной в этом номере журнала, мы подробно описали, что делает эта команда и зачем она нужна, а потому лишь напомним, что при удалении файла операционная система посылает команду TRIM контроллеру диска и дает ему знать, какие страницы памяти могут быть перезаписаны, то есть содержат устаревшие данные. Соответствующие страницы памяти помечаются к удалению и могут быть использованы в процедуре Garbage Collection.
Поддержка команды TRIM позволяет уменьшить показатель Write Amplification и тем самым способствует сокращению циклов перезаписи каждой отдельной ячейки памяти. Для работы команды TRIM необходима поддержка как со стороны ОС, так и со стороны драйвера диска (драйвера контроллера на системной плате) и контроллера самого SSD-диска. Команда TRIM реализована в операционной системе Windows 7, а также в ядре Linux, начиная с ревизии 2.6.28. Что касается поддержки команды TRIM в драйверах контроллера на системной плате, то она имеется в стандартном драйвере Microsoft, а также в драйвере Intel RST 9.6 (в случае использования чипсетов Intel), причем в случае применения драйвера Intel RST 9.6 команда TRIM поддерживается также и для RAID-массивов.
Поддержка команды TRIM контроллером SSD-диска зависит от его прошивки. Отметим, что в некоторых случаях обновление прошивки диска позволяет воспользоваться преимуществами команды TRIM, а в некоторых — нет. В частности, для дисков Intel X25-M первого поколения нет и не будет прошивки с поддержкой команды TRIM, а вот для дисков второго поколения поддержка TRIM реализована в прошивке. Попутно отметим, что мы тестировали диск Intel X25-M (Gen 2) с последней (на момент тестирования) версией прошивки 2CV102HD. Немаловажно подчеркнуть, что для дисков Intel X25-M предусмотрена очень простая процедура обновления прошивки контроллера. Для этого достаточно скачать с сайта Intel ISO-образ программы установки. Данный ISO-образ позволяет создать загрузочный CD/DVD-диск с программой установки новой версии прошивки контроллера. Ну а дальнейшая процедура очень проста: загружаем компьютер с CD/DVD-диска, выбираем, согласно инструкции на экране, нужный нам SSD-диск Intel (если их несколько) и подтверждаем операцию обновления прошивки контроллера.
Кроме утилиты для перепрошивки контроллера, для дисков Intel X25-M второго поколения предназначена еще одна очень полезная программа — Intel SSD Toolbox (текущая версия 1.3). Она представляет собой набор инструментов для работы с SSD-дисками и поддерживает только 34-нм диски Intel, то есть диски второго поколения, в которых реализована поддержка команды TRIM.
После установки и запуска программы Intel SSD Toolbox в главном окне отображаются все подключенные к компьютеру диски. Выбрав нужный диск, можно получить доступ к одной из пяти функций: Intel SSD Management Tools, View Drive Information, Check SMART Attributes, Run Fast Diagnostic Scan и Run Full Diagnostic Scan (рис. 1).
Рис. 1. Главное окно программы Intel SSD Toolbox
Функции View Drive Information и Check SMART Attributes реализованы для всех подключенных дисков, а остальные функции — только для SSD-дисков Intel второго поколения. Функция View Drive Information отображает всю информацию о диске (номер модели, серийный номер, номер микрокода и т.д.), а функция Check SMART Attributes показывает SMART-таблицу устройства и, при необходимости, действие, которое следует выполнить. В случае SSD-диска Intel SMART-таблица отображает и такие данные, как полный объем данных, записанных на диск, а также множество другой полезной информации.
Функция Run Fast Diagnostic Scan позволяет запустить сканирование (проверку) первых 1,5 Гбайт SSD-диска на наличие любых ошибок чтения или записи, а функция Run Full Diagnostic Scan запускает сканирование всего SSD-диска на наличие любых ошибок чтения или записи, а также дефектных блоков.
Наиболее полезной является функция Intel SSD Management Tools (средства управления твердотельными дисками Intel SSD). Собственно, из средств управления SSD-дисками Intel имеется только одно, но очень полезное. Речь идет об утилите Intel SSD Optimizer, которую можно запускать как в ручном режиме, так и по расписанию.
Если проводить аналогию, то как процедура дефрагментации для HDD-дисков позволяет увеличивать их производительность, которая уменьшается по мере фрагментации файлов на диске, так и утилита Intel SSD Optimizer оптимизирует производительность SSD-дисков, снижающуюся по мере их эксплуатации. Напомним, что для SSD-дисков процедура дефрагментации не только бесполезна, но и вредна, поскольку приводит лишь к их более быстрому износу. Но точно так же, как для HDD-дисков нужно периодически проводить процедуру дефрагментации, так для SSD-дисков Intel следует регулярно (рекомендуется раз в неделю) выполнять процедуру оптимизации с использованием инструмента Intel SSD Optimizer.
Сразу оговоримся, что запускать утилиту Intel SSD Optimizer имеет смысл только в том случае, если применяется операционная система, не поддерживающая команду TRIM (например, Windows XP или Windows Vista). Тогда утилита Intel SSD Optimizer будет просматривать таблицу размещения файлов на уровне операционной системы и, находя в ней файлы, помеченные к удалению, посылать контроллеру SSD-диска команду TRIM, что приведет к тому, что соответствующие этим файлам страницы памяти SSD-диска также будут помечаться к удалению. Соответственно в дальнейшем это повысит эффективность процедуры Garbage Collection, что отразится на повышении производительности и износостойкости диска.
Если же используется операционная система Windows 7 со стандартным драйвером Microsoft AHCI, то в запуске утилиты Intel SSD Optimizer нет необходимости, поскольку команда TRIM поддерживается самой операционной системой.
Исключение составляет случай, когда применяется операционная система Windows 7, но с драйвером Intel Matrix Storage Manager (версия 8.x). Этот драйвер не поддерживает команду TRIM, поэтому имеет смысл периодически запускать утилиту Intel SSD Optimizer.
Кроме того, если используется операционная система Windows 7 с драйвером Intel RST 9.6, то команда TRIM поддерживается только для дисков, не объединенных в RAID-массив. Если же применяется RAID-массив, то следует периодически запускать утилиту Intel SSD Optimizer.
Сопоставляя диски Intel X25-M первого и второго поколений, заметим, что определить, о каком именно диске (первого или второго поколения) идет речь, очень просто. Поколение дисков Intel указывается в полном названии модели. К примеру, в нашем случае полное название модели диска SSDSA2MH160G2R5, а расшифровка его такая. Первые три буквы — SSD — это тип диска, следующие две буквы —SA — определяют интерфейс диска, в нашем случае это SATA (возможны также буквы PA (PATA) и US (USB). Идущая далее цифра указывает на формфактор диска: 1 — 1,8 дюйма, 2 — 2,5 дюйма. Следующая буква характеризует тип ячеек памяти: M — MLC, S — SLC. Буква за ней (H) свидетельствует о том, что речь идет о высокопроизводительном диске (High Performance). Далее три цифры и одна буква определяют емкость диска, например 160G означает, что диск имеет емкость 160 Гбайт. Затем идет цифра, которая как раз указывает на поколение диска: 1 — первое поколение, 2 — второе поколение. В названии модели присутствуют еще две буквы, которые определяют номер заказа, но это уже не столь важно.
Да и по внешнему виду диск Intel X25-M (Gen 2) отличается от диска первого поколения: он выполнен в металлическом серебристом корпусе с черной пластиковой рамкой сверху. Кроме того, в комплектацию диска входит монтажная рамка для установки его в 3,5-дюймовый отсек.
Методика тестирования
После обзора диска Intel X25-M Gen 2 можно перейти к анализу результатов его тестирования, но сначала подробно расскажем о том, как именно оно проводилось.
При тестировании диска Intel X25-M Gen 2 мы не ставили себе задачу сравнить его по производительности с другими SSD-дисками. Главной целью нашего тестирования было изучение зависимости скоростных характеристик диска от различных условий.
Конфигурация стенда
Для тестирования мы использовали стенд следующей конфигурации:
- процессор — Intel Core i7-965 EE;
- системная плата — Gigabyte GA-EX58-UD4;
- чипсет системной платы — Intel X58 Express (южный мост ICH 10R);
- BIOS системной платы — F10;
- диск с операционной системой — Seagate Barracuda ST31500341AS (7200 RPM, 1,5 Тбайт);
- режим работы SATA — AHCI;
- драйвер дисков — Intel RST 9.6;
- версия прошивки тестируемого диска — 2CV102HD;
- контроллер диска — интегрированный в чипсет контроллер Intel X58 Express.
Диск Intel X25-M (Gen-2) имел прошивку 2CV102HD (последняя версия прошивки на момент тестирования).
При тестировании применялась операционная система Window 7 Ultimate (32 bit). Дополнительно устанавливался драйвер Intel RST 9.6, а сам диск Intel X25-M подключался к SATA-порту, реализованному через контроллер, интегрированный в южный мост чипсета Intel X58 Express. К еще одному SATA-порту подключался HDD-диск, на который устанавливалась операционная система и все необходимые для тестирования приложения. В настройках BIOS для всех SATA-портов задавался режим работы AHCI.
Утилита IOmeter
Для тестирования мы использовали только утилиту IOmeter версии 2008.06.18 (последняя версия на момент тестирования), которая представляет собой очень мощный инструмент для анализа производительности накопителей -— как HDD, так и SSD (рис. 2). Кстати, данная утилита была разработана компанией Intel, код этой программы открыт и она поддерживается группой независимых разработчиков.
Рис. 2. Главное окно утилиты IOmeter
Утилита IOmeter позволяет работать как с дисками, на которых создан логический раздел, так и с дисками без логического раздела. В случае если проводится тестирование диска без созданного на нем логического раздела, то IOmeter работает на уровне логических блоков данных, то есть вместо операционной системы передает команды контроллеру на запись или чтение LBA-блоков.
Если на диске создан логический раздел, то первоначально утилита IOmeter создает на диске файл, который по умолчанию занимает весь логический раздел (в принципе, размер этого файла можно изменять, указав его в количестве 512 байтных секторов), и далее уже работает с этим файлом, то есть считывает или записывает (перезаписывает) отдельные LBA-блоки в пределах этого файла. Но опять-таки IOmeter работает в обход операционной системы, то есть непосредственно посылает запросы контроллеру на чтение/запись данных.
Вообще, при тестировании HDD-дисков, как показывает практика, разницы между результатами тестирования диска с созданным логическим разделом и без него практически нет. Однако для SSD-дисков разница наблюдается довольно существенная (почему это так, мы обсудим позже), а потому мы проводили тестирование SSD-диска как с созданным логическим разделом, так и без него.
При этом утилита IOmeter (рис. 3) позволяет задавать размер блока запроса (Transfer Request Size) на запись/чтение данных, тестирование можно проводить как для последовательных (Sequential) чтения и записи, то есть когда LBA-блоки считываются и записываются последовательно друг за другом, так и для случайных (Random) чтения и записи, когда LBA-блоки считываются и записываются в произвольном порядке. При формировании сценария нагрузки можно задавать время теста, процентное соотношение между последовательными и случайными операциями (Percent Random/Sequential Distribution), а также процентное соотношение между операциями чтения и записи (Percent Read/Write Distribution). Кроме того, утилита IOmeter позволяет автоматизировать весь процесс тестирования и сохраняет все результаты в CSV-файл, который затем легко экспортируется в таблицу Excel.
Рис. 3. Возможности по настройке теста в утилите IOmeter
Еще одна интересная настройка, которую позволяет делать утилита IOmeter, — это так называемое выравнивание блоков запросов на передачу данных (Align I/Os on) по границам секторов жесткого диска. По умолчанию IOmeter выравнивает блоки запросов по границам 512-байтных секторов диска, однако можно задать и произвольное выравнивание. Вообще говоря, у SSD-дисков нет никаких секторов, и, казалось бы, такая настройка не актуальна для них. Однако это не так, поскольку все операционные системы ориентированы на работу не c SSD-, а с HHD-дисками и считают, что у всех дисков размер сектора составляет 512 байт. Собственно, большинство жестких дисков имеют размер сектора 512 байт и только в последнее время стали появляться диски с размером сектора 4 Кбайт. Напомним, что в HDD-дисках сектор — это минимальный адресуемый размер данных, который можно записать или считать с диска.
В SSD-дисках аналогом сектора является страница памяти размером 4 Кбайт, за тем исключением, что страницу можно записать и считать, а удалить можно только блок, состоящий из большого количества страниц (обычно из 128 страниц). В HDD-дисках каждый физический сектор жестко связан с логическим сектором (LBA), который, собственно, и адресуется. В SSD-дисках такого жесткого соответствия между логическими секторами LBA и физическими страницами памяти (PBA) нет, и для их соответствия используется специальная таблица LBA — PBA.
Собственно, для того чтобы обмануть операционную систему, если размер сектора составляет не 512 байт, каждый адресуемый логический сектор разбивается на абстрактные 512-байтные секторы. К примеру, для SSD-дисков каждый логический адресуемый сектор размером 4 Кбайт разбивается на восемь 512-байтных секторов и для операционной системы такие диски всё равно выглядят как традиционные диски с 512-байтными секторами.
Теперь рассмотрим пример, когда имеется запрос на передачу данных размером 4 Кбайт (рис. 4). Проще говоря, такой запрос означает, что требуется записать или прочитать блок данных размером 4 Кбайт, начиная с определенного 512-байтного сектора. То есть запрос всегда выровнен по границе какого-либо 512-байтного сектора, однако при этом он может быть не выровнен по границе логического сектора LBA. Если запрос выровнен и по границе логического сектора LBA, то достигается максимальная производительность. Если, к примеру, речь идет о запросе на запись блока размером 4 Кбайт, то один такой запрос займет ровно один логический сектор (одну страницу памяти).
Рис. 4. Запрос на передачу блока
данных размером 4 Кбайт, выровненный
относительно логического сектора LBA
Но что произойдет, если запрос не выровнен относительно границы логического сектора LBA? То есть если в запросе говорится, что нужно прочитать или записать блок данных определенного размера (кратного 512 байтам), начиная с определенного 512-байтного сектора, причем начало этого сектора не совпадает с началом логического сектора LBA. Рассмотрим, как и в предыдущем примере, случай с запросом на передачу блока данных размером 4 Кбайт (рис. 5). Запрос будет соответствовать уже не одному, а двум логическим секторам. Если речь идет о запросе на запись, то это приведет к тому, что блок данных размером 4 Кбайт будет размещаться в двух 4-килобайтных страницах памяти. Более того, это приведет к резкому снижению производительности (придется записывать не одну, а две страницы памяти) и отразится на долговечности SSD-диска, поскольку количество циклов записи каждой ячейки флэшпамяти ограничено.
Рис. 5. Запрос на передачу блока данных
размером 4 Кбайт, не выровненный относительно
логического сектора LBA
Каким же образом можно разрешить данную проблему? Как мы уже отмечали, утилита IOmeter по умолчанию выравнивает запросы на передачу блоков данных по границам 512-байтных секторов. Для того чтобы запросы выравнивались по границам логических секторов, достаточно указать в настройках IOmeter выравнивание запросов не по 512-байтным секторам, а по блокам, равным или кратным 4 Кбайт, то есть кратным размеру логического сектора.
В случае если размер запроса на передачу блока данных превышает размер логического сектора (например, используется запрос на запись блока данных размером 8 Кбайт), но при этом применяется выравнивание запросов по границам 4-килобайтных логических секторов, то при случайной записи может возникнуть ситуация, когда два запроса, следующих друг за другом, окажутся не выровненными друг относительно друга (рис. 6). Это приведет к тому, что один из двух использованных до этого логических секторов будет перезаписан, а соответствующая этому логическому сектору страница памяти будет помечена к удалению, что, в свою очередь, приведет к дополнительной дефрагментации страниц памяти, помеченных к удалению, и дополнительной нагрузке на контроллер диска по оптимизации таблицы размещения. В принципе, ничего страшного в этом нет, поскольку речь идет о сценарии случайной записи, однако для чистоты эксперимента желательно выравнивать запросы на передачу блоков данных не только по границам логических разделов, но и друг относительно друга. Естественно, что это возможно только в том случае, если сами запросы кратны размерам логических секторов. Поэтому при тестировании SSD-диска во всех сценариях нагрузки мы устанавливали выравнивание запросов по блокам, равным размеру запроса (дабы выровнять запросы друг относительно друга), а сами размеры запросов выбирали кратными 4 Кбайт.
Рис. 6. Запросы на передачу данных,
не выровненные друг относительно друга
Отметим, что в некоторых случаях (в частности, с дисками Intel) выравнивание запросов по границам логических секторов никак не отражается на результатах тестирования. Дело в том, что в данном случае контроллер SSD учитывает несоответствие 512-байтных секторов логическим 4-килобайтным секторам и выполняет процедуру выравнивания автоматически. Но, чтобы использовать одни и те же настройки теста для тестирования любых SSD-дисков, мы применяли описанную настройку выравнивания запросов на передачу блоков данных.
Что касается функциональных возможностей утилиты IOmeter применительно к тестированию SSD-дисков, то отметим, что она не позволяет продемонстрировать преимущество использования команды TRIM, поскольку в случае тестирования диска как без созданного логического раздела, так и с созданным логическим разделом никакие файлы на уровне операционной системы с диска не удаляются, а команду TRIM операционная система может посылать только при удалении файла. Впрочем, это обстоятельство нисколько не умаляет достоинств утилиты IOmeter как инструмента для анализа производительности SSD-дисков.
Сценарии нагрузки диска
После описания возможностей утилиты IOmeter самое время огласить список тех сценариев нагрузки, которые мы использовали для тестирования диска Intel X25-M (Gen 2). Однако прежде напомним, что производительность SSD-диска зависит от того, новый он (ранее не использовавшийся) или нет. Под новым мы будем понимать SSD-диск, не содержащий никаких данных, то есть диск, у которого все физические страницы памяти свободны. Причем отсутствие, с точки зрения операционной системы, на диске файлов еще не означает, что страницы памяти диска не содержат данных. Контроллер самого диска при этом может считать, что страницы памяти диска заполнены данными.
Под ранее использовавшимся диском мы будем понимать диск, все страницы памяти которого уже были заполнены данными как минимум один раз. При этом неважно, помечены эти страницы памяти к удалению или нет.
Собственно, именно поэтому при тестировании SSD-диска мы применяли сценарии нагрузки как с новыми дисками, так и с ранее использовавшимися. Естественно, возникает вопрос: а как получить новый диск? Ведь уже после первого теста он будет не совсем новым.
Для того чтобы привести использовавшийся SSD-диск к состоянию нового или «диска из коробки» (out of box), применяются специализированные утилиты, которые удаляют все данные с диска в безопасном режиме. Это так называемые утилиты класса Security Erase или Disk Wiper. Они удаляют все данные с диска без возможности их восстановления. Все подобные утилиты ориентированы на HDD-диски, восстановление данных возможно даже после низкоуровневого форматирования (правда, для этого уже требуется специальное оборудование). Существуют различные алгоритмы и стандарты безопасного удаления данных, суть которых сводится к тому, что диск несколько раз подряд заполняется различными (к примеру, псевдослучайными) данными, в результате чего происходит полное перемагничивание всех секторов магнитного диска и восстановить данные уже невозможно. Отметим, что в результате безопасного удаления данных диск оказывается заполненным всяким «мусором», но, естественно, операционная система об этом не знает и считает, что он пустой.
Специализированных утилит для очистки SSD-дисков не существует. К сожалению, даже компания Intel не предлагает для своих дисков подобной утилиты, поэтому традиционно используются утилиты сторонних производителей для безопасного удаления данных с HDD-дисков. Вообще, у нас есть некоторые сомнения относительно корректности приведения SSD-дисков к их первоначальному состоянию путем применения утилит для безопасного удаления данных с HDD-дисков. Дело в том, что после такого удаления все страницы памяти будут не пустыми, а заполнеными «мусором». Вполне возможно, что все эти страницы памяти будут отмечены в таблице размещения к удалению, но, тем не менее, они не будут пустыми. Чтобы действительно привести SSD-диск к его первоначальному состоянию, нужно провести операцию стирания всех блоков памяти и обнулить таблицу размещения, и вряд ли эту процедуру можно выполнить с помощью утилит безопасного удаления данных.
Впрочем, провести процедуру очистки диска с помощью утилит безопасного удаления данных — это, конечно, лучше, чем ничего. Более того, на практике результаты тестирования действительно нового диска (диска, который только что достали из коробки и подключили к компьютеру) и диска, очищенного с использованием утилиты безопасного удаления данных, практически не отличаются друг от друга. А потому в дальнейшем будем считать, что диск, очищенный с помощью утилиты безопасного удаления, — это полный аналог нового диска.
Наиболее распространенной утилитой, которая используется для очистки SSD-дисков при тестировании, является бесплатная утилита HDD Eraser (текущая версия 4.0). Ее можно скачать как отдельно, так и в составе известного сборника программных утилит Hiren`s BootCD 11.0. Утилита HDD Eraser грузится из-под DOS, то есть необходимо иметь загрузочный диск с ядром DOS и данной утилитой либо воспользоваться загрузочным диском Hiren`s BootCD 11.0. Кроме того, прежде чем пользоваться этой утилитой, следует в настройках BIOS переключить порты SATA, к которым подключен диск, из режима AHCI в режим IDE (в противном случае утилита HDD Eraser просто не увидит никаких дисков).
Первоначально мы пытались воспользоваться утилитой HDD Eraser из набора загрузочного диска Hiren`s BootCD 11.0. С дисками Intel X25-M первого поколения никаких проблем при применении утилиты HDD Eraser не возникало. С дисками второго поколения всё оказалось сложнее. Вопервых, утилита HDD Eraser не видит дисков Intel X25-M (Gen 2), а во-вторых, что еще более печально, как только она пытается просканировать систему на предмет подключенных дисков, диск Intel X25-M (Gen 2) переходит в заблокированное состояние (операционная система не видит логического раздела диска) и реанимировать его (создать вновь логический раздел) средствами операционной системы уже не удается. Собственно, полдня у нас ушло на то, чтобы найти утилиту, которая смогла бы разблокировать его после этого. Поэтому для очистки диска Intel X25-M (Gen 2) мы применяли программу Paragon Disk Wiper 2010 c алгоритмом однопроходного заполнения всех секторов нулями.
Для того чтобы получить использованный диск, то есть диск, в котором все страницы памяти уже записаны данными, с помощью утилиты IOmeter мы проводили случайную запись блоками по 64 Кбайт в течение такого времени, чтобы суммарный объем записанных на диск данных в 1,5 раза превышал его размер.
После описания метода восстановления SSD-диска к его первоначальному состоянию приведем список сценариев загрузки диска Intel X25-M (Gen 2) при его тестировании.
Процесс тестирования мы разделили на два этапа. На первом этапе исследовалась зависимость скорости выполнения операций последовательного и случайного чтения, а также последовательной записи от размера блока запроса на передачу данных. В этих тестах использовались следующие сценарии нагрузок:
- последовательное чтение диска с созданным на нем логическим разделом;
- последовательное чтение диска без созданного на нем логического раздела;
- случайное чтение диска с созданным на нем логическим разделом;
- случайное чтение диска без созданного на нем логического раздела;
- последовательная запись нового диска с созданным на нем логическим разделом;
- последовательная запись нового диска без созданного на нем логического раздела;
- последовательная запись использовавшегося ранее диска без созданного на нем логического раздела.
Во всех перечисленных сценариях загрузки применялись запросы на передачу данных блоками следующих размеров: 512 байт, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 Кбайт и 1 Мбайт. Выравнивание устанавливалось по размеру блока. В случае тестирования диска с созданным логическим разделом размер раздела составлял всю доступную область диска, а если диск тестировался без созданного логического раздела, то в настройках утилиты IOmeter указывалось, что в тестах необходимо использовать всё пространство диска (это настройка по умолчанию).
Понятно, что результаты операций последовательного и случайного чтений не могут различаться для нового и уже использовавшегося дисков. Поэтому для операций чтения тест проводился только для уже применявшегося диска (с таким же успехом этот тест можно было осуществлять на базе нового диска).
Для операций последовательной записи мы проводили тест как для нового диска, так и для ранее использовавшегося. Отметим, что для создания ранее применявшегося диска мы предварительно использовали операцию случайной записи блоками по 32 Кбайт в течение 18 часов.
В перечисленных сценариях нагрузки время теста с каждым запросом на передачу блока данных составляло 5 мин. Также отметим, что во всех перечисленных тестах мы задавали в настройках IOmeter глубину очереди задачи (# of Outstanding I/Os) равной 4, что типично для пользовательских приложений.
Второй и третий этапы тестирования были посвящены операциям случайной записи. Дело в том, что, в отличие от всех остальных тестов, скорость случайной записи со временем меняется. Поэтому на втором этапе тестирования мы исследовали изменение скорости выполнения случайной записи от времени. Данный тест выполнялся следующим образом. С каждым размером блока запроса на передачу данных тест запускался на протяжении четырех часов (240 мин) с фиксацией результатов через каждую минуту (утилита IOmeter позволяет создать подобный сценарий загрузки). После этого для каждого размера блока строился график зависимости скорости передачи данных (Мбайт/с) от времени.
В тесте использовались следующие размеры запросов на передачу блоков данных: 2, 4, 8, 16, 32, 64 и 128 Кбайт. Выравнивание устанавливалось по размеру блока.
Отметим, что после окончания отдельного теста с каждым размером блока запроса на передачу данных диск приводился в исходное состояние с помощью утилиты Paragon Disk Wiper 2010. Фактически тест начинался с новым диском, а заканчивался с уже использованным.
Измерение скорости случайной записи от времени проводилось как с диском, на котором создан логический раздел, так и с диском без логического раздела. В случае тестирования диска с созданным логическим разделом размер раздела составлял всю доступную область диска, а если диск тестировался без созданного логического раздела, то в настройках утилиты IOmeter указывалось, что в тестах нужно использовать всё пространство диска.
Теоретически скорость выполнения операций случайной записи должна зависеть от количества свободных страниц памяти и от размера резервной области, поскольку пустые страницы памяти, а также страницы памяти резервной области применяются в процедуре перемещения данных, и чем их больше, тем выше скорость выполнения операций случайной записи. Поэтому на третьем этапе тестирования мы измеряли зависимость скорости выполнения операций случайной записи от размера резервной области.
Данный тест проводился только с запросами на передачу данных блоками по 4 Кбайт и с диском, на котором создан логический раздел. Напомним, что любой диск имеет резервную область, недоступную для использования. Размер этой области рассчитывается как разница заявленного размера диска в двоичных гигабайтах (1 Гбайт = 1 073 741 824) и его размера в десятичных гигабайтах (1 Гбайт = 1 000 000 000). К примеру, для диска объемом 160 Гбайт размер резервной области составляет примерно 11 Гбайт (двоичных), а для использования доступно 149 Гбайт (двоичных). Собственно, именно поэтому операционная система определяет размер диска не как 160, а как 149 Гбайт, поскольку операционная система всегда считает размер диска в двоичных гигабайтах.
Размер резервной области можно увеличить, если создать на диске логический раздел с меньшим размером, чем размер диска. В этом случае всё неиспользуемое пространство автоматически будет задействоваться как резервная область.
В тесте измерения зависимости скорости выполнения операций случайной записи от размера резервной области мы задавали размер логического раздела в процентах от максимального: 100% (149 Гбайт), 75% (111,8 Гбайт), 50% (74,5 Гбайт) и 25% (37,3 Гбайт). Все остальные настройки теста соответствовали настройкам для случайной записи с различными размерами блоков.
Результаты тестирования и их анализ
Последовательное чтение
Результаты тестирования в режиме последовательного чтения показаны на рис. 7. Как видно, максимальная скорость последовательного чтения составляет 260 Мбайт/с для диска с логическим разделом и 270 Мбайт/с для диска без логического раздела. Отметим, что это даже немного выше, чем производитель заявляет в спецификации. При этом максимальное значение скорости чтения достигается при размере блока в 64 Кбайт.
Рис. 7. Зависимость скорости передачи данных при последовательном чтении диска
Случайное чтение
Результаты тестирования в режиме случайного чтения показаны на рис. 8. Как видите, для диска без логического раздела (чистая производительность) скорость случайного чтения практически не отличается от скорости последовательного чтения. Собственно, это вполне предсказуемый вариант, поскольку в NAND флэшпамяти просто нет причин, которые могли бы привести к разнице в скорости последовательного и выборочного чтения. А вот для диска с логическим разделом между скоростью последовательного и случайного чтения наблюдается разница. Мы не можем объяснить, чем именно это обусловлено, а потому лишь констатируем обнаруженный факт.
Рис. 8. Зависимость скорости передачи данных при случайном чтении диска
Последовательная запись
Результаты тестирования для последовательного чтения показаны на рис. 9 и 10. Как и предполагалось, скорость последовательной записи зависит от состояния диска. Для нового (ранее не использовавшегося) диска максимальная скорость последовательной записи превышает 100 Мбайт/с, причем никакой разницы в скорости для диска с логическим разделом и без него не наблюдается.
Рис. 9. Зависимость скорости передачи данных при последовательной записи
для нового диска
Рис. 10. Зависимость скорости передачи данных при последовательной записи
для ранее использовавшегося диска
А вот в случае ранее применявшегося диска ситуация значительно сложнее и зависит от того, как именно диск использовался до теста. Если на диске предварительно в течение длительного времени осуществлялись операции последовательной записи, то при последующей последовательной записи процедура Garbage Collection не должна повлиять на уменьшение скорости и результат не должен сильно отличаться от результата с новым диском. Если (как в нашем случае) на диске предварительно в течение длительного времени осуществлялись операции случайной записи, то при последующей последовательной записи доминирующим фактором, отражающимся на скорости, станет процедура Garbage Collection, то есть процедура очистки блоков со страницами, помеченными к удалению. В то же время если процедуру последовательной записи проводить долго, то в конечном счете количество разрозненных страниц памяти, помеченных к удалению, станет небольшим, а показатель усиления записи приблизится к единице и скорость последовательной записи возрастет и станет практически такой же, как и в случае, если на диске предварительно в течение длительного времени осуществлялись операции последовательной записи.
Случайная запись
Пожалуй, анализ результатов именно случайной записи диска вызывает наибольший интерес, поскольку со временем меняется скорость выполнения только этих операций. Как правило, в качестве главной причины, приводящей к падению скорости осуществления операций случайной записи, указывается уменьшение со временем количества свободных страниц памяти и, как следствие, возрастание показателя усиления записи. Напомним вкратце, о чем идет речь. По мере уменьшения количества свободных страниц контроллер диска начинает задействовать страницы, помеченные к удалению, которые неизбежно появляются при случайной записи. Перед тем как записать на такую страницу памяти новые данные, ее необходимо очистить, то есть стереть устаревшие данные. Однако очистить лишь одну страницу NAND флэшпамяти нельзя (собственно, это и есть ахиллесова пята NAND флэшпамяти). Стирать данные можно только блоками, состоящими из большого числа страниц. Но в блоке могут быть страницы, как помеченные к удалению, так и содержащие нужные данные. Поэтому при записи страниц, помеченных к удалению, используется довольно сложная процедура. Сначала контроллер диска по особому алгоритму выбирает блок, содержащий как можно больше страниц памяти, помеченных к удалению. Потом из этого блока считываются все страницы, содержащие нужные данные, а затем эти страницы переписываются в свободный блок или блок из резервной области. В этот же блок страницами дописываются и те данные, которые нужно было записать изначально. Ну а блок, который содержал страницы, помеченные к удалению, целиком удаляется и помечается как свободный или резервный. В результате такой процедуры, во-первых, приходится выполнять еще и считывание, а во-вторых, записывать данных больше, чем требуется (размер записываемых данных превышает размер запроса). Собственно, именно поэтому и происходит резкое снижение производительности.
Однако давайте попробуем проанализировать изменение скорости передачи данных при случайной записи для диска Intel X25-M (Gen 2). Результаты тестирования для случайной записи показаны на рис. 11-13.
Рис. 11. Зависимость скорости передачи данных от времени при случайной записи
для диска без логического раздела
Рис. 12. Зависимость скорости передачи данных от времени при случайной записи
для диска с логическим разделом
Рис. 13. Зависимость скорости выполнения операций случайной записи
от размера логического сектора
В случае тестирования диска без логического раздела (см. рис. 11) в первые несколько минут теста (зависит от размера блока) наблюдается очень резкое падение производительности. К примеру, при размере блока 4 Кбайт скорость передачи данных за первые три минуты теста уменьшается с 90 до 10 Мбайт/с, а при размере 16 Кбайт — со 100 до 30 Мбайт/с. Давайте посмотрим, может ли такое падение производительности быть вызвано уменьшением количества свободных страниц памяти. Как показывают расчеты, при размере блока 4 Кбайт с учетом изменения скорости передачи данных за первые три минуты всего на диск записывается не более 10 Гбайт данных, то есть заполняется не более 6% пространства диска. Понятно, что ни о каком уменьшении количества свободных страниц памяти речи пока не идет, а значит, такое падение производительности не может быть следствием уменьшения числа свободных страниц памяти.
В статье «Особенности работы современных SSD-дисков» мы указали, что при случайной записи, помимо уменьшения числа свободных страниц памяти, есть еще одна причина, приводящая к падению производительности. Речь идет об оптимизации таблицы размещения, которая включает записи, сопоставляющие логические адреса (LBA) физическим адресам (PBA). Важно, что эта таблица не содержит отдельных записей для каждого 512-байтного сектора, а оперирует блоками переменной длины. Чем больше блоки, тем меньшее количество записей в таблице требуется. Строго говоря, это не просто таблица, а более сложная структура. При коротких блоках данных первых нескольких минут вполне достаточно, чтобы таблица размещения выросла до размеров оперативной памяти контроллера SSD, в которой, собственно, она и расположена. И с этого момента уже требуется постоянно оптимизировать таблицу, что сказывается на производительности. Процесс оптимизации, по сути, состоит из объединения разрозненных маленьких фрагментов в один непрерывный сегмент. Одно такое объединение позволяет заменить несколько тысяч записей в таблице на одну запись. Объединение делается путем считывания разрозненных фрагментов и записи их последовательно в новый сегмент. Физические блоки, где эти фрагменты ранее размещались, помечаются как неиспользуемые.
Также по графикам видно, что чем больше размер блока, тем дольше происходит падение производительности. В общемто это понятно, поскольку с ростом размера блока уменьшается и скорость роста размера таблицы размещения.
Вплоть до размера блока 32 Кбайт вслед за резким падением скорости передачи данных при случайной записи происходит ее рост, а затем наступает период стабилизации. К примеру, для размера блока 4 Кбайт скорость случайной записи перестает изменяться примерно через 40 мин, а для размера блока 16 Кбайт — примерно через 200 мин. Как показывают расчеты, при размере блока 4 Кбайт за 40 мин невозможно заполнить всё пространство диска данными. Более того, для этого недостаточно даже 4 ч. Впрочем, мы специально проводили этот тест и на протяжении 8 ч, однако картина не меняется: при размере блока 4 Кбайт скорость передачи данных стабилизируется на уровне примерно 2 Мбайт/с.
Объяснение в данном случае может быть следующее. После 40 мин тестирования количество свободных страниц памяти подходит к той границе, когда начинает активизироваться функция Garbage Collection, в результате чего количество свободных блоков остается практически неизменным на протяжении всего дальнейшего теста. Соответственно показатель усиления записи поддерживается неизменным, а скорость случайной записи не изменяется и зависит лишь от размера блока.
Интересно отметить, что при размере блока 32, 64, 128 Кбайт и выше (мы проверяли и при размере блока 256 и 512 Кбайт) зависимость скорости передачи данных от времени абсолютно одинакова. По всей видимости, это объясняется тем, что, когда размер блока в несколько раз превышает размер страницы физической памяти, эффективность процедуры Garbage Collection, а соответственно и показатель Write Amplification уже перестают зависеть от размера блока.
Если сравнивать результаты тестирования при случайной записи для диска с логическим разделом (рис. 12) и без, то видно, что в первом случае результаты несколько хуже. Проблема опять-таки заключается в таблице размещения, которая принимает более сложную форму, и соответственно ее оптимизация становится еще сложнее.
Собственно, основная разница в результатах заключается в том, что в случае диска с логическим разделом падение скорости передачи данных происходит более стремительно.
К примеру, для размера блока 4 Кбайт в случае диска без логического раздела через 1 мин теста скорость передачи данных составляет 65 Мбайт/с, а через 4 мин уменьшается до 8 Мбайт/с. После этого наблюдается постепенное увеличение скорости передачи данных до 15 Мбайт/с и последующее уменьшение до 2 Мбайт/с. Причем уровня в 2 Мбайт/с скорость достигает через 40 мин после начала теста.
В случае диска с логическим разделом при том же размере блока (4 Кбайт) через 1 мин теста скорость передачи данных составляет 61 Мбайт/с, а через 4 мин уменьшается до 2,6 Мбайт/с и уже практически не изменяется на протяжении всего теста.
Не менее интересными являются и результаты тестирования скорости случайной записи при различных размерах резервной области, которые наглядно демонстрируют, каким образом можно повысить производительность SSD-диска, уменьшив размер логического сектора.
Редакция выражает признательность компании Intel и персонально Артему Даниелову за консультативную помощь при написании данной статьи.
 |
|
