Тест Adata XPG SX8200 Pro 512 ГБ серверными и профессиональными нагрузками

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

Adata XPG SX8200 Pro позиционируется как экономная альтернатива Samsung EVO 970 Pro или WD Black SN750, и экономия идёт, прежде всего, на контроллере. Если Pro-линейки Samsung и Western Digital используют контроллер собственной разработки, то Adata устанавливает SM2262EN разработки компании Silicon Motion. В качестве буфера Adata использует память DDR3-1600, набранную двумя 256-мегабайтными чипами, в то время как другие производители реализуют для этой цели DDR4. Здесь следует сказать, что при прочих равных, DDR3 обладает более низкой задержкой, и при правильном подходе такой SSD может быть более «отзывчивым» на операциях с закэшированными данными. Основной объём накопителя набран 4-мя чипами 64-слойной TLC 3D Nand производства Micron. Монтаж микросхем осуществляется с двух сторон, а ещё в комплекте поставляется тоненькая пластинка теплораспределителя для охлаждения контроллера, который итак имеет встроенную пластинку для отвода тепла.

Я рекомендую клеить комплектный радиатор на обратную сторону накопителя, и вот почему: если ваша рабочая станция собрана на базе десктопной материнской платы, у вас скорее всего будет более серьёзный радиатор для SSD, а вы хотите установить его в сервер, то там интенсивный воздушный поток справится с отводом тепла и без радиатора. В случае же если радиатор со временем отклеится, он не упадёт на GPU или на какой-нибудь контроллер, а ляжет на поверхность платы, которая под слотом для NVME M.2, как правило, совсем голая.

Совместимость с ESXi 6.7 U2+ и ESXi 7

Если вы подбираете SSD для кеширования в гипервизоре ESXi, то знайте что начиная с апдейта 6.7 U2, компания VMware убрала поддержку «десктопных» NVMe накопителей. При этом, вышеназванные Samsung 970 Pro, WD Black SN750 определяются без проблем, а для SSD с контроллерами Silicon Motion надо немного поколдовать.

Вам потребуется файл nvme.v00 из инсталляции VMWare ESXi 6.5 (можете скачать отсюда), который можно найти в составе старого дистрибутива. Его надо загрузить в папку /bootbank, зайдя в гипервизор по SSH, а затем выполнить перезагрузку хоста. Что интересно, та же замена работает и для новейшей ESXi 7, с той лишь разницей, что файл нужно переименовать в nvme_pci.v00.

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

Как и почему мы будем тестировать?

Для рабочих станций ситуация несколько иная: как правило, при разработке проектов, работе с графикой или с видео, компилировании софта, равно как и при запуске виртуалок, основная активность приходится на небольшую область накопителя, которая легко умещается в кэш устройства. Поэтому подбирая SSD для работы с цифровыми данными, мы никогда не смотрим на CrystalDisk Benchmark, - тест, под который каждый производитель подгоняет данные. Для нас важнее задержки и стабильность доступа, которые возникают при использовании паттернов доступа, снятых с реальных задач. Именно паттерны способны сбрасывать производительность с мифических 3 Гб/с до реальных 80 Мб/с, - скорости, на которой и будет работать ваш софт. И поскольку крайне редко приходится разово записывать десятки или сотни гигабайт, нас интересует средняя задержка дискового доступа, а точнее её стабильность во времени, и это полностью зависит от контроллера накопителя. Используя тестовый пакет IOmeter, мы заполним диск на 80% случайными данными, и несколько раз перезапишем их, чтобы уйти от состояния "свежего SSD".

Все наши тесты мы будем проводить на временном отрезках 600 и 800 секунд - этого достаточно, чтобы увидеть работу контроллера и кэша.

Материнская плата - ASRock EPYCD8-2T
Процессор - AMD EPYC 7531p
Память - 64 Гб
VMware ESXi 6.7 U2

Windows Server 2016
NTFS, размер сектора 512 б

IOmeter, Pseudo Random

Синтетика

Синтетические тесты мы будем проводить в 1 поток, на накопителе, который был подготовлен 2-кратной перезаписью своего объёма случайными данными. Это наиболее репрезентативные результаты, которые покажут производительность SSD в условиях установки в рабочую станцию, в работе с одним приложеием. Перед каждым запуском теста, SSD находился в режиме простоя в течении 15 минут, чтобы инициировать исполнение механизмов GC.

Начнём наше тестирование с исследования скорости случайного доступа:

Случайное чтение практически ровное, без сюрпризов. Среднее время доступа составляет 0.15 мс, что считается нормой для накопителя подобного класса. На случайной записи мы видим, как со временем буквально как по истечению 10 минут записи, очевидно израсходуется весь SLC-кэш, а задержка возрастает в 2 раза. При 70% чтении, накопитель успевает справиться с распределением новых данных, и переполнения кэша не происходит. Переходим к операциям с последовательным доступом блоками по 1 мегабайту.

Типичное время чтения приложения составляет 880 Мб/с, что в общем-то, находится на уровне других SSD объёмом 480-512 Гб. Линейная запись в кэш доходит до 1.4 Гб/с, но со временем скорость падает аж до 150-170 Мб/с. Практически точно так же ведёт себя SATA SSD Transcend 230S, тоже созданный на контроллере Silicon Motion, правда версси SM2258. В нашем тестлабе мы используем данный SSD для хранения виртуальных машин, и опыт показал, что в принципе, он при записи выдаёт свои честные 147 Мб/с, и именно на эту скорость надо рассчитывать, а не на показания CrystalDisk Benchmark, который рисует в разы большую производительность.

Тем не менее, если не брать ситуации обработки Big Data или миграции виртуальных машин, то SSD - он и есть SSD, и низкой линейной скорости можно никогда и не увидеть. Посмотрим на время доступа в серверных нагрузках.

Серверные нагрузки

Для тестирования серверных нагрузок мы используем те же паттерны, что и для тестов корпоративных СХД класса SAN и NAS. Прочитать о них вы можете в наших обзорах СХД Synology и Huawei. Эти паттерны разработаны специалистами компании Pure Storage на основе трейсинга операций ввода/вывода реальных приложений. Здесь каждый тест мы запускаем в 1-поточном и 8-поточном режимах. Большее число потоков устанавливать не имеет смысла, поскольку там уже SSD перешагивает значение 10 мс, что по современным требованиям рынка я считаю предельным значением.

Во всех наших тестах серверных задач, первые 5 минут время доступа было наиболее высоким. Возможно, это период "прогрева" внутреннего кэша, после чего время выравнивается и снижается почти в 3 раза. Для 8 потоков ситуация принципиально иная: кэш переполняется, накопитель не успевает оптимизировать свежие записанные данные, и время доступа постоянно растёт.

Чем больше записи производит рабочая задача, тем сильнее растёт задержка со временем на многопоточных загрузках.

И опять же, в транзакционных нагрузках, таких как базы данных, SSD показывает себя великолепно.

Так что если вы занимаетесь разработкой и тестированием СУБД, с учётом того, что одна база данных пишет на диск в 1 поток, вы получите от Adata XPG SX8200 Pro очень низкое время доступа - менее 1 мс. Да и в принципе, 6-8 баз данных этот накопитель так же выдержит без особых проблем. Но устанавливать его в СХД в качестве кэширующего или основного, я бы остерёгся.

Офисные нагрузки

Офисные нагрузки мы так же моделируем с помощью паттернов, но уже снятых своими силами. Все тесты мы запускаем в 1 поток, и поскольку в реальных офисных и мультимедийных задачах производительность никогда не упирается в дисковую подсистему, а всегда зависит от CPU и GPU, мы используем в качестве метрики пропускную способность в мегабайтах в секунду. Каждый тест здесь у нас длится 600 секунд.

Лучше всего Adata XPG SX8200 Pro справляется с тестами, имеющими преимущественное чтение большими блоками: проверка архивов бэкапа, или импорт 4K видео в редактор. Любая запись, замиксованная с чтением, обваливает скорость до 60-70 Мб/с.

Офисные нагрузки в ограниченной области (ближе к реальным данным)

А теперь давайте перейдём к тому, с чего начали: у вас что, постоянно идёт выборка со всего объёма диска при работе в офисных задачах? Вы открываете/закрываете проекты, подтягиваете данные, делаете импорт и экспорт, запускаете софт, и всё это происходит лишь на малой части вашего накопителя. Даже базы данных, в большинстве своём, интенсивно работают лишь с частью данных, кэшируя наиболее важные из них, чтобы разгрузить дисковую подсистему. Давайте ограничим область работы SSD двадцатью гигабайтами, увеличим время теста до 800 секунд и посмотрим, вытянет ли кэш накопителя полученные результаты в плюс?

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

А вот в офисных задачах наоборот, кэширование показывает огромный прирост скорости, выводя накопитель на показатели, достойные NVME диска. Вероятно, механизм кэширования настроен на операции с последовательными блоками, по крайней мере, в СХД такая дифференцация, что именно кэшировать, используется уже довольно долго.