Еще одна утилита для тестирования производительности накопителей

Анализируя статистику неисправностей накопителей (mass storage devices), нетрудно заметить, что ведущее место занимают отказы, связанные с носителем информации: повреждения поверхности жестких магнитных дисков или износ запоминающих ячеек NAND-памяти для SSD-устройств и USB-флешек. Логично, что информационно-диагностический софт, призванный оценить состояние устройства, делает акцент на выявлении сбоев именно такого типа. Предлагаем познакомиться с NIOBench — одной из таких утилит, созданной для оценка скорости копирования файлов на магнитных и твердотельных носителях с различными интерфейсами с помощью Java-приложения, использующего Non-Blocking I/O технологию.

Использование файловых операций силами неблокирующего ввода-вывода (NIO) позволяет создавать достаточно серьезную нагрузку на подсистему хранения данных, способствуя проявлению редких ошибок, появляющихся из-за внутренней программы накопителя или проблем с интерфейсным контроллером либо долгочитаемых секторов на поверхности. Ведь своеобразное коварство дисковых проблем в том, что они создают почву для возникновения трудно выявляемых ошибок: при обычном линейном тесте поверхности, управляемом из одного потока выполнения, скрытый дефект, приводящий к сбоям в обработке очереди запросов NCQ, сложно обнаружить. Накопитель исправно проходит все тесты, а в реальных приложениях работает некорректно.

При разработке NIOBench ставилась задача с помощью рандомизированных либо изоморфных паттернов измерить исключительно производительность накопителя (либо схем архивации данных, работающих на уровнях, ниже файловых API, что возможно в некоторых системах хранения данных), минимизируя влияние хост-системы и программного обеспечения.

Практика показала, что начинать тест NIOBench желательно не ранее чем через 3-5 минут после загрузки ОС, так как в первые минуты после загрузки выполняется большое количество фоновых процессов, влияющих на результат бенчмарок. Особенно это актуально, если установлено сравнительно мало оперативной памяти и ОС активно использует своппинг.

Мы в первую очередь акцентируем внимание на результатах для больших файлов (1024 MB), так как при небольших файлах ОС и Java-машина хорошо кэшируют данные. Если за один вызов программного интерфейса обрабатывается больше данных, то такой тест в большей степени зависит от накопителя и в меньшей степени зависит от процессора, ОС, JVM. Поэтому, при размере 1024 MB мы тестируем накопитель, а при размерах 1-10 MB рискуем получить результат, в большей степени зависящий от особенностей платформы, ОС, JVM, чем от накопителя.

Приступая к стресс-тестам, помните, что backup это наше все...

P.S. Относительно ошибки RDRAND. На самом деле это не ошибка, а предупреждение о том, что процессор не поддерживает инструкцию RDRAND и будет использован программный генератор случайных чисел. Этим управляет опция Data:

• Zeroes = заполнение нулями,
• Software RNG = программный генератор случайных чисел.

Если бы инструкция RDRAND поддерживалась, то в выпадающем меню опции Data появился бы вариант Hardware RND.

Инструкция RDRAND поддерживается Intel начиная с ядра Haswell. У AMD, похоже, еще нет процессоров с поддержкой RDRAND, а есть только упоминание о ней в документации. Таким образом, несмотря на данное предупреждение, все управляемо и предсказуемо.