Тестирование IOPS дисков в Linux

В этой статье рассмотрим способы тестирования производительности IOPS дисков или дискового массива в Linux. IOPS (input/output operations per second) – количество операций ввода-вывода, выполняемые системой хранения данных за одну секунду (это может быть как один диск, RAID массив или LUN на системе хранения). Условно IOPS можно считать количество блоков, которые успевает считаться или записаться на носитель.

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

Установка утилиты fio для тестирования IOPS в Linux

Для замера производительности IOPS дисков в Linux можно использовать утилиту fio (утилита доступна для CentOS в репозитории EPEL). Соотвественно для установки fio в RHEL, CentOS используется пакетный менеджер yum (dnf):

# yum install epel-release -y
# yum install fio -y

Либо apt-get в Debian, Ubuntu :

# apt-get install fio

Затем вам нужно определить диски для тестирования. Тестирование выполняется путев выполнения операций записи/чтения в той директории, в которую примонтирован диск или LUN.

Измерение производительности дисков в IOPS с помощью fio

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

Тест случайных операций на чтение/запись

При запуске такого теста, будет создан файл размером 8 Гб. Затем утилита fio выполнит чтение/запись блока 4КБ (стандартный размер блока) с разделением на 75/25% по количеству операций чтения и записи и замерит производительность. Команда выглядит следующим образом:

# fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=fiotest —filename=testfio —bs=4k —iodepth=64 —size=8G —readwrite=randrw —rwmixread=75

Первую проверку я запустил на массиве из двух SSD дисков и результаты получились хорошие:

Чтение:

328MiB/s, 83000 IOPS
Запись:

110MiB/s, 28000 IOPS

Так как мы запустили тест на чтение/запись, показатели по отдельным проверкам, будут чуть выше.

Для сравнения, я замерил скорость на обычном SATA диске:

Чтение

1.7 MiB/s, 430 IOPS
Запись

0.5 MiB/s, 143 IOPS

Для HDD диска результаты, конечно гораздо хуже, чем для SSD.

Тест случайных операций на чтение

Чтобы замерить производительность дисков только для случайных операций на чтение, нужно выполнить следующую команду:

# fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=fiotest —filename=testfio —bs=4k —iodepth=64 —size=8G —readwrite=randread

Команда поменялась в самом конце на —readwrite=randread .

Как ранее я уже говорил, скорость по отдельным замерам будет выше:

Если запустить тест только на чтение, разница со смешанным тестом достигает (200-250 MiB/s и 67000 IOPS), что достаточно ощутимо.

Тест случайных операций на запись

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

# fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=fiotest —filename=fiotest —bs=4k —iodepth=64 —size=8G —readwrite=randwrite

Производительность операций записи на хороших SSD дисках тоже очень высокая. Как и в случае с чтением, разница со смешанным тестом достигает 200-250 MiB/s, а в IOPS 56000.

Если опираться на официальную документацию по дискам от производителя (это SSD диски от Intel), можно смело сказать, что в данном случае они не обманули.

Тестирование производительности дисков с помощью файлов.

Утилита fio позволяет проверять диски не только с помощью интерактивного запуска команд, но и запускать заранее подготовленные конфигурационные файлы для тестов. Чтобы воспользоваться данным вариантом, создайте файл:

И добавьте в него содержимое:

Теперь запустите тест:

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

Проверка latency диска с помощью ioping

Помимо IOPS есть еще один важный параметр, характеризующий качество вашей дисковой подсистемы – latency. Latency – это время задержки выполнения запроса ввода/вывода и характеризуют время доступа к системе хранения (измеряется в миллисекундах). Чем выше latency, тем больше приходится ждать вашему приложения данных от дисковой подсистемы. Для типовых систем хранения значения latency более 20 мс считаются плохими.

Для проверки latency диска используется утилита ioping:

# yum install ioping -y

# apt-get install ioping

Запустите тест latency для диска (выполняется 20 запросов):

# ioping -c 20 /tmp/

Среднее значение 298.7 us (микросекунд), т.е. средняя latency диска в нашем случае 0.3 ms, что очень хорошо.

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

Источник

Нагрузка на диски в Linux

Для измерения текущей нагрузки на диски (что происходит, кто куда копирует и прочее) в Linux можно использовать iotop (и здесь же lsof) и iostat. А для тестирования возможностей дисковой системы fio. Несмотря на то, что первое, о чем можно подумать в плане попугаев — это IOPS или же Мб/сек за чтение или запись, обратите внимание на время ожидания. Примерно как если бы вы стояли в очереди в кассу: вас обслужили бы за 2 минуты, но очередь может быть минут на 30. И со стороны наблюдателя ваш процесс обслуживания будет «висеть». Именно так могут ощущать себя клиенты сервера, если время ожидания будет намного превышать время выполнения конкретной задачи. Поэтому определение длинной очереди и задержек часто бывает более важным, чем знать, что ваш диск «вау, может писать 400 Мбит/с». Нагрузка на диск может оказаться в 4000 Мбит/с в течение длительных периодов времени и все это время клиенты сервера будут недовольны.

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

IOTOP

Посмотреть, какие процессы в настоящее время создают нагрузку на диск удобно смотреть командой iotop:

Здесь видно, что в данный момент mc что-то пишет (а в это время в другом окне я в самом деле копировал кучу файлов на usb-диск в Midnight Commander (он же mc).

Понять, что коипрует mc в данный момент можно узнать командой:

IOSTAT

Пример вывода iostat на незагруженной в данный момент старенькой системе из двух SATA HDD в soft raid 1 (зеркало) mdadm:

Команда выглядела так:

-x — расширенная статистика

-t — выводить время для каждой порции замеров

-m — результаты в Мбайт

5 — интервал замеров 5 секунд.

Если нужны не история, а динамика процесса, попробуйте так:

watch iostat -x -t -m 1 2

В этом выводе r/s и w/s это отправленные к устройству запросы на выполнение (IOPS, которые хотелось бы, чтобы устройство выполнило).

await — время, включающее ожидание выполнения запроса (как если бы вы встали в очередь в кассу и ждали бы, пока вас обслужат).

svctm — время, реально затраченное на выполнение запроса (время «на самой кассе»).

Для обычных SATA дисков нагрузка IOPS где-то до 100-130 вполне выполнимая. В момент проведения замеров запрошенная нагрузка была 40 IOPS, поэтому запрос практически в очереди и не стоял, его обслужили почти сразу (на «кассе» никого не было). Поэтому await практически равен svctm.

Другое дело, когда нагрузка на диск вырастает:

%iowait — простой процессора (время в процентах) от или процессоров, в то время пока обрабатывались запросы. Т.е. в среднем процессор отдыхал почти 50% времени.

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

Замер сделан во время переноса большого количества писем из одной папки IMAP в другую. Особо обратите внимание на await и svctm. Налицо длинная очередь (отношение await к svctm). Дисковая система (или чипсет, или медленный контроллер SATA, или. ) не справляется с запрошенной нагрузкой (w/s).. Для пользователей в этот момент все выглядело просто — сервер тупит или даже завис.

Заранее проверить производительность дисков можно с помощью fio. Также можно примерно оценить на одной машине производительность дисков и понимать, какой уровень «в среднем по больнице» вы можете ожидать. Это, конечно же, не правильно, но оценить все же поможет. Глубже анализировать результаты, а, главное, методики тестов мне пока трудно.

# yum install fio

# apt-get install fio

В общем виде запуск выглядит так:

Файл your.cfg (название произвольное) может быть примерно таким (пример рабочего конфига для теста на чтение):

Буферизацию не используем (buffered=0), чтение не последовательное (rw=randread).

Во время выполнения этого теста (а выполняться тест может доооолго, надоест — Ctrl+C, результаты все равно будут) можно запустить iostat и посмотреть, что происходит:

Обратите внимание на отношение await к svctm: await/svctm = 32,11..11, т.е. можно считать 32. Это и есть iodepth из конфига your.cfg. Теперь проще понять смысл iodepth — мы указываем, насколько хотим в тесте имитировать длинную очередь заданий.

Я не стал ждать два дня, Ctrl+C и вот результат:

Получили 109 iops, что в принципе нормально, диск обычный, SATA.

Источник

Утилита fio — тест производительности дисков в Linux

Для замера производительности дисковой системы в Linux есть замечательная утилита fio (Flexible I/O tester). Утилита позволяет использовать для тестирования заранее написанные файл-тесты, в которых указывается что именно мы хотим измерить.

К примеру, можно провести тест на производительность при последовательном и случайном чтении/записи на диск.

Установка fio

Измеряем производительность NVMe диска с помощью fio

Есть сервер Dell PowerEdge R640 с NVMe дисками SSD Dell EMC NVMe 3.84 TB — KCD5XLUG3T84. В спецификации указаны следующие параметры производительности для данной модели NVMe диска:

• Последовательное чтение: 3140 MBPS
• Последовательная запись: 1520 MBPS
• Случайное чтение: 465000 IOPS
• Случайная запись: 40000 IOPS

Загружаю на сервере Dell Support Live Image с операционной системой CentOS. Работаю в терминале под рутом. Устанавливаю репозиторий EPEL:

Создаю файл-тест с конфигурацией тестирования, назову его srcmvme0n1:

Будем проводить четыре теста:

• Случайное чтение блоками 4k
• Случайная запись блоками 4k
• Последовательное чтение блоками 512k
• Последовательная запись блоками 512k

Процедура тестирования может занять продолжительное время.

Сравню полученные результаты с заявленными в спецификации (в скобках).

• Последовательное чтение: 2518 (3140) MBPS
• Последовательная запись: 1583 (1520) MBPS
• Случайное чтение: 342000 (465000) IOPS
• Случайная запись: 278000 (40000) IOPS

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

Заключение

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

Я не самый большой специалист в тестировании дисков и не досконально знаю все возможные опции для настройки файл-теста. Однако, готовые шаблоны можно всегда найти в Интернете.

Дотошные читатели могли заметить, что мой тест завершается строкой «Bus error». Скорее всего, данной ошибкой можно пренебречь, советуют воспользоваться более новой версией fio. Но я не стал заморачиваться, поскольку результат тестирования меня устроил.

Хотелось бы отметить, что утилитой fio кроме дисков можно проводить тестирование программных и аппаратных массивов.

Источник

How to Check Disk Performance (IOPS and Latency) in Linux?

In this article we will discuss how to check the performance of a disk or storage array in Linux. IOPS (input/output operations per second) is the number of input-output operations a data storage system performs per second (it may be a single disk, a RAID array or a LUN in an external storage device). In general, IOPS refers to the number of blocks that can be read from or written to a media.

Most disk manufacturers specify nominal IOPS values, but in fact these are not guaranteed. To understand the performance of your storage subsystem prior to starting a project, it is worth getting the maximum IOPS values your storage can handle.

Using FIO (Flexible I/O) Tool for Storage Benchmarking

To measure disk IOPS performance in Linux, you can use the fio (the tool is available for CentOS/RHEL in EPEL repository). So, to install fio in RHEL or CentOS, use the yum (dnf) package manager:

# yum install epel-release -y
# yum install fio -y

Or apt-get in Debian or Ubuntu:

# apt-get install fio

Then you to identify the disks to test. The test is done by performing read/write operations in the directory your disk or LUN is mounted to.

Let’s do several types of disk IOPS performance tests in various disk load scenarios (a test mode you select depending on a hosted app logic and general infrastructure of a project).

Random Read/Write Operation Test

When running the test, an 8 GB file will be created. Then fio will read/write a 4KB block (a standard block size) with the 75/25% by the number of reads and writes operations and measure the performance. The command is as follows:

# fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=fiotest —filename=testfio —bs=4k —iodepth=64 —size=8G —readwrite=randrw —rwmixread=75

I ran my first test on an array that consisted of two SSDs and got good results:

• Read: 3280MiB/s, IOPS avg 83000
• Write: 110MiB/s, IOPS avg 28000

Since we have run a combined read/write test, the values for the separate tests will be higher.

In comparison, I measured the performance on a SATA drive:

• Read: IOPS=430, BW=1.7 MiB/s
• Write: IOPS=143, BW= 0.6 MiB/s

Of course, the HDD results are worse than those of the SSD.

Random Read Operation Test

To measure disk performance for random read operations only, run the following command:

# fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=fiotest —filename=testfio —bs=4k —iodepth=64 —size=8G —readwrite=randread

The final part of the command was changed to —readwrite=randread .

As I told earlier, the read/write performance will be higher if measured separately:

Random Write Operation Test

To measure disk performance for random write operations, run this command:

# fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=fiotest —filename=fiotest —bs=4k —iodepth=64 —size=8G —readwrite=randwrite

Write operation performance on good SSDs is also very high. Like in read operation test, the difference as compared to a mixed test reaches 200-250 MiB/s and 50000 IOPS.

If you refer to the official manufacturer documentation (these are Intel SSDs), it is safe to say that the values are true.

Fio Config File Examples

Fio allows to check disk performance using interactive commands and with configuration files prepared in advance for testing. To use the this option, create a file:

And add the following contents into it:

Then start the test:

The test will measure the read performance of a disk. To test write performance, use the following config file:

Measuring Disk Latency Using Ioping

Besides IOPS, there is another important parameter that characterizes the quality of your storage: it is latency. Latency is an input/output request delay that determines the time of access to a storage (measured in milliseconds). The higher the latency is, the more your app has to wait till it gets data from your disk. The latency values over 20 ms for typical data storage systems are considered poor.

To check disk latency in Linux, the ioping tool is used:

# yum install ioping -y

# apt-get install ioping

Run the latency test for your disk (20 requests are run):

# ioping -c 20 /tmp/

The average value is 298.7 us (microseconds), so the average latency in our case is 0.3 ms, that is excellent.

So you can perform a storage load test on your server prior to launching a project and check the highest performance values. However, the test doesn’t guarantee that your disk array or disk will show the same performance constantly, but it is worth to take the test on the initial stage of a project. Learn how to test IOPS in Windows in this article.

Источник