Производительность SSD в Linux: методы оценки и тесты

Средняя пропускная способность здесь не заменяет этот показатель: накопитель может показывать высокие MB/s в последовательном тесте и одновременно задерживать критичные операции fsync. Для баз данных, виртуальных машин и системных журналов это разные характеристики, и проверять их нужно раздельно.

Оценка производительности SSD в Linux начинается не с выбора самой быстрой утилиты, а с определения нагрузки. Последовательное чтение, случайный доступ блоками 4k и синхронная запись нагружают накопитель по-разному. Один тест не описывает все три режима. Поэтому результат в MB/s без размера блока, глубины очереди, движка ввода-вывода и параметров кеширования практически невозможно интерпретировать.

Почему hdparm не показывает полную картину

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

Число из такого теста легко принять за общую характеристику диска. Это ошибка методики. Последовательный доступ крупными блоками подходит для задач вроде чтения больших файлов. Операции приложений часто состоят из множества небольших запросов, где важны IOPS и задержка, а не только пропускная способность.

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

Для быстрой диагностики hdparm допустим: например, чтобы проверить, нет ли очевидного провала в последовательном чтении. Для сравнения SSD под прикладной нагрузкой нужен профиль, который задаёт тип операций, размер блока и очередь. Эту задачу решает fio.

fio: профиль нагрузки важнее одной команды

fio — Flexible I/O Tester, основной инструмент для воспроизводимых тестов ввода-вывода в Linux. Его создал Йенс Аксбо, разработчик подсистемы ввода-вывода ядра Linux. Утилита позволяет задавать смешанные и отдельные профили: чтение или запись, последовательный или случайный доступ, размер блока, глубину очереди, число потоков и длительность прогона.

Для диска обычно анализируют три группы результатов:

• Пропускная способность, как правило, в MB/s. Она показывает объём данных, который проходит за единицу времени.
• IOPS — число операций ввода-вывода в секунду. Метрика полезна для случайных запросов небольшого размера.
• Задержка — время выполнения отдельной операции. Для сервисов с синхронной записью особенно важны верхние процентили, а не только среднее значение.

fio поддерживает разные движки ввода-вывода. Для асинхронной работы в Linux применяют, в частности, libaio и io_uring. Их нельзя считать взаимозаменяемыми настройками, которые автоматически дают одинаковый результат: смена движка меняет путь обработки запросов. Если сравниваются два накопителя, параметры должны оставаться одинаковыми. Если сравниваются два режима ядра или приложения, движок, напротив, может быть предметом отдельного теста.

В конфигурации стоит фиксировать как минимум:

• режим доступа: последовательный или случайный;
• размер блока: 4k для типового теста random I/O, 512k или 1M для последовательных операций;
• глубину очереди iodepth;
• число потоков и соотношение чтения к записи;
• движок ioengine;
• включён ли прямой ввод-вывод;
• длительность прогона и размер тестового файла.

Флаг --direct=1 применяют, чтобы исключить влияние Page Cache при тестировании диска. Без него данные могут обслуживаться кешем операционной системы, и измерение перестанет отражать производительность накопителя. При этом прямой ввод-вывод не делает тест автоматически похожим на приложение: профиль доступа всё равно нужно выбирать по реальной нагрузке.

KDiskMark — графическая оболочка над fio. Она удобна, когда нужно запустить типовые тесты без ручной сборки параметров. По назначению интерфейс близок к CrystalDiskMark: он показывает результат в привычном виде, но за цифрами остаются параметры профиля. При публикации результата или сравнении с другим диском эти настройки нужно сохранять, иначе сопоставление будет приблизительным.

Размер блока и глубина очереди

iodepth — количество запросов ввода-вывода, ожидающих выполнения одновременно. При малой глубине диск обрабатывает ограниченное число операций. При большой — получает больше параллельной работы. Это влияет на IOPS и пропускную способность, но не означает, что максимальная очередь соответствует типичной нагрузке конкретной системы.

Для random I/O часто используют блок 4k. Такой тест помогает оценить работу с небольшими запросами, характерными для ряда системных и прикладных операций. Для последовательного чтения и записи используют более крупные блоки — например, 512k или 1M. Результаты этих профилей отвечают на разные вопросы. Сравнивать их между собой как единую оценку диска нельзя.

Глубина очереди 16, 32, 64 или 256 задаёт разные режимы нагрузки. Высокая очередь может показать, на что способен накопитель при параллельной подаче запросов. Но рабочее приложение может не формировать такую очередь. Если измерить только высокую глубину, можно получить показатель, который не соответствует задержке одиночного запроса или малопараллельной нагрузки.

Практичный набор тестов строится от сценария:

1. Последовательное чтение и запись крупными блоками. Полезно для крупных файлов и потокового доступа. Запись выполняют только в безопасный тестовый файл или на выделенный тестовый накопитель.

2. Случайное чтение блоками 4k. Показывает поведение при множестве небольших запросов.

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

4. Несколько значений iodepth. Дают профиль зависимости IOPS, пропускной способности и задержки от параллелизма.

5. Смешанный профиль чтения и записи. Имеет смысл, если он соответствует приложению; универсального соотношения для всех систем нет.

Размер блока задаёт характер запроса. Глубина очереди — уровень параллелизма. Без этих двух параметров число IOPS почти ничего не говорит о нагрузке.

Сравнение файловых систем на Linux требует отдельной дисциплины. Если тестируются ext4, XFS или другая файловая система, нужно удерживать одинаковыми устройство, размер тестового файла, параметры монтирования, профиль fio и состояние накопителя. Следует также различать тест блочного устройства и тест файла внутри смонтированной файловой системы: во втором случае измеряется не только SSD, но и путь через файловую систему. Нельзя приписывать разницу одной файловой системе, если одновременно менялись режим кеширования или глубина очереди.

Задержка и 99-й процентиль

Среднее значение сглаживает редкие, но существенные задержки. Для систем, чувствительных к времени ответа, полезно смотреть распределение latency и отдельно оценивать высокие процентили. В etcd ориентир для 99-го процентиля задержки синхронизации диска — не более 10 мс. Это не универсальный норматив для любого SSD или приложения, а показатель, связанный с требованиями конкретного распределённого хранилища.

Для анализа задержек ввода-вывода недостаточно записать одну цифру из итоговой строки теста. Нужно понимать, что именно измерялось: чтение или запись, синхронный или асинхронный режим, какая глубина очереди была задана и включал ли тест прямой ввод-вывод. Результат с низкой средней задержкой при коротком прогоне не гарантирует такой же профиль при длительной нагрузке.

При разборе отчёта fio полезно разделять три вопроса:

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

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

Безопасность теста и защита данных

Самая опасная ошибка при работе с fio — запуск записи напрямую на системное устройство. Параметры вида --filename=/dev/sdX или /dev/nvmeXn1 при тесте записи могут уничтожить файловую систему и данные на диске. Такой сценарий допустим только для выделенного устройства, когда данные не нужны и риск потери заранее принят.

Для обычной проверки следует направлять нагрузку в отдельный тестовый файл на целевой файловой системе. Это безопаснее для существующей разметки, но не отменяет контроля размера файла и свободного места. Тест записи способен занять значительный объём и создать дополнительную нагрузку на накопитель. На рабочем сервере запускать его без окна обслуживания и оценки влияния на приложения не следует.

Перед запуском проверьте саму конфигурацию:

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

Повторяемость важнее эффектного результата. На показатели влияют фоновые операции, заполненность SSD, состояние кешей и конкурирующая нагрузка. Один короткий запуск не даёт надёжного основания для вывода о деградации устройства. Для мониторинга износа SSD нужны данные SMART и оценка показателей конкретного устройства. Тест fio сам по себе не позволяет определить точный остаточный срок службы или TBW.

Как собрать применимый результат

Результат тестирования должен содержать не только итоговую скорость, но и профиль, при котором она получена. Минимальная запись для сравнения включает модель накопителя, тип доступа, размер блока, глубину очереди, движок fio, режим direct I/O и измеренные MB/s, IOPS и задержки. Без этого повторить тест или объяснить расхождение будет сложно.

Порядок принятия решения простой:

1. Зафиксировать рабочую нагрузку: последовательная передача, random I/O, синхронная запись или смешанный режим.

2. Выбрать соответствующие размеры блоков и глубину очереди.

3. Запустить безопасный тест на файле либо на отдельном тестовом устройстве.

4. Сравнить не только пропускную способность, но и IOPS с распределением задержек.

5. Повторить измерение в сопоставимых условиях и проверить фоновые операции.

6. Для вывода об износе отдельно анализировать SMART; не выводить срок службы из fio.

Оптимальный набор инструментов для Linux — fio для контролируемых профилей, KDiskMark для типового графического запуска и hdparm для ограниченной проверки последовательного чтения. dd годится для простой операционной проверки, но не для достоверного сравнения SSD. Архитектурное решение следует принимать по метрикам реальной нагрузки: сначала latency и IOPS там, где критичен отклик, затем MB/s там, где система передаёт крупные массивы данных.