Что влияет на скорость записи и чтения SSD-накопителей?

После цикла экспериментов по бенчмаркам копирования данных стоит поинтересоваться, какие факторы влияют на скорость записи и чтения ин­формации на твердотельных носителях? В прошлый раз мы иссле­до­ва­ли результаты, полученные с помощью двух разных метрик, разрабо­тан­ных раз­ными авторами: в тестовых испытаниях были задействованы утилиты AS SSD и NIOBench. Продолжим наши исследования с ука­зан­ным ин­стру­мен­та­рием не меняя тестовую платформу. Напомним, что в этом нам поможет 120 ГБ SSD-накопитель 3510-й серии от Intel на плат­форме ASUS P10S-i, ос­на­щенной процессором Xeon E3-1230 v5.

Проблемы бенчмаркинга

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

Как протестировать накопитель? Есть два подхода, каждый из которых имеет свои преимущества и недостатки.

• Первый путь состоит в явном отказе от механизма кэширования, используя опции, задаваемые во входных параметрах функций ОС API. В системах Microsoft — это флаг FILE_FLAG_NO_BUFFERING, от­ме­ня­ющий бу­фе­ризацию и кэширование чтения и флаг FILE_FLAG_WRITE_THROUGH , запрещающий отложенную запись. От­ка­зав­шись от буферизации, приложение получает «аппаратную» производительность устройства, возложив на себя заботу о ряде низкоуровневых факторов, в частности — выравнивании размера пе­ре­да­ва­е­мых блоков в со­от­ветствии с размером сектора. Отметим очевидную «синтетичность» такого сценария, поскольку в ре­аль­ной жизни буферизация по умолчанию включена.
• Второй путь неявно устраняет кэширование, оперируя большими блоками данных, что приводит к пере­пол­не­нию кэша. Файлы или фрагменты, кэшированные в оперативной памяти, оказываются вытесненными к моменту их использования и ОС вынуждена читать информацию с диска. Это сказывается на общей произ­во­ди­тельности подсистемы хранения данных, так как на выполнение кэширования, результаты которого не­вос­тре­бо­ва­ны, потрачен ценный системный ресурс — время. Такой механизм ближе к ситуации, имеющей место в реальных приложениях и не использует системно-зависимых опций ОС API.

Мы пойдем другим вторым путем!

Нисколько не преуменьшая программное влияние на экосистему «платформа – ОС – накопитель», возьмем пока только второй из задекларированных способов «угнетения» спекуляционных алгоритмов. Это необходимо вы­пол­нить для того, чтобы понять, насколько возможно приблизиться к естественным метрикам производительности с помощью синтетических бенчмарок. Свои выводы будем поверять результатами тестирования SSD-накопителя, полученными с помощью AS SSD. Как и в прошлый раз, выберем паттерн размером в 1 ГБ, принимая во внимание, что иной информации об этом «черном ящике» у нас нет.

Рис 1. Одна из итераций тестирования накопителя Intel SSDSC2BB120G6 утилитой AS SSD

Как и ранее, стабильность результатов AS SSD будет обеспечивать троекратное повторение тестов; их сведем в таблицу, где каждая ячейка — скорость копирования в МБ/сек.

Таблица 1а

Таблица 1б

Сравнивая полученные данные с результатами утилиты NIOBench, запущенной в асинхронном режиме неблоки­ру­ю­ще­го ввода-вывода, несложно понять, что расхождения на порядок, о которых сказано в главе «Проблемы бенч­мар­кин­га» не заставили себя ждать. Посему стоит сравнивать скорость чтения и записи в AS SSD с синхронными ре­жи­ма­ми.

Рис 2. Коллаж результатов, полученных в процессе тестирования SSD-накопителя
утилитой NIOBench в синхронных режимах

Из предыдущей публикации следует, что контроллер SSD-накопителя Intel SSDSC2BB120G6 не реагирует на кон­тент паттерна. Ему все равно с какими данными оперирует тест: с файлами, заполненными нулями, или со слу­чай­ны­ми данными, полученными с помощью аппаратной рандомизации. Это к вопросу, почему во всех испытаниях используется параметр Hardware RNG.

Утилита NIOBench v0.42 допускает использовать следующие опции по управлению записью (напомним, про­це­ду­ры чтения и записи выполняются исключительно средствами java-фреймворка NIO):

1. Synchronize write+copy — принудительная синхронизация сохраняемых файлов для бенчмарок записи и ко­пи­рования, то есть для всех видов записи на диск.
2. Synchronize write — принудительная синхронизация сохраняемых файлов для бенчмарок записи; бенч­мар­ки копирования выполняются в режиме по умолчанию — с разрешением отложенной записи.
3. Synchronize+sparse — этот режим подобен Synchronize write+copy, но при открытии файлов добавляется атрибут SPARSE, сообщающий процедурам обслуживания файловой системы, что данный файл пла­ни­ру­ет­ся использовать для хранения разреженных (что также означает — хорошо сжимаемых) данных.

Результаты неблокирующего ввода-вывода во всех синхронных режимах также представим в табличном виде.

Таблица 2

Подведем итоги

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

Тест чтения SSD-накопителя

Утилита AS SSD продемонстрировала лучшие результаты в производительности Sequentional Read (последо­ва­тель­но­го чтения) с твердотельного носителя, что, скорее всего, можно объяснить различием в стратегии работы с дисковым кэшем, а точнее методах нивелирования его влияния на результаты бенчмарок. Низкоуровневый тест AS SSD, лишенный java-прослойки, не ограничен в управлении опциями ОС API.

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

Утилита NIOBench, действуя в рамках фреймворка java.NIO ограничена в методах воздействия на опции ОС API, по­это­му, арсенал средств управления поведением ОС несколько скромнее, очистка кэша выполняется путем его переполнения, в частности копированием больших объемов данных. В этой ситуации кэшированная информация вытесняется, а накладные расходы, связанные с кэшированием, «не окупившись» в виде ускорения доступа, при­ве­ли к снижению производительности. Такой сценарий, связанный с переполнением кэша, достаточно рас­про­стра­нен в реальных приложениях.

Кажущееся отклонение от регулярности в методике испытаний NIOBench нивелируется удовлетворительной до­сто­вер­ностью результатов, когда погрешность не выходит за рамки 2,44%, что наблюдается и при 4K-чтении AS SSD и косвенно подтверждается в режиме съема бенчмарок записи данных на SSD-устройство.

Тест записи SSD-накопителя

Очевидна корреляция последовательной записи в AS SSD с аналогичной операцией NIOBench с небольшой раз­ни­цей в постоянную составляющую, заметно меньшую, чем при чтении (около 2 МБ/сек против 55 МБ/сек). Результат закономерен, если принять во внимание, что в случае записи в арсенале NIOBench есть опция DSYNC (Data Syn­chro­nize), соответствующая нативному флагу FILE_FLAG_WRITE_THROUGH. Из этого неопровержимо следует, что кэширование записи выключается, и, в отличие от чтения, нет необходимости искать сценарии переполнения кэш-памяти и нести накладные расходы по ее обслуживанию.