Производительность SSD в приложениях для рабочих станций – THG.RU

Производительность SSD в приложениях для рабочих станций: 3D-рендеринг, CAD, программирование и виртуализация

Несмотря на то, что тесты производительности дисковой подсистемы часто показывают, что SSD многократно превосходит по “общей” пропускной способности жёсткие диски, при переходе к реальным приложениям картина может быть иной. Многие приложения просто не могут извлечь преимущество при переходе на SSD тем же путём, как его выявляют синтетические бенчмарки, которые устроены таким образом, чтобы выжать максимум, на который способен каждый накопитель.

Говоря в общем, SSD достигают лучших результатов, когда речь идёт о работе на высокой глубине очереди. Если вы просмотрите наш последний обзор линейки накопителей Intel SSD 520, чтобы получить более полное представление о нашей методике тестирования SSD в реальных приложениях, тем не менее, вы обнаружите, что приложения, часто используемые на настольных ПК, попросту не предполагают работу на высокой глубине очереди, при которой разница между SSD и накопителями на магнитных пластинах будет наиболее значительной. Таким образом возникает вопрос: действительно ли задачи, ради которых вы можете перейти на SSD, могут реализовать весь потенциал твердотельного накопителя, реализовать его частично или вовсе не задействуют его? Иногда ответ на этот вопрос удивляет. В качестве примера можно привести сканирование диска антивирусной программой. Можно предположить, что большой объём файлов приведёт к увеличению глубины очереди. Но на самом деле дело обстоит совсем не так, как показал наш анализ профиля загрузки диска в офисных приложениях.

За последние несколько месяцев, по мере того, как мы оттачивали и оптимизировали наш пакет тестовых программ, мы также предложили несколько отдельных обзоров, касающихся работы дисковой подсистемы в специфических областях: офисных приложениях, работе с видео. Кроме того, мы в значительной степени акцентировали внимание на играх, где производительность дисковой подсистемы имеет весьма важную роль. Тестовая система, на которой мы тестируем новые видеокарты, оснащена именно твердотельным диском, и это не случайно. Ещё две статьи были посвящены вопросу, стоит ли вообще переходить на SSD, исходя из специфики ваших задач: “Стоит ли переходить с жёсткого диска на SSD?” и “SSD: лучший апгрейд для старого ПК?”.

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

Рабочая станция на базе процессора Xeon E5-2600

Редактирование проекта трёхмерной модели в LightWave 3D

Недавно Intel представила новую линейку процессоров Xeon E5, обзор и тест которых вы сможете увидеть в ближайшее время на страницах THG. Приложения наподобие Cinebench 11.5 (на основе движка рендеринга Cinema 4D компании Maxon), 3d Max и Vue 8 делают очевидным, что вычислительные ресурсы процессоры, пожалуй, самое главное, что требуется от рабочей станции, использующейся для 3D-рендеринга. В результате, можно легко возложить всю ответственность за результат на CPU и графическую карту, придавая меньшее значение производительности дисковой подсистемы.

Редактирование проекта 3D-модели не является слишком интенсивной нагрузкой с точки зрения работы накопителя, так как работа над проектом предполагает большое количество пользовательских манипуляций. В итоге 89% всех операций осуществляется на минимальной глубине очереди. Большинство операций обращения к данным являются случайными, и основная часть операций осуществляется с блоками по 4 кбайт. Это объясняется тем, что любой проект включает множество мелких модульных компонентов.

Статистика операций ввода/вывода:

• 89% всех операций осуществляется на глубине очереди, равной единице.
• 88% объёма всех переданных данных относится к случайным операциям.
• 60% всех операций работают с блоками данных по 4 кбайт.
• 16% всех операций работают с блоками данных меньше 512 байт.

LightWave 3D: Рендеринг

Мы использовали пример LightWave, называющийся “Тест рендеринга Radiosity”. Согласно описанию разработчика, “данная сцена разработана таким образом, чтобы загрузить движок непрямого освещения (GI) путем включения в сцену очень мелких деталей на большом пространстве, почти полностью имеющего непрямое освещение, несмотря на то, что рендеринг по-прежнему осуществляется достаточно быстро”.

Данную сцену нельзя назвать излишне тяжёлой с точки зрения нагрузки на ПК: процесс рендеринга на нашей тестовой системе с процессором Core i5-2500K занимает всего 13 минут и 30 секунд. Мы снова видим, что большинство операций во время рендеринга осуществляется на минимальной глубине очереди. Кроме того, поскольку тестовая сцена содержит множество мелких деталей, большая часть переданных данных относится к случайным операциям, и значительная часть операций производится с блоками по 4 кбайт.

Статистика операций ввода/вывода:

• 78% всех операций осуществляется на глубине очереди, равной единице.
• 65% объёма всех переданных данных относится к случайным операциям.
• 47% всех операций работают с блоками данных по 4 кбайт.
• 11% всех операций работают с блоками данных меньше 512 байт.

AutoCAD: Редактирование проекта

Чтобы обеспечить хороший противовес LightWave 3D, мы решили рассмотреть профиль загрузки накопителя в приложении, которое используется, в первую очередь, для построения двухмерных моделей. Но, по сравнению с LightWave 3D, профиль AutoCAD выглядит очень похоже. Основная часть всех операций обращения к диску по-прежнему производится на глубине очереди, равной единице, и большинство переданных данных относится к случайным операциям. Интересно, что редактирование проекта в AutoCAD предполагает множество операций с очень маленькими блоками данных. Согласно нашим измерениям, 61% операций работают с блоками, имеющими размер всего 512 байт. Даже с учётом того, что наш тестовый чертёж состоит из множества элементов, описанная нами тенденция, судя по всему, не зависит от компоновки чертежа.

Статистика операций ввода/вывода:

• 92% всех операций осуществляется на глубине очереди, равной единице.
• 81% объёма всех переданных данных относится к случайным операциям.
• 61% всех операций работают с блоками данных по 512 байт.
• 20% всех операций работают с блоками данных по 8 кбайт.

Программирование в Visual Studio: Открытие проекта

Программирование – общий компонент нагрузки для любой рабочей станции. Тем не менее, простое действие открытия файла, содержащего программный код, зачастую упускается из вида. В нашем тесте мы открывали единичный .cpp-файл из проекта Mozilla с открытым исходным кодом. Подавляющее большинство операций осуществляются на глубине очереди, равной единице, причём основная часть переданных данных относится к случайным операциям. Согласно нашим измерениям, значительная часть операций производится с блоками объёмом 4 кбайт.

Статистика операций ввода/вывода:

• 82% всех операций осуществляется на глубине очереди, равной единице.
• 81% объёма всех переданных данных относится к случайным операциям.
• 52% всех операций работают с блоками данных по 4 кбайт.
• 16% всех операций работают с блоками данных по 32 кбайт.

Программирование в Visual Studio: Компиляция кода

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

Существует множество различных примеров, которые мы могли бы использовать в нашем тесте как профиль нагрузки при компиляции, но мы стремились найти что-то типичное и знакомое. По этой причине мы решили загрузить исходный код для Firefox и использовали компилятор Visual Studio 2010. Организация Mozilla Foundation, в основном, подготавливает исходный код, что облегчает процесс компиляции.

Согласно нашим замерам, большая часть операций осуществляется на глубине очереди свыше единицы. Поскольку компилятор обращается к массиву файлов в некой последовательности, операции организованы в очередь заданий. Интересно также, что наш тест выявил некий баланс между случайными операциями с блоками по 4 кбайт и последовательной передачей данных блоками по 128 кбайт. Это было неожиданно для нас, так как основная часть файлов в проекте имеет размер менее 10 кбайт.

Таким образом, компиляция кода – не тот сценарий, где SSD имеют явное преимущество. Как мы знаем, чтение и запись случайных данных – область, где жёсткие диски наиболее ощутимо проигрывают SSD. Рассмотрим статистику операций и выявим разницу по скорости при компиляции кода между одним твердотельным накопителем Vertex 3 и парой жёстких дисков Caviar Green объёмом 1 тбайт, работающими в массиве RAID 0. Система на основе SSD выполняет компиляцию кода за 49 минут, система на основе жёстких дисков – за 55 минут.

Статистика операций ввода/вывода:

• 43% всех операций осуществляется на глубине очереди, равной единице.
• 30% всех операций осуществляется на глубине очереди от 2 до 4.
• 41% всех переданных данных относится к последовательным операциям.
• 29% всех операций работают с блоками данных по 4 кбайт.
• 21% всех операций работают с блоками данных по 128 кбайт.

MATLAB: Загрузка данных

Анализ данных – ещё один из вариантов использования рабочей станции, который часто встречается в инженерных или научных областях. Подобный тип нагрузки намного сложнее, чем работа в Exel, с которой многие из нас сталкиваются ежедневно.

Следовательно, мы должны рассмотреть более серьёзные типы нагрузки по анализу данных. В нашем тесте мы использовали CSV-файл объёмом 8 Mбайт от бюро переписи США, который содержит статистику по более 80 000 городов и посёлков, и загрузили этот объём данных в MATLAB. В целом, как нам представляется, импорт данных – довольно лёгкий тип нагрузки, поскольку подавляющее большинство операций производится на глубине очереди, равной единице, и основная часть переданных данных относится к случайным операциям. Наконец, две трети всех операций осуществляются с блоками данных по 4 кбайт.

Статистика операций ввода/вывода:

• 75% всех операций осуществляется на глубине очереди, равной единице.
• 82% всех переданных данных относится к случайным операциям.
• 66% всех операций работают с блоками данных по 4 кбайт.
• 10% всех операций работают с блоками данных по 8 кбайт.
• 9% всех операций работают с блоками данных меньше 512 кбайт.

MATLAB: Анализ данных

Анализ значительного объёма данных с точки зрения производительности системы предъявляет требования, напоминающие нагрузку по импорту данных. Мы вновь видим, что большинство операций осуществляются на минимальной глубине очереди, и большая часть переданных данных относится к случайным операциям. Около половины всех операций производятся с блоками объёмом 4 кбайт.

Статистика операций ввода/вывода:

• 85% всех операций осуществляется на глубине очереди, равной единице.
• 83% всех переданных данных относится к случайным операциям.
• 49% всех операций работают с блоками данных по 4 кбайт.
• 21% всех операций работают с блоками данных по 32 кбайт.

VMware: инсталляция операционной системы

Многие пользователи рабочих станций используют преимущества виртуализации, запуская несколько операционных систем на одной и той же системе. В данном тесте мы установили 64-битную версию Windows 7 на виртуальную машину VMware Workstation с установками по умолчанию (файл виртуальной машины VM объёмом 20 Гбайт). Профиль производительности отражает данную весьма тяжёлую нагрузку. Около 50% всех операций производятся на минимальной глубине очереди, ещё 40% – на глубине очереди от двух до четырёх. Любопытно, что лишь 59% объёма всех переданных данных относится к последовательным операциям. Наконец, как мы и ожидали, лишь около четверти всех операций работают с блоками по 4 кбайт, в остальных случаях блоки данных имеют больший объём.

Статистика операций ввода/вывода:

• 49% всех операций осуществляется на глубине очереди, равной единице.
• 40% всех операций осуществляется на глубине очереди от 2 до 4.
• 59% всех переданных данных относится к последовательным операциям.
• 24% всех операций работают с блоками данных по 4 кбайт.
• 21% всех операций работают с блоками данных по 64 кбайт.

VMware: Загрузка

SSD-накопители, как известно, помогают ускорить загрузку систему. Глубина очереди при запуске Windows может с лёгкостью достичь четырёх операций, так как операционная система последовательно обращается сразу к нескольким файлам одновременно. Это именно то, что мы видим при запуске Windows 7 из-под виртуальной машины VMware. Менее половины всех операций осуществляется на глубине очереди, равной единице. Подавляющее большинство передаваемых данных являются последовательными, причём около двух третей операций работают с блоками объёмом 64 кбайт.

Загрузка Windows 7 до рабочего стола из виртуальной машины VMware занимает всего 30 с. Для сравнения, в случае использования двух накопителей WD Caviar Green в массиве RAID 0 данный процесс занимает около 50 с.

Статистика операций ввода/вывода:

• 38% всех операций осуществляется на глубине очереди, равной единице.
• 55% всех операций осуществляется на глубине очереди от 2 до 5.
• 75% всех переданных данных относится к последовательным операциям.
• 18% всех операций работают с блоками данных по 4 кбайт.
• 64% всех операций работают с блоками данных по 64 кбайт.

VMware: веб-сёрфинг

Мы также хотели проверить влияние работы виртуальной машины на более типичные пользовательские задачи. Для этого мы измерили активность диска во время веб-сёрфинга в Firefox из-под виртуальной машины. Полученные результаты интересно сравнить с данными из нашего “Теста производительности SSD в офисных приложениях”, где мы также изменяли профиль нагрузки на диск при работе в сети.

Влияние виртуализации на дисковую подсистему в данном случае незначительно. Как вы можете видеть из результатов теста, основная часть операций производится на глубине очереди, равной единице, и подавляющее большинство объёма передаваемых данных относится к случайным операциям. Размер блоков данных – основное отличие веб-сёрфинга из виртуальной машины VMware Workstation по сравнению с “чистой” системой Windows 7. В данном случае, мы видим большее количество операций блоками до 4 кбайт.

Статистика операций ввода/вывода:

• 77% всех операций осуществляется на глубине очереди, равной единице.
• 93% всех переданных данных относится к случайным операциям.
• 31% всех операций работают с блоками данных по 4 кбайт.

Есть ли смысл в переходе на SSD с учётом специфики использования рабочих станций?

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

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

Сравнение HDD (2 накопителя в режиме RAID 0) и SSD (Vertex 3) в приложениях для рабочих станций

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

Очевидно, что когда мы имеем дело с типами нагрузки, специфичными для рабочих станций, SSD пойдёт на пользу делу (примерно так же, как это происходит и в других видах работы на ПК, которые мы рассматривали в предшествующих обзорах). Но лишь то, что вы используете SSD для работы, ещё не означает, что у вас имеется дополнительный бюджет, чтобы потратить $1,5-2 за гигабайт ёмкости.

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

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