После цикла экспериментов по бенчмаркам копирования данных стоит поинтересоваться, какие факторы влияют на скорость записи и чтения информации на твердотельных носителях? В прошлый раз мы исследовали результаты, полученные с помощью двух разных метрик, разработанных разными авторами: в тестовых испытаниях были задействованы утилиты 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а
| Испытание | Read №1 | Read №2 | Read №3 | Среднее | Погрешность | В %% |
| Seq[uential] | 425,66 | 421,39 | 421,62 | 422,89 | 1,85 | 0,44% |
| 4K [format] | 22,08 | 24,43 | 22,60 | 23,04 | 0,93 | 4,03% |
| 4K-64 Thrd | 253,03 | 254,14 | 254,14 | 253,77 | 0,49 | 0,19% |
Таблица 1б
| Испытание | Write №1 | Write №2 | Write №3 | Среднее | Погрешность | В %% |
| Seq[uential] | 141,25 | 141,03 | 141,53 | 141,27 | 0,17 | 0,12% |
| 4K [format] | 71,71 | 71,39 | 68,89 | 70,66 | 1,18 | 1,67% |
| 4K-64 Thrd | 104,25 | 104,47 | 104,03 | 104,25 | 0,15 | 0,14% |
Сравнивая полученные данные с результатами утилиты NIOBench, запущенной в асинхронном режиме неблокирующего ввода-вывода, несложно понять, что расхождения на порядок, о которых сказано в главе «Проблемы бенчмаркинга» не заставили себя ждать. Посему стоит сравнивать скорость чтения и записи в AS SSD с синхронными режимами.
Рис 2. Коллаж результатов, полученных в процессе тестирования SSD-накопителя
утилитой NIOBench в синхронных режимах
Из предыдущей публикации следует, что контроллер SSD-накопителя Intel SSDSC2BB120G6 не реагирует на контент паттерна. Ему все равно с какими данными оперирует тест: с файлами, заполненными нулями, или со случайными данными, полученными с помощью аппаратной рандомизации. Это к вопросу, почему во всех испытаниях используется параметр Hardware RNG.
Утилита NIOBench v0.42 допускает использовать следующие опции по управлению записью (напомним, процедуры чтения и записи выполняются исключительно средствами java-фреймворка NIO):
- Synchronize write+copy — принудительная синхронизация сохраняемых файлов для бенчмарок записи и копирования, то есть для всех видов записи на диск.
- Synchronize write — принудительная синхронизация сохраняемых файлов для бенчмарок записи; бенчмарки копирования выполняются в режиме по умолчанию — с разрешением отложенной записи.
- Synchronize+sparse — этот режим подобен Synchronize write+copy, но при открытии файлов добавляется атрибут SPARSE, сообщающий процедурам обслуживания файловой системы, что данный файл планируется использовать для хранения разреженных (что также означает — хорошо сжимаемых) данных.
Результаты неблокирующего ввода-вывода во всех синхронных режимах также представим в табличном виде.
Таблица 2
| Испытание | Synchronize write+copy |
Synchronize write |
Synchronize +sparse |
Среднее | Погрешность | В %% |
| Read | 358,71 | 343,70 | 367,84 | 356,75 | 8,70 | 2,44% |
| Write | 139,80 | 138,78 | 138,95 |
139,18 |
0,71 | 0,29% |
Подведем итоги
Как и в первом раунде тестирования, результаты чтения и записи демонстрируют «кучность» в каждой из тестовых сред и релевантность результатов, полученных различным способом.
Тест чтения 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 Synchronize), соответствующая нативному флагу FILE_FLAG_WRITE_THROUGH. Из этого неопровержимо следует, что кэширование записи выключается, и, в отличие от чтения, нет необходимости искать сценарии переполнения кэш-памяти и нести накладные расходы по ее обслуживанию.