Как измерять производительность диска и памяти сервера

Быстрые ссылки

• Как измеряется производительность IO?

• Установка fio для тестов случайного чтения/записи

• Тестирование производительности памяти

Как измеряется производительность ввода-вывода (IO)

Нет единого числа «скорости» диска — разные нагрузки требуют разных метрик. Основные понятия:

• Последовательный ввод/вывод: чтение или запись больших непрерывных блоков данных. Измеряется в МБ/с (мегабайт в секунду). Полезно для резервного копирования и потоковой передачи.
• Случайный ввод/вывод: доступ к данным в произвольных блоках. Критичен для баз данных, веб-серверов и многопользовательских нагрузок. Измеряется в IOPS (операций ввода-вывода в секунду) и в МБ/с для суммарной пропускной способности.

Определение: IOPS — количество завершённых операций ввода-вывода в секунду; МБ/с — суммарный объём переданных данных в мегабайтах в секунду.

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

Твердотельные накопители (SSD) обычно показывают высокую производительность случайного доступа и поэтому лучше подходят для общих серверных задач. Жёсткие диски (HDD) имеют хорошие последовательные скорости и подходят для архивации и больших объёмов данных, где доминирует последовательный доступ.

Важно: многие приложения кэшируют данные в памяти (если ОЗУ достаточно), поэтому повторное чтение часто происходит из памяти, а не с диска. Для записей кеширование менее эффективно — запись должна быть зафиксирована на носителе.

Единицы измерения

• МБ/с (MB/s) в русскоязычной среде часто записывают как МБ/с.
• IOPS — без изменений.

Формула для грубой конвертации между МБ/с и IOPS (при фиксированном размере блока):

IOPS = (MBps / Block Size) * 1024

Примечание: в формуле MBps — мегабайты в секунду, Block Size — размер блока в килобайтах; результат даёт количество операций в секунду. Разные поставщики могут считать IOPS по-разному (например, используют разные блоки), поэтому всегда проверяйте методику и проводите собственные тесты.

Установка fio для тестов случайного чтения/записи

Для реальных смешанных и случайных тестов дисков используйте fio — гибкий генератор нагрузки. Команда установки в Debian/Ubuntu:

sudo apt-get install fio

Пример базового запуска для смешанного теста (80% чтений, 20% записей) на 250 МБ данных:

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read_write.fio --bs=4k --iodepth=64 --size=250M --readwrite=randrw --rwmixread=80

Пояснения к параметрам (кратко):

• –bs=4k — размер блока 4 КБ (стандарт для случайных тестов).
• –iodepth=64 — количество параллельных запросов на одно потоковое устройство.
• –direct=1 — минует кеш ОС (тестирует реальный диск).
• –size=250M — объём данных, используемых для теста.
• –readwrite=randrw и –rwmixread=80 — смешанный режим 80/20.

Результаты fio включают IOPS, МБ/с и среднюю/перцентильную латентность. Примерное изображение вывода:

Пояснения по интерпретации результатов:

• IOPS важнее, если у вас много мелких операций (64–4КБ).
• Средняя латентность и перцентильные латентности (p95, p99) важны для пользовательского опыта. Высокая средняя IOPS с плохими p99 может означать нестабильную задержку.
• Записи часто медленнее чтений, особенно у некоторых типов SSD и HDD, из‑за накладных операций записи и флаш-циклов.

Типы тестов fio

• seqread — последовательное чтение
• seqwrite — последовательная запись
• randread — случайное чтение
• randwrite — случайная запись
• randrw — смешанный случайный

Блоки 16К–32КБ чаще ближе к реальной нагрузке для последовательных операций.

Тестирование производительности памяти

fio не измеряет ОЗУ, поэтому для памяти используют sysbench (или специализированные бенчмарки). Установка в Debian/Ubuntu:

sudo apt-get install sysbench

Пример синтетического теста записи памяти, который выделяет 1 МБ блоки и пишет всего 10 ГБ данных (не требуется 10 ГБ физической ОЗУ):

sysbench --test=memory --memory-block-size=1M --memory-total-size=10G run

Вывод покажет скорость в МиБ/с и латентность доступа.

Параметры для контроля:

• –memory-oper=read — чтобы измерить операцию чтения.
• уменьшение размера блока увеличивает нагрузки на контролер и кеш, повышая число операций и латентность.

На практике количество ОЗУ обычно важнее её пропускной способности для большинства серверных задач; однако для специализированных вычислений и баз данных пропускная способность и задержка памяти критичны.

Когда тесты диска и памяти не отражают реальной нагрузки

Important: Результаты синтетических тестов зависят от параметров: размер блока, глубина очереди, соотношение чтений/записей, использование кеша. Сценарии, где простой fio/sysbench даёт вводящие в заблуждение результаты:

• Нагрузки, зависящие от сетевого I/O, а не от диска.
• Приложения, использующие кеш верхнего уровня (напр., Redis, memcached) — повторные обращения идут в память.
• RAID или LVM-уровни, где контроллер и драйвер меняют поведение операций (дополнительная латентность/кеширование).
• Облачные диски с динамическим предоставлением производительности (burst-пики), которые не поддерживают непрерывную высокую производительность.

Альтернативные инструменты и диагностика

• dd — простой инструмент для последовательных тестов (быстро, но небезопасно как индикатор случайной нагрузки).
• iostat / vmstat — мониторинг в реальном времени (долгосрочные метрики).
• bonnie++ — комплексный диск-бенчмарк (старее, но даёт дополнительные сценарии).
• fio — универсальный вариант для произвольных сценариев.

Когда использовать dd (пример):

dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct

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

Мини‑методика: как получить воспроизводимые тесты (SOP)

1. Подготовка окружения
   • Остановите несущественные сервисы, которые могут влиять на диск (бэкапы, индексаторы).
   • Убедитесь, что тест выполняется на правильном разделе/устройстве (не на корневом FS, если хотите тестировать raw device).
2. Настройки ОС
   • Используйте –direct=1 в fio, чтобы миновать кеш ОС, если нужно тестировать носитель.
   • Повторите тест несколько раз (минимум 3) и усредните результаты.
3. Варьируйте параметры
   • Тесты: seqread/seqwrite/randread/randwrite/randrw
   • Размеры блоков: 4K, 16K, 32K
   • Глубина очереди: 1, 16, 64
4. Сохранение и анализ
   • Логируйте выводы в файл. Фиксируйте время выполнения, загрузку CPU и температуры.
5. Критерии приёмки
   • Определите порог IOPS/МБ/с и p99-латентность, при которых приложение считается работоспособным.

Шаблон команд для распространённых сценариев (cheat sheet)

• Смешанный случайный тест 80/20, 4K блоки:

fio --name=mix --filename=/path/to/testfile --size=1G --bs=4k --readwrite=randrw --rwmixread=80 --iodepth=32 --direct=1 --ioengine=libaio

• Последовательная запись, большой блок 32K:

fio --name=seqw --filename=/path/to/testfile --size=2G --bs=32k --readwrite=seqwrite --direct=1

• Тест памяти на чтение:

sysbench --test=memory --memory-oper=read --memory-block-size=1M --memory-total-size=10G run

Руководство по ролям: что проверяет кто

• Системный администратор:
  • Выполняет fio/sysbench, собирает логи, мониторит iostat и dmesg.
• Разработчик приложения:
  • Проверяет p95/p99 латентности и реагирует на проблемы временных задержек.
• DevOps/инженер по производительности:
  • Планирует нагрузочные тесты, сопоставляет с требованиями SLO/SLI.

Примеры тестовых случаев и критерии приёмки

• Тест-кейс: 4K randrw, iodepth=64, 80% чтений. Критерий приёмки: IOPS >= целевого значения (установить внутренний порог), p99 < 50 мс.
• Тест-кейс: seqwrite 32K, цель — непрерывная запись 200 МБ/с без ошибок.

Критерии приёмки должны быть согласованы с владельцем сервиса и зависят от рабочего профиля (OLTP, аналитика, файловое хранилище).

Дерево решений (быстрое) — какой тест запускать?

flowchart TD
  A[Нужна проверка диска?] --> B{Тип нагрузки}
  B --> |Последовательная| C[Запустить seqread/seqwrite]
  B --> |Случайная/много маленьких операций| D[Запустить randread/randwrite/randrw с 4K]
  B --> |Смешанная| E[Запустить randrw с rwmixread=r]
  C --> F[Проанализировать МБ/с и CPU]
  D --> G[Проанализировать IOPS и p99]
  E --> G
  F --> H{Соответствует SLO?}
  G --> H
  H --> |Да| I[Документировать и принять]
  H --> |Нет| J[Изучить: кеш, драйвер, RAID, provisioning]

Риски и рекомендации

• Риск: тестирование на виртуальном диске облачного провайдера может показывать «burst» значения. Рекомендация: проводите длительные тесты и проверяйте документацию провайдера по гарантированной производительности.
• Риск: тесты с кешем ОС дают нереалистично высокие результаты. Рекомендация: для честного теста используйте –direct=1.

Короткая сводка

• Измеряйте и анализируйте оба типа: последовательные и случайные операции.
• fio и sysbench — ваши основные инструменты для диска и памяти.
• Всегда повторяйте тесты, фиксируйте параметры и сравнивайте с критериями приёмки.

Summary (ключевые выводы):

• Сконцентрируйтесь на случайной производительности (IOPS и латентности) для многопользовательских приложений.
• Используйте прямой доступ к устройству (direct) для реальной картины.
• Понимайте влияние блочного размера и глубины очереди на результаты.