Российская схд aerodisk: нагрузочное тестирование. выжимаем iops-ы

iotop — Monitor disk IO Speed

specialises in getting disk stats and is part of rpm. You can install using or any other tool depending upon your environment.

# rpm -q iotop
iotop-0.6-4.el7.noarch

watches disk I/O usage information output by the Linux kernel (requires 2.6.20 or later) and displays a table of current I/O usage by processes or threads on the system.

With will only show processes or threads actually doing I/O, instead of showing all processes or threads so you can check and monitor disk IO performance.

Advertisement

# iotop --only
Total DISK READ :       0.00 B/s | Total DISK WRITE :    1103.25 M/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:     699.93 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
15091 be/4 root        0.00 B/s  965.33 M/s  0.00 % 99.99 % cp loadfile loadfile1
29926 be/4 root        0.00 B/s    0.00 B/s  0.00 % 15.49 % [kworker/u64:0]
 3312 be/3 root        0.00 B/s  137.92 M/s  0.00 %  0.09 % [jbd2/dm-3-]

Показатели производительности

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

Задержка

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

Если при записи данных результатом операции является короткое сообщение о её завершении, то при чтении данных их передача может иметь заметную продолжительность.

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

У современных дисков в штатном режиме время задержки составляет единицы миллисекунд или даже доли миллисекунд.

Скорость передачи данных

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

Определять скорость передачи данных лучше с помощью файлов большего размера с нерегулярным содержанием. Как правило, этим условиям соответствуют видео- или аудиофайлы, архивы сжатых файлов, большие jpeg-изображения и т. п.

В первую очередь, скорость передачи данных характеризует возможности контроллера, его пропускную способность. Это особенно относится к SSD-дискам.

Число дисковых операций

Во время реальной эксплуатации дисков редко бывает, что на них только записывают или с них только читают данные. Обычно запись и чтение постоянно чередуются между собой. Поэтому в качестве характеристики общей прикладной производительности диска был предложен такой показатель как число операций ввода-вывода в единицу времени: IOPS (Input/output Operations Per Second).

Для правильного сравнения дисков по этой характеристике нужно, чтобы тестовые замеры на каждом из дисков производились с одинаковыми порциями (блоками) данных. Сейчас в качестве таких «стандартных» порций для бытовых компьютеров часто используют блоки размером в 4 килобайта, а для серверов — в 32, 64 и даже 128 килобайтов.

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

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

— Но… в какой пропорции?

Однозначного ответа этот вопрос нет и быть не может. В одних системах данные чаще записывают, чем читают; в других — наоборот. Например, при видеохостинге данные, в основном, читают; в системах протоколирования (log-данные), видеонаблюдения или резервного копирования — записывают; в корпоративных информационных системах — и записывают, и читают.

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

Для правильного тестирования дисковых подсистем нужно моделировать нагрузку

Проверка диска на битые секторы Linux

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

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

В этом примере я хочу проверить раздел /dev/sda2 с файловой системой XFS. Как я уже говорил, для этого используется команда badblocks. Синтаксис у неё довольно простой:

$ sudo badblocks опции /dev/имя_раздела_диска

Давайте рассмотрим опции программы, которые вам могут понадобится:

• -e — позволяет указать количество битых блоков, после достижения которого дальше продолжать тест не надо;
• -f — по умолчанию утилита пропускает тест с помощью чтения/записи если файловая система смонтирована чтобы её не повредить, эта опция позволяет всё таки выполнять эти тесты даже для смонтированных систем;
• -i — позволяет передать список ранее найденных битых секторов, чтобы не проверять их снова;
• -n — использовать безопасный тест чтения и записи, во время этого теста данные не стираются;
• -o — записать обнаруженные битые блоки в указанный файл;
• -p — количество проверок, по умолчанию только одна;
• -s — показывать прогресс сканирования раздела;
• -v — максимально подробный режим;
• -w — позволяет выполнить тест с помощью записи, на каждый блок записывается определённая последовательность байт, что стирает данные, которые хранились там раньше.

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

Это безопасно и её можно выполнять на файловой системе с данными, она ничего не повредит. В принципе, её даже можно выполнять на смонтированной файловой системе, хотя этого делать не рекомендуется. Если файловая система размонтирована, можно выполнить тест с записью с помощью опции -n:

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

Если на разделе используется файловая система семейства Ext, например Ext4, то для поиска битых блоков и автоматической регистрации их в файловой системе можно использовать команду e2fsck. Например:

Параметр -с позволяет искать битые блоки и добавлять их в список, -f — проверяет файловую систему, -p — восстанавливает повреждённые данные, а -v выводит всё максимально подробно.

bus saturation

Последний вопрос — это вопрос затенения шины. О чём речь? Если у нас ssd способна выдать 400 МБ/с, а мы её подключаем по SATA/300, то очевидно, что мы не увидим всю производительность. Причём с точки зрения latency проблема начнёт проявляться задолго до приближения к 300МБ/с, ведь каждому запросу (и ответу на него) придётся ждать своей очереди, чтобы проскочить через бутылочное горлышко SATA-кабеля.

Но бывают ситуации более забавные. Например, если у вас есть полка дисков, подключенных по SAS/300×4 (т.е. 4 линии SAS по 300МБ каждая). Вроде бы много. А если в полке 24 диска? 24*100=2400 МБ/с, а у нас есть всего 1200 (300х4). 

Более того, тесты на некоторых (серверных!) материнских платах показали, что встроенные SATA-контроллеры часто бывают подключены через PCIx4, что не даёт максимально возможной скорости всех 6 SATA-разъёмов.

Повторю, главной проблемой в bus saturation является не выедание «под потолок» полосы, а увеличение latency по мере загрузки шины.

Оцениваем разницу в производительности

Ну а теперь, основываясь на скриншотах пользователей, можно оценить разницу в производительности разных типов носителей.

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

Очевидно, что производительность SSD в рядовых файловых операциях в разы выше, нежели жестких дисков.

Но следует учитывать, что большинство таких тестов проводились при оптимальном подключении, то есть SSD был подключен через интерфейс SATA 3.

Возникает закономерный вопрос, а имеет ли смысл подключать SSD к SATA 2?

Очевидно, что максимальная скорость при последовательных операциях чтения/записи будет ограничена возможностью SATA 2. Напомню, это приблизительно 300 Мбайт/c.

Однако значительно большее значение IOPS сократит задержки в файловых операциях в несколько раз, и, как видно из тестов, скорость случайных операций значительно ниже пропускной способности SATA 2.

Но и тут не все так однозначно…

Как показывают тесты, при подключении к SATA 2 падает и это значение…

Тем не менее, оно все равно значительно выше, нежели у жестких дисков. Поэтому, с моей точки зрения, установка SSD на SATA 2 все равно оправдана — мы получаем возможный максимум при последовательных операциях и в пять-десять раз ускоряем рядовые файловые операции.

Итак, с производительностью определились, осталось разобраться с долговечностью.

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

не может проверить скорость ОЗУ, поэтому, если вы хотите провести тестирование ОЗУ вашего сервера, вы должны установить от менеджера пакетов вашего дистрибутива:

sudo apt-get install sysbench

Этот пакет может тестировать множество показателей производительности, но мы сосредоточены только на тесте памяти. Следующая команда выделяет 1 МБ ОЗУ, затем выполняет операции записи до тех пор, пока не будет записано 10 ГБ данных (не беспокойтесь, для выполнения этого теста не требуется 10 ГБ ОЗУ).

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

Это покажет скорость памяти в миБ / с, а также задержку доступа, связанную с этим.

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

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

Просмотры:
398

Проверка скорости SSD

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

CrystalDiskInfo

Программное обеспечение в свободном доступе, бесплатное. Утилита совместима с операционными системами Windows XP, Vista, Windows 7, 8, 10. Программное обеспечение создано для проверки скорости SSD и её сравнения. Как же провести тест с помощью утилиты CrystalDiskInfo:

1. Закройте все лишние программы, которые могут влиять на чистоту теста на скорость. К таким ПО относятся мессенджеры, торренты, графические редакторы и прочие.
2. Рядом с вкладкой “All” выберите количество циклов чтение/запись, оптимальное количество 3-5 (по умолчанию установлено 5).
3. Выберите объём тестового файла, рекомендуется 1 Гб.
4. Выберите диск теста SSD накопителя (обычно выбирают диск, на котором хранится операционная система).

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

1. Столбец “read” — это данные скорости чтения.
2. Столбец “write” — данные скорости записи.
3. Последовательная скорость чтения/записи при глубине очереди равной 32 (SeqQ32T1).
4. Тест скорости случайного чтения/записи блоков 4 Кб при глубине очереди равной 32 (4KQ32T1).
5. Последовательная скорость чтения/записи (Seg).
6. Скорость случайного чтения/записи блоков 4 Кб при глубине очереди равной 1.

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

AS SSD Benchmark

Бесплатная программа для тестирования SSD с единственным недостатком — не русифицированным меню. Утилита совместима со всеми операционными системами, и как предыдущая программа CrystalDiskInfo, служит для теста скорости чтения-записи, оценки состояния диска. Разница с предыдущей программе лежит в отсутствии таких показателей:

• Отсутствия данных последовательной скорости чтения/записи при глубине очереди равной 32.
• Тест скорости случайного чтения/записи блоков 4 Кб при глубине очереди равной 64 (4K-64Thrd).

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

HD Tune

Возможности программного обеспечения:

• Получения подробных сведений о твердотельном накопителе.
• Проверка текущего состояния SSD диска.
• Сканирование накопителя на ошибки и битые сектора.
• Автоматическое определение температурного режима.
• У версии Pro есть дополнительные тесты для SSD диска.

После установки программы появится окно с 4 вкладками: benchmark, info, health, error scan. Рассмотрим каждую из вкладок, какие данные они предоставляют:

1. Benchmark. Предназначена для проверки скорости SSD. После проведения тестов появятся сведения о таких параметрах: пиковая скорость, самая низкая, максимальная и средний показатель, показатель нагрузки на CPU, интервал времени обращения файлам.
2. В этом окне вы можете ознакомиться с моделью твердотельного накопителя, его серийный номер, объём памяти
3. Health. Само название говорит о том, что в этой вкладке вы можете ознакомиться со “здоровьем” винчестера. Если напротив какого-либо параметра стоит утверждение “OK” значит характеристики отвечают нормальное работе накопителя, если стоит статус “Failed”, значит устройство функционирует некорректно.
4. Error scan. Последняя вкладка помогает находить повреждённые сектора. Для сканирования потребуется немного времени, после чего в окне появится поле с битыми секторами, обозначенными красными квадратами. Для того, чтобы ускорить процесс нахождения повреждённых файлов, рекомендуется снизить нагрузку на ЦПУ, закрыв фоновые программы, а также антивирус, если это возможно.

Утилита CrystalDiskMark

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

Часто для тестирования носителей информации используют утилиту CrystalDiskMark. Именно ее скриншоты выкладывают пользователи после покупки и тестов жестких дисков или SSD.

И что же нам должны сказать цифры с этого скриншота?

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

Фактически о производительности носителей информации делается заключение по скорости последовательных и случайных операций записи/чтения.

На скриншоте мы видим две колонки с результатами — в первой выведены значения тестов на чтение, во второй на запись.

Всего выводятся результаты четырех тестов.

Первый тест — последовательное чтение (запись) данных блоками по 1 МБ в один поток с очередью в 32. Очередь — это количество отложенных операций ввода-вывода. Все эти цифры отражены в названии теста.

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

Однако это далеко не самые важные цифры.

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

Тем не менее подавляющее большинство файловых операций на диске имеют совсем не последовательный, а скорее случайный характер. И именно его мы и можем оценить по четвертому тесту, который демонстрирует скорость передачи данных блоками по 4КБ в один поток и длиной очереди в 1. На практике это как раз и есть те самые обычные файловые операции, которые выполняются на диске операционной системой или запущенными программами.

Четвертый — это, пожалуй, самый важный для нас тест, а вот второй и третий тесты мало информативны для рядового пользователя и на них внимание можно не обращать. Подведу краткий итог

Подведу краткий итог.

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

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

Conclusion

In this tutorial we learned about various Linux tools which can be used to check disk usage by different processes and monitor disk IO Performance. Disk read write plays very important role in how application data is processed between RAM and Disk so it is very important that you have disk with good I/O speed and RPM. I would recommend reading about different available disk types and disk interface types

This would give you an idea on choosing the type of drive which suits your requirement. In production environment we mostly prefer HDD over SSD due to cost and many other factors but for laptops and desktops mostly SSD are used. But now a days even in production environment is starting to move to SSD to support cloud environment.

Lastly I hope the steps from the article to monitor disk IO performance, disk stats and disk IO statistics in Linux was helpful. So, let me know your suggestions and feedback using the comment section.
 

vmstat — Report virtual memory statistics

is another monitoring tool which is part of rpm. It is most likely possible that is installed by default on your Linux node or else you can also install it manually using

# rpm -q procps-ng
procps-ng-3.3.10-23.el7.x86_64

reports information about processes, memory, paging, block IO, traps, disks and cpu activity. Here we will use to monitor disk IO performance in Linux using for 1 second with 1 second interval.

# vmstat -d 1 1
disk- ------------reads------------ ------------writes----------- -----IO------
       total merged sectors      ms  total merged sectors      ms    cur    sec
sda   667530  12447 7660380 2108711 91090178 3458386 12047478760 1506891675      0  11791
dm-0  607338      0 4858728 1760585 206130      0 1649040 5723571      0   1245
dm-1   72135      0 2626562  466444 94344918      0 12045847864 1574232872      0  11050
dm-2   72135      0 2626562  466583 94344918      0 12045847864 1574410699      0  11050
dm-3   72240      0 2630178  905647 94422613      0 12046752440 3064011073      9  12087
dm-4       0      0       0       0      0      0       0       0      0      0

To get summary disk IO statistics about disk activity

# vmstat -D 1 1
            6 disks
            3 partitions
      1492064 total reads
        12447 merged reads
     20407898 read sectors
      5711511 milli reading
    374572389 writes
      3460667 merged writes
  48208708608 written sectors
   7759736862 milli writing
            0 inprogress IO
        47247 milli spent IO

Follow man page of to get the complete list of supported arguments using which you can monitor your system resource.

Результаты тестов

Последовательная нагрузка маленькими блоками 4k

100%_read_4k_sequential

График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_4k_sequential

График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Результаты теста с использованием последовательного характера нагрузки небольшими блоками 4k нас впечатлили, получилось !1,4 миллиона! IOPS на чтение и 700k на запись. Если сравнивать это с предыдущим нашим тестом на ядре 4,19 (371k и 233k IOPS), то это скачек в четыре раза при том, что железо мы не меняли.

Также отмечаем довольно небольшую утилизацию CPU, она примерно на 20% ниже предыдущего теста (69/71% против 76/92%).

Задержки при этом остались на том же уровне, что и полгода назад, это не значит, что с этим мы думаем мириться, это значит, что над этим мы ещё будем работать. В конце статьи, будет итоговая таблица сравнения с тестом полугодовой давности на ядре 4,19.

Случайная нагрузка маленькими блоками 4k

100%_read_4k_random

График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_4k_random

График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Показатели случайной нагрузки маленькими блоками, характерной для транзакционных СУБД остались практически без изменений по сравнению с прошлым тестом. СХД Восток на Эльбрусе вполне нормально справляется с подобными задачами, выдавая 118k IOPS на чтение и 84k IOPS на запись при довольно высокой утилизации CPU.

Отмечаем, что для Эльбруса в отличии от других процессоров работа в режиме постоянной загрузки близкой к 100% является штатной ситуацией (он для этого создавался). Мы это проверяли, оставляя СХД Восток с нагруженным процессором под 95% на несколько дней и результат был следующий: 1) процессор был холодный; 2)процессор и система в целом работали в нормальном режиме. Поэтому к высокому уровню утилизации процессоров Эльбрус следует относиться спокойно.

Также с прошлого ядра сохранилась приятная особенность

Если посмотреть на задержки при случайной нагрузке маленькими блоками, то внимание привлекает то, что задержки на запись ниже, чем на чтение (3 мс против 8 мс), когда мы все привыкли, что должно быть наоборот. Эльбрус с точки зрения случайного характера нагрузки по-прежнему любит запись больше чем чтение, что несомненно является отличным преимуществом, которое грех не использовать

Последовательная нагрузка большими блоками 128k

100%_read_128k_sequential

График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_128k_sequential

График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Ещё полгода назад СХД Восток на базе процессоров Эльбрус показала отличный результат в тесте последовательной нагрузки большими блоками, что актуально для видеонаблюдения или трансляций. Особой фишкой Эльбруса были ультранизкие задержки при работе с большими блоками (0,4-0,5 мс против 5 – 6 мс у аналогичного процессора архитектуры x-86).

При чтении данных большими блоками данное преимущество удалось не только закрепить, но и развить. Максимальную скорость на новом ядре удалось поднять в два раза (5,7 ГБ/с на ядре 5.4 против 2,6 ГБ/с на ядре 4.19) при задержках 0,3 мс! Также нагрузка на процессор при данном тесте тоже выглядит лучше (52% на 5,4 против 75% на 4,19).

А вот с записью не так все радужно. К сожалению, в новой версии ядра получить ультранизкие задержки на запись уже не удается, во всяком случае пока. Они находятся на уровне 11 мс (а было 0,5 мс), что в целом не плохо, т.к. примерно такой же уровень задержек при таком тесте мы видим на процессорах других архитектур. Так или иначе – это наше домашнее задание, над которым мы будем работать. При этом позитивный момент все-таки есть. Как и в других тестах утилизация процессора значительны снижена (74% против 95%).

IOPS в SSD и HDD

Жесткие диски используют стандартное уравнение для определения операций ввода-вывода в секунду, но твердотельные накопители работают иначе. Для жестких дисков IOPS зависит от времени поиска, а твердотельные накопители в первую очередь зависят от внутреннего контроллера устройства. Производительность SSD меняется со временем, достигая пика на ранней стадии. Однако даже после перехода в устойчивое состояние твердотельные накопители по-прежнему превосходят жесткие диски с точки зрения операций ввода-вывода в секунду. Жесткие диски также борются с более высокой задержкой и более длительным временем чтения/записи.

Проверка работоспособности SSD/HDD

Чтобы проверить общее состояние введите команду:

Опишу команды подробнее:

d – Указывает тип устройства.ata – тип устройства ATA, используйте scsi для типа устройства SCSI.H – Проверяет устройство, чтобы сообщить о его состоянии и работоспособности.

Проверка общего состояния

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

Это указывает на неудачное использование и появляется возможность получить дополнительную информацию.

Команда Smartctl – ИНТЕЛЛЕКТУАЛЬНЫЕ атрибуты

Вы можете увидеть следующие атрибуты:

Reallocated Sectors Count – Количество секторов, перераспределенных из-за ошибок чтения.

Reported Uncorrect – Количество неисправимых ошибок при доступе к сектору чтения/записи.

Индикатор износа носителя – Текущее состояние работы диска на основе срока службы.

Если вы видите 100 — это лучшее значение. А если видите — это ХУДШЕЕ значение.

Дополнительные сведения см. в разделе Сведения о интеллектуальных атрибутах.

Чтобы инициировать расширенный тест (long), выполните следующую команду:

Инициирование расширенного теста

Чтобы выполнить самотестирование, введите команду:

Выполнение самотестирования с помощью smartctl

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

результат самотестирования smartctl

Чтобы оценить время выполнения теста, выполните следующую команду.

Расчет времени выполнения теста

Вы можете распечатать журналы ошибок диска с помощью команды:

Печать журналов ошибок диска

Анализ вывода

Во время теста мы видим что-то вроде такого:

Jobs: 2 (f=2):   [13312K/11001K /s] [3250/2686 iops] 

В квадратных скобках — цифры IOPS’ов. Но радоваться рано — ведь нас интересует latency.

На выходе (по Ctrl-C, либо по окончании) мы получим примерно вот такое:

^Cfio: terminating on signal 2

read: (groupid=0, jobs=1): err= 0: pid=11048
  read : io=126480KB, bw=14107KB/s, iops=3526, runt=  8966msec
    slat (usec): min=3, max=432, avg= 6.19, stdev= 6.72
    clat (usec): min=387, max=208677, avg=9063.18, stdev=22736.45
    bw (KB/s) : min=10416, max=18176, per=98.74%, avg=13928.29, stdev=2414.65
  cpu          : usr=1.56%, sys=3.17%, ctx=15636, majf=0, minf=57
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued r/w: total=31620/0, short=0/0
     lat (usec): 500=0.07%, 750=0.99%, 1000=2.76%
     lat (msec): 2=16.55%, 4=35.21%, 10=35.47%, 20=3.68%, 50=0.76%
     lat (msec): 100=0.08%, 250=4.43%
write: (groupid=0, jobs=1): err= 0: pid=11050
  write: io=95280KB, bw=10630KB/s, iops=2657, runt=  8963msec
    slat (usec): min=3, max=907, avg= 7.60, stdev=11.68
    clat (usec): min=589, max=162693, avg=12028.23, stdev=25166.31
    bw (KB/s) : min= 6666, max=14304, per=100.47%, avg=10679.50, stdev=2141.46
  cpu          : usr=0.49%, sys=3.57%, ctx=12075, majf=0, minf=25
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued r/w: total=0/23820, short=0/0
     lat (usec): 750=0.03%, 1000=0.37%
     lat (msec): 2=9.04%, 4=24.53%, 10=49.72%, 20=9.56%, 50=0.82%
     lat (msec): 100=0.07%, 250=5.87%

Нас из этого интересует (в минимальном случае) следующее:read: iops=3526 clat=9063.18 (usec), то есть 9мс.write: iops=2657 clat=12028.23

Не путайте slat и clat. slat — это время отправки запроса (т.е. производительность дискового стека линукса), а clat — это complete latency, то есть та latency, о которой мы говорили. Легко видеть, что чтение явно производительнее записи, да и глубину я указал чрезмерную. 

В том же самом примере я снижаю iodepth до 16/16 и получаю:

read 6548 iops, 2432.79usec = 2.4mswrite 5301 iops, 3005.13usec = 3ms

Очевидно, что глубина в 64 (32+32) оказалась перебором, да таким, что итоговая производительность даже упала. Глубина 32 куда более подходящий вариант для теста.

Итоговые результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8 С, ядро 5.4

Улучшение в 5.4 – зеленые, ухудшения 5.4 – оранжевые

Для сравнения, результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8С, ядро 4.19

Улучшение в 5.4 – зеленые, ухудшения в 5.4 – оранжевые

Прогресс виден не вооруженным глазом! Новая версия ядра 5.4 для архитектуры Эльбрус позволила выжать практические максимумы из совсем не нового процессора Эльбрус 8С (2016 г. выпуска). На данный момент даже у самых ярых пессимистов уже не повернется язык назвать процессор Эльбрус медленным, все – таки полтора миллиона IOPS – это много.

В очередной раз мы убедились в отличной работе СХД на Эльбрусе среде, где преобладает последовательная нагрузка, а это аналитические СУБД, онлайн-трансляции, видеонаблюдение, обработка больших данных и т.п.

Кроме того, Эльбрус отлично себя показывает в случайной нагрузке на запись, показывая минимальные задержки, что актуально для классических транзакционных СУБД.

Безусловно есть ещё над чем работать (те же задержки при записи больших потоков), но за прошедшие полгода коллектив МЦСТ проделал титаническую работу, и она дала видимый результат, что не может не радовать.

В конце этого – 21-ого года мы ожидаем новый процессор Эльбрус 16С, который, кроме того что будет намного быстрее, ещё будет поддерживать аппаратную виртуализацию, а это значит что у нас в России наконец-то появится полностью отечественные не только СХД, но и системы виртуализации, и гиперконвергентные системы (кто сказал АИСТ и vAIR?))).

Кстати о птичках! В течение этой недели мы определимся с датами следующего технического вебинара «ОколоИТ» про нашу систему виртуализации АИСТ и гиперконвергентную систему vAIR, ссылка на регистрацию появится в этой статье (следите за обновлением), а также в нашем телеграмм-чате.

Ну и само собой, не можем не напомнить о бесплатных курсах по системам Аэродиск, на которые можно записаться тут.

На этой позитивной ноте завершаем очередную статью про Эльбрус. Традиционно ждем каверзных вопросов, конструктивных споров и предложений.