Для данного сервера установлен лимит на производительность диска в 300 iops
Несколько способов измерения производительности диска или дискового массива.
тесты на чтение
Запуск: fio read.ini
Содержимое read.ini
Задача подобрать такой iodepth, чтобы avg.latency была меньше 10мс.
Штраф на запись RAID-массива
Наиболее распространенные типы RAID и их штрафы на запись определяются в следующей таблице:
RAID Type | Write Penalty |
---|---|
RAID 1 | 2 |
RAID 5 | 4 |
RAID 6 | 6 |
RAID 10 | 2 |
Чтобы вычислить максимальное значение IOPS записи (maxWriteIops) для заданного RAID-массива, разделим максимальное значение IOPS чтения (maxReadIops) на штраф за запись RAID-массива (raidWritePenalty): maxWriteIops = maxReadIops / raidWritePenalty
Используя наш пример с 4-мя дисками и конфигурацией RAID 10, получаем следующие значения:
Итого, для нашего примера, максимальное значение IOPS на запись для массива RAID 10 - 158.
Последовательный / одновременный ввод / вывод
Концептуально параллельный ввод-вывод означает, что после отправки команды ввода-вывода на один диск, не дожидаясь его ответа, затем отправляются команды ввода-вывода на другой диск. Для чередующегося RAID (LUN) операции ввода-вывода, выполняемые на нем, являются параллельными, например: raid 0 + 1 (1 + 0), raid5 и т. Д. В противном случае это последовательный ввод-вывод.
Чтобы контролировать производительность ввода-вывода на диске, мы можем использовать системные команды AIX, такие как: sar -d, iostat, topas, nmon и т. Д. Ниже я возьму nmon и topas в качестве примеров, чтобы описать, как наблюдать за производительностью дискового ввода-вывода в системе.
Вычисляем минимальное количество дисков для RAID-массива
Как только минимальное количество требуемых IOPS определено, очень легко определить минимальное количество и скорость дисков, необходимых для создания RAID-массива для удовлетворения требований к производительности.
Минимальное количество дисков по скорости диска
Минимальное количество дисков, необходимых для выполнения нашего требования к производительности (minNumDiskMinPerf), рассчитывается следующим образом: minNumDisksMinPerf = minReqdIops / maxIopsByDiskSpeed
Используя информацию из расчета минимально необходимых IOPS выше и предполагая, что мы хотим создать массив из 10 000 RPM-дисков (~125-150 IOPS), вычисление минимального количества дисков, которое будет соответствовать нашим минимальным требованиям к производительности (minNumDisksMinPerf) 1800 IOPS (minReqdIops) выглядит следующим образом:
Минимальное количество дисков 10 000 RPM, необходимых для удовлетворения наших требований к производительности, - 14.
Минимальное количество дисков по типу RAID
Тип RAID определяет минимальное количество дисков для удовлетворения требований типа RAID. Например, для RAID 5 всегда требуется как минимум 3 диска. Для RAID 10 всегда требуется как минимум 4 диска.
Для любых массивов, требующих большого количества дисков, используйте множитель в приведенной ниже таблице, чтобы определить правильное количество дисков для соответствия требованиям типа RAID:
Тип RAID | Количество дисков | RAID множитель |
---|---|---|
RAID5 | 3 | N/A |
RAID10 | 4 | 4 |
После вычисления количества дисков по скорости, определяем минимальное количество дисков, требуемых по типу RAID.
В примере, когда 10K RPM-диски были выбраны для построения массива, расчет показывает, что требуется не менее 14 дисков. Если тип RAID будет 5, 14 дисков будет достаточным. Однако, если тип RAID будет равен 10, минимальное количество дисков, требуемых этим типом RAID, будет 8, поскольку множитель для RAID 10 равен 4.
Гибридные тесты
самая вкусная часть:
(внимание! Ошибётесь буквой диска — останетесь без данных)
Во время теста мы видим что-то вроде такого:
В квадратных скобках — цифры IOPS'ов. Но радоваться рано — ведь нас интересует latency.
На выходе (по Ctrl-C, либо по окончании) мы получим примерно вот такое:
^C
fio: terminating on signal 2
Нас из этого интересует (в минимальном случае) следующее:
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.4ms
write 5301 iops, 3005.13usec = 3ms
Очевидно, что глубина в 64 (32+32) оказалась перебором, да таким, что итоговая производительность даже упала. Глубина 32 куда более подходящий вариант для теста.
IOPS используется для определения производительности диска или дискового массива.
IOPS означает Input/Output (operations) Per Second , количество “операций ввода/вывода в секунду”. Величина измеряет объем работы за определенный промежуток времени. По сути, IOPS это количество блоков, которое успевает считаться или записаться на носитель. Чем больше размер блока, тем меньше кусков, из которых состоит файл, и тем меньше будет IOPS, так как на чтение куска большего размера будет затрачиваться больше времени.
“Операция ввода/вывода” - это просто некая часть работы дисковой подсистемы, которая совершается в ответ на запрос хост-сервера и/или некоторых внутренних процессов. Обычно это чтение или запись с различными подкатегориями, например “чтение” (read), “повторное чтение” (re-read), “запись”(write), “перезапись” (re-write), “произвольный тип доступа” (random), “последовательный тип доступа” (sequential) и размер оперируемого блока данных.
Основными измеряемыми величинами являются операции линейного (последовательного) и произвольного (случайного) доступа.
Под линейными операциям чтения/записи, при которых части файлов считываются последовательно, одна за другой, подразумевается передача больших файлов (более 128 К). При произвольных операциях данные читаются случайно из разных областей носителя, обычно они ассоциируются с размером блока 4 Кбайт.
В зависимости от вида операции, этот размер может варьироваться от байт до килобайт и даже нескольких мегабайт. Существует множество типов ввода/вывода и многозадачная и многохостовая система почти никогда не использует какой-то один. Виртуализация только добавляет разнообразия к паттернам ввода/вывода.
Никакая система хранения не может показывать максимальные значения IOPS безотносительно к характеру операций ввода/вывода, значений latency и размеру блоков.
Latency это мера того, сколько времени занимает выполнение одного запроса ввода/вывода, с точки зрения приложения.
Значительные объемы I/O wait это признак того, что источник проблем - хранилище (существуют и другие источники задержек, CPU и сеть - это обычные примеры). Даже в случае хороших показателей latency, если вы видите большое количество I/O waits - это значит, что приложение хотело бы больше скорости от системы хранения.
Определение производительности дисковой системы - это часто игнорируемый аспект проектирования систем. Поскольку дисковая система является самой медленной средой на компьютере, она должна быть одной из ПЕРВЫХ компонентов, спецификация которых правильно определена.
Приложения которые интенсивно используют операции на запись являются хорошими кандидатами для RAID 10, тогда как приложения которые интенсивно используют операции на чтение могут быть размещены на RAID 5.
IOPS используются для определения производительности диска или дискового массива. Для примера можно считать, что максимальный IOPS для диска:
ПРИМЕЧАНИЕ. Для расчета фактического IOPS для диска требуется следующая информация: Average latency , Average seek time . Эту информацию можно получить от производителя
Непрерывный / случайный ввод / вывод
Непрерывный ввод-вывод означает, что адрес начального сектора, заданный этим вводом-выводом, и адрес конечного сектора предыдущего ввода-вывода полностью непрерывны или не сильно различаются. И наоборот, если разница большая, она считается случайным вводом-выводом.
Причина, по которой непрерывный ввод-вывод более эффективен, чем случайный ввод-вывод, заключается в следующем: при выполнении непрерывного ввода-вывода головке вряд ли нужно менять полосу, или время для смены полосы очень короткое; для случайного ввода-вывода, если этот ввод-вывод Во многих случаях это приводит к тому, что голова постоянно меняет полосу движения, что приводит к значительному снижению эффективности.
Вычислим максимальный IOPS для диска
Для примера возьмем диск: Seagate ST500DM002-1BC142
Чтобы вычислить IOPS используем уравнение:
Итого, максимальный IOPS - 79.
Измерение случайных IOPS с помощью FIO
FIO - популярный инструмент для измерения IOPS на сервере Linux.
Достаточно гибкий и простой инструмент в пользовании.
В статье будет рассмотрено несколько вариантов проверки, а именно случайное чтение, случайная запись и их комбинация блоками по 4Кб с многопоточностью.
Установка в CentOS/RHEL
Установка в Debian/Ubuntu
Тест случайных операций на чтение/запись
Данный тест создаст файл размером 4Гб и выполнит чтение и запись 4Кб с использованием разделения 75%/25% в файле, причем одновременно будет выполняться 64 операции. На каждые 3 операции чтения - одна операция на запись.
Результат выполнения команды будет приблизительно следующим:
Исходя из полученной информации делаем вывод, что наш диск в среднем выполняет 32115 операций на чтение и 10709 на запись. (Соотношение 3/1)
Тест случайных операций на чтение
Для измерения количества случайных операций на чтение выполняем следующую команду:
Результат выполнения команды будет приблизительно следующим:
Результаты теста показывают 55763 операций чтения в секунду, что очень хорошо для локального SSD.
Тест случайных операций на запись
Для измерения количества случайных операций на запись выполняем следующую команду:
Результат выполнения команды будет приблизительно следующим:
Результаты теста показывают 28660 операций на запись в секунду.
Последним аспектом оценки производительности диска является измерение задержки по отдельным запросам. Один из способов выяснить это - воспользоваться утилитой ioping.
Среднее значение задержки 138.8 us (микросекунд), что в целом очень хорошо! Если данный параметр будет превышать несколько миллисекунд, то с диском или дисковым массивом наблюдаются проблемы. Необходимо провести диагностику и найти “узкое место”, либо источник проблемы.
Большой / малый блочный ввод / вывод
Это значение относится к количеству последовательных секторов чтения, заданных в команде контроллера. Если число велико, например, 64, 128 и т. Д., Мы можем рассматривать его как большой блок ввода-вывода; наоборот, если оно маленькое, например 4, 8, мы будем рассматривать его как небольшой блок ввода-вывода. Фактически, в большом блоке и Нет четкой границы между малым вводом-выводом.
Максимальное значение IOPS для чтения
Вычисление максимального значения IOPS чтения (maxReadIops) для RAID-массива:
maxReadIops = numDisks * diskMaxIops
Соответственно для массива из 4 дисков максимальное значение IOPS чтения будет следующим:
Индекс оценки производительности диска - IOPS и пропускная способность
Понятие ввода-вывода в буквальном смысле означает ввод и вывод. Операционная система переходит с верхнего уровня на нижний, и между каждым уровнем есть операции ввода-вывода. Например, у ЦП есть ввод-вывод, у памяти есть ввод-вывод, у VMM есть ввод-вывод, а у нижележащего диска также есть ввод-вывод. Это ввод-вывод в широком смысле. Вообще говоря, ввод-вывод верхнего уровня может генерировать несколько операций ввода-вывода для дисков, то есть ввод-вывод верхнего уровня является разреженным, а ввод-вывод нижнего уровня Он плотный.
Рис. 1. Архитектура физического диска и распространенные типы дисков.
SAN (сеть хранения данных, сеть хранения данных) И NAS-хранилище (сетевое хранилище) обычно имеют два оценочных показателя: IOPS И пропускная способность (пропускная способность) - два показателя независимы и взаимосвязаны. Самый важный показатель, отражающий производительность системы хранения, - это IOPS . Далее я объясню значение этих двух параметров.
IOPS (Input / Output Per Second) - это количество входных и выходных данных (или количество операций чтения и записи) в секунду, и это один из основных показателей для измерения производительности диска. IOPS относится к количеству запросов ввода-вывода, которые система может обработать за единицу времени. Запросы ввода-вывода обычно представляют собой запросы на операции чтения или записи данных. Для приложений с частым случайным чтением и записью, таких как OLTP (обработка онлайн-транзакций), IOPS является ключевым показателем. Еще один важный показатель - это пропускная способность данных (Throughput), которая относится к количеству данных, которые могут быть успешно переданы за единицу времени. Для большого количества приложений последовательного чтения и записи, таких как VOD (Video On Demand), больше внимания уделяется показателям пропускной способности.
IOPS диска - это количество операций ввода-вывода, операций чтения и записи, выполненных диском за одну секунду.
Пропускная способность диска, то есть трафик ввода-вывода диска в секунду, то есть размер операций записи на диск плюс данные чтения.
Связь между IOPS и пропускной способностью
Пропускная способность ввода-вывода в секунду = IOPS * средний РАЗМЕР ввода-вывода. Это можно увидеть из формулы: чем больше РАЗМЕР В / В, тем выше IOPS и тем выше пропускная способность ввода / вывода в секунду. Следовательно, мы думаем, что чем выше IOPS и пропускная способность, тем лучше. Фактически для диска эти два параметра имеют свои максимальные значения, и между этими двумя параметрами существует определенная взаимосвязь.
IOPSЕго можно разбить на следующие показатели:
- Toatal IOPS, дисковый IOPS при смешанной загрузке чтения-записи и последовательной произвольной нагрузке ввода-вывода, это наиболее соответствует реальной ситуации ввода-вывода, и большинство приложений обращают внимание на этот показатель.
- IOPS при произвольном чтении, IOPS при 100% произвольной нагрузке чтения.
- IOPS при произвольной записи, IOPS при 100% произвольной загрузке записи.
- IOPS при последовательном чтении, 100% IOPS при последовательном чтении под нагрузкой.
- Последовательная запись IOPS, IOPS при 100% загрузке последовательной записи.
На следующем рисунке показан типичный результат теста NFS:
Инструменты тестирования производительности IOPS в основном включают Iometer , IoZone, FIO и т. д. можно использовать для проверки IOPS диска в различных ситуациях. Для прикладной системы необходимо сначала определить нагрузочные характеристики данных, а затем выбрать разумный индекс IOPS для измерения и сравнительного анализа, а затем выбрать соответствующий носитель и программную систему соответственно.
Формула расчета IOPS
Для диска полная операция ввода-вывода выполняется следующим образом: когда контроллер отправляет команду операции ввода-вывода на диск, рычаг привода диска с головкой чтения-записи (головкой) покидает Зону посадки и находится в (Область без данных во внутреннем круге), переместитесь чуть выше дорожки (Track), где находится начальный блок данных, который будет использоваться. Этот процесс называется поиском, а соответствующее затраченное время называется временем поиска. ); Однако данные не могут быть прочитаны сразу после нахождения соответствующей дорожки. В это время головка должна ждать, пока дисковая пластина (Platter) не повернется в сектор, где начальный блок данных (Sector) расположен непосредственно над головкой чтения / записи, прежде чем читать данные , Время, затрачиваемое на ожидание поворота диска в рабочий сектор, называется задержкой вращения (задержка вращения ); затем, когда диск вращается, головка продолжает Чтение / запись соответствующего блока данных до завершения всех данных, необходимых для этой операции ввода-вывода.Этот процесс называется передачей данных, а соответствующее время называется временем передачи. После выполнения этих трех шагов операция ввода-вывода завершается.
Когда мы смотрим на листовки производителей жестких дисков, мы часто видим 3 параметра, а именно среднее время адресации, скорость вращения диска и максимальную скорость передачи.Эти три параметра могут предоставить нам расчет трех вышеуказанных шагов. время.
ПервыйВремя адресаУчитывая, что данные, которые должны быть прочитаны и записаны, могут находиться на любой дорожке диска, они могут находиться в самом внутреннем круге диска (самое короткое время адресации) или в самом внешнем круге диска (самое длинное время адресации), поэтому В расчетах мы учитываем только среднее время адресации, то есть среднее время адресации, указанное в параметрах диска. Здесь используется текущий максимальный жесткий диск 10krmp 5 мс.
секундаЗадержка отжимаКак и при адресации, когда головка расположена на дорожке, она может находиться чуть выше сектора для чтения и записи. В это время данные могут быть прочитаны и записаны немедленно без дополнительной задержки, но в худшем случае требуется, чтобы диск вращался. Головка может считывать данные после полного оборота, поэтому здесь мы также учитываем среднюю задержку вращения, которая составляет (60 с / 10 кОм) * (1/2) = 2 мс для диска со скоростью 10 об / мин.
ТретийСрок поставкиПараметры диска обеспечивают максимальную скорость передачи данных. Конечно, достичь этой скорости очень сложно, но эта скорость - это скорость диска, считывающего и записывающего данные на диск, поэтому, если задан размер одного ввода-вывода, мы знаем Сколько времени диск должен потратить на передачу данных, на этот раз - размер блока ввода-вывода / максимальная скорость передачи.
Теперь мы можем получить такую формулу для расчета времени одиночного ввода-вывода.
IO Time = Seek Time + 60 sec/Rotational Speed/2 + IO Chunk Size/Transfer Rate
Таким образом, мы можем рассчитать IOPS следующим образом.
IOPS = 1/IO Time = 1/(Seek Time + 60 sec/Rotational Speed/2 + IO Chunk Size/Transfer Rate)
Для заданного другого размера ввода-вывода мы можем получить следующую серию данных
4K (1/7.1 ms = 140 IOPS)
5ms + (60sec/15000RPM/2) + 4K/40MB = 5 + 2 + 0.1 = 7.1
8k (1/7.2 ms = 139 IOPS)
5ms + (60sec/15000RPM/2) + 8K/40MB = 5 + 2 + 0.2 = 7.2
16K (1/7.4 ms = 135 IOPS)
5ms + (60sec/15000RPM/2) + 16K/40MB = 5 + 2 + 0.4 = 7.4
32K (1/7.8 ms = 128 IOPS)
5ms + (60sec/15000RPM/2) + 32K/40MB = 5 + 2 + 0.8 = 7.8
64K (1/8.6 ms = 116 IOPS)
5ms + (60sec/15000RPM/2) + 64K/40MB = 5 + 2 + 1.6 = 8.6
Из приведенных выше данных видно, что, когда одиночный ввод-вывод меньше, время, потребляемое одним вводом-выводом, также меньше, и соответствующее число операций ввода-вывода в секунду также больше.
Все наши данные, приведенные выше, основаны на идеальном предположении. Идеальная ситуация здесь состоит в том, что диск требует среднего времени адресации и средней задержки вращения. Это предположение на самом деле больше соответствует нашей реальной ситуации. Произвольное чтение и запись. При произвольном чтении и записи нельзя игнорировать время адресации и задержку ротации каждой операции ввода-вывода. Существование этих двух времен также ограничивает размер IOPS. Теперь мы рассмотрим относительно экстремальную последовательную операцию чтения и записи, например, при чтении большого файла, который хранится непрерывно распределенным на диске, потому что распределение хранилища файла является непрерывным после того, как головка завершает операцию чтения ввода-вывода, Нет необходимости в переадресации или задержке вращения.В этом случае мы можем получить большое значение IOPS следующим образом.
4K (1/0.1 ms = 10000 IOPS)
0ms + 0ms + 4K/40MB = 0.1
8k (1/0.2 ms = 5000 IOPS)
0ms + 0ms + 8K/40MB = 0.2
16K (1/0.4 ms = 2500 IOPS)
0ms + 0ms + 16K/40MB = 0.4
32K (1/0.8 ms = 1250 IOPS)
0ms + 0ms + 32K/40MB = 0.8
64K (1/1.6 ms = 625 IOPS)
0ms + 0ms + 64K/40MB = 1.6
По сравнению с первым набором данных разрыв очень велик, поэтому, когда мы хотим использовать IOPS для измерения производительности системы ввода-вывода, мы должны прояснить, что такое IOPS, то есть, чтобы объяснить чтение и запись. Способ и размер одиночного ввода-вывода, конечно, на практике, особенно в системах OLTP, случайное чтение и запись небольших операций ввода-вывода наиболее убедительны.
Программы для измерения IOPS
IOmeter — тест IOPS
IOzone — тест IOPS
FIO — тест IOPS
CrystalDiskMark — тест IOPS
SQLIO — набор тестов для расчета производительности (IOPS, MB, Latency) под сервера БД
wmarow — калькулятор RAID по производительности IOPS
topas
Войдите в операционную систему AIX, введите topas и нажмите D, появится следующий интерфейс:
На приведенном выше рисунке TPS - это количество операций ввода-вывода в секунду для диска, а KBPS - это пропускная способность диска в секунду. Поскольку сервер простаивает, мы видим, что данные IOPS и KBPS очень низкие.
Мы используем команду dd if для отправки операций ввода-вывода для чтения на диск hdisk2, размер блока составляет 1 МБ:
Используйте topas для мониторинга:
В настоящее время пропускная способность hdisk2 составляет 163,9 МБ, а количество операций ввода-вывода в секунду - 655.
Запустим еще один dd, если довести занятость жесткого диска до 100%:
Как видно из приведенного выше рисунка, когда диск загружен на 100%, его пропускная способность составляет 304,1 МБ, а IOPS - 1200.
hdisk2 - это локально интегрированный диск SAS. Мы можем выяснить, что пропускная способность локально интегрированного канала SAS составляет 3 Гб:
Для канала SAS 3 Гбит / с пропускная способность диска 304,1 МБ уже близка к пику пропускной способности ввода-вывода.
Следует отметить, что можно использовать dd, если для измерения пропускной способности диска, но ненаучно определять IOPS и пропускную способность бизнес-ввода / вывода на основе этого. Поскольку чтение и запись, инициируемые dd if, представляют собой только последовательные операции ввода-вывода, чтение и запись. В OLTP-бизнесе такие операции чтения и записи не распространены, но случайные небольшие операции ввода-вывода являются относительно большими. Производительность / O необходимо контролировать во время ведения бизнеса.
Введите nmon в систему и нажмите d, чтобы получить следующий интерфейс:
Можно получить, что пропускная способность диска hdisk2 в настоящее время составляет 318 МБ.
Используйте nmon для сбора данных за определенный период времени, а затем используйте анализатор nmon для анализа, вы можете получить более прямой график:
Воспользуйтесь анализатором nmon, чтобы проанализировать собранные файлы nmon и получить следующий отчет:
Рис. 2. диаграмма nmon, показывающая производительность диска
Проектирование для производительности
Простое вычисление максимального количества IOPS для чтения и записи для существующего или будущего RAID-массива недостаточно. Для обеспечения последовательной и устойчивой производительности необходимо определить требования к производительности для системы, чтобы определить лучшее решение для диска. Минимальный требуемый IOPS должен быть определен таким образом, чтобы можно было приобрести необходимое количество дисков с требуемой скоростью.
Для начала необходимо знать требования к производительности (например, чтение и запись IOPS) для данной системы или приложения. Эта информация может быть получена из документации поставщика или программного обеспечения.
Тесты на запись
(внимание! Ошибётесь буквой диска — останетесь без данных)
Вычисляем максимальное значение IOPS для дискового массива
В примечании к разработке системы хранения, вычисление производительности дисковой системы имеет решающее значение для работы данной системы. Большинство систем используют RAID для обеспечения избыточности хранилища. В этом разделе описывается, как вычисляются IOPS для RAID-массивов.
Максимальное значение IOPS для записи
Вычисление максимального значения IOPS записи (maxWriteIops) - это совсем другое в отношении RAID-массивов. RAID-массивы имеют штраф на запись, а тип RAID-массива определяет серьёзность штрафа. Этот штраф является результатом избыточности, которую предоставляет RAID, поскольку массив обязательно должен записывать данные на несколько дисков/локаций для обеспечения целостности данных.
Убедитесь, что дисковый ввод-вывод имеет проблемы с производительностью
Для случайных нагрузок, когда встречаются остальные условия, мы обычно думаем, что существует проблема производительности ввода-вывода:
1. Среднее время чтения превышает 15 мс.
2. С кешем записи среднее время записи превышает 2,5 мс.
Для последовательных загрузок мы обычно думаем, что существует проблема с производительностью ввода-вывода при обнаружении остальных условий:
1. На диске два последовательных потока ввода-вывода.
2. Недостаточная пропускная способность (то есть намного меньше пропускной способности дискового ввода-вывода).
Для диска по мере увеличения количества операций ввода-вывода в секунду увеличивается количество операций ввода-вывода, и наступает точка насыщения, то есть после того, как количество операций ввода-вывода в секунду достигнет определенной точки, увеличение числа операций ввода-вывода в секунду приведет к значительному увеличению времени обслуживания ввода-вывода. .
Рисунок 3. Связь между дисковым IOPS и временем обслуживания IO.
Исходя из опыта, в нашей работе по тестированию мы в основном сосредотачиваемся на трех значениях IOPS и пропускной способности, а также на% занятости диска. Если и IOPS, и пропускная способность очень низкие, а процент занятости диска также очень низок, мы будем думать, что давление на диск слишком мало, что приводит к слишком низкой пропускной способности и IOPS; только когда IOPS и пропускная способность очень низкие, процент занятости диска очень высок ( При приближении к 100%) мы проанализируем производительность ввода-вывода с точки зрения дискового ввода-вывода.
Кроме того, для одного и того же диска (или LUN), поскольку размер данных, считываемых и записываемых каждым вводом-выводом, различен, значение IOPS не является фиксированным. Например, каждая запись или чтение ввода-вывода представляет собой непрерывный большой блок данных, и IOPS в это время будет относительно низким; в случае нечастой смены полосы движения каждый раз записываемый или читаемый блок данных будет небольшим. Условно говоря, IOPS будет выше. Другими словами, количество операций ввода-вывода в секунду также зависит от размера блока ввода-вывода, а значения операций ввода-вывода, измеренные с разными размерами блоков ввода-вывода, отличаются. Для определенного количества операций ввода-вывода в секунду вы можете узнать размер блока ввода-вывода, который он тестировал в то время. И у IOPS есть предельное значение, В таблице 1 перечислены предельные значения IOPS для различных дисков.
Таблица 1. Общие типы дисков и их количество операций ввода-вывода в секунду
Вообще говоря, типы ввода-вывода можно разделить на: ввод-вывод для чтения / записи, ввод-вывод больших / малых блоков, непрерывный / случайный ввод-вывод, последовательный / параллельный ввод-вывод. Среди этих типов мы в основном обсуждаем: ввод-вывод больших / малых блоков, непрерывный / случайный ввод-вывод, последовательный / параллельный ввод-вывод.
Измерение IOPS с помощью CrystalDiskMark в Windows
CrystalDiskMark - небольшая бесплатная программа, предназначенная для сравнительного тестирования быстродействия жестких дисков. Позволяет измерить скорость чтения и записи данных.
Загружаем и запускаем утилиту:
В программе представлено несколько тестов:
- Sequential Tests (последовательная запись и чтение)
- 4K Q8T8 (случайное чтение/запись блоков по 4Kб с глубиной 8 в 8 поток)
- 4K Q1T1 (случайное чтение/запись блоков по 4Kб с глубиной 1 в 1 поток)
- 4K QD32T1 (случайное чтение/запись блоков по 4Kб с глубиной 32 в 1 поток)
Запустим выполнение всех тестов и посмотрим на результат.
Посмотрим среднее количество IOPS на примере теста 4K Q8T8, для этого наведите курсор на значение и во всплывающей подсказке будет отображено количество IOPS.
IOPS (количество операций ввода/вывода – от англ. Input/Output Operations Per Second) – один из ключевых параметров при измерении производительности систем хранения данных, жестких дисков (НЖМД), твердотельных диски (SSD) и сетевых хранилища данных (SAN).
По сути, IOPS это количество блоков, которое успевает считаться или записаться на носитель. Чем больше размер блока, тем меньше кусков, из которых состоит файл, и тем меньше будет IOPS, так как на чтение куска большего размера будет затрачиваться больше времени.
Значит, для определения IOPS надо знать скорость и размер блока при операции чтения / записи. Параметр IOPS равен скорости, деленной на размер блока при выполнении операции.
Характеристики производительности
Основными измеряемыми величинами являются операции линейного (последовательного) и произвольного (случайного) доступа.
Под линейными операциям чтения/записи, при которых части файлов считываются последовательно, одна за другой, подразумевается передача больших файлов (более 128 К). При произвольных операциях данные читаются случайно из разных областей носителя, обычно они ассоциируются с размером блока 4 Кбайт.
Ниже приведены основные характеристики:
Параметр | Описание |
Всего IOPS (Total IOPS) | Суммарное число операций ввода/вывода в секунду (при выполнении как чтения, так и записи) |
IOPS произвольного чтения (Random Read) | Среднее число операций произвольного чтения в секунду |
IOPS произвольной записи (Random Write) | Среднее число операций произвольной записи в секунду |
IOPS последовательного чтения (Sequential Read) | Среднее число операций линейного чтения в секунду |
IOPS последовательной записи (Sequential Write) | Среднее число операций линейной записи в секунду |
Приблизительные значения IOPS
Приблизительные значения IOPS для жестких дисков.
Устройство | Тип | IOPS | Интерфейс |
7,200 об/мин SATA-диски | HDD | ~75-100 IOPS | SATA 3 Гбит/с |
10,000 об/мин SATA-диски | HDD | ~125-150 IOPS | SATA 3 Гбит/с |
10,000 об/мин SAS-диски | HDD | ~140 IOPS | SAS |
15,000 об/мин SAS-диски | HDD | ~175-210 IOPS | SAS |
Приблизительные значения IOPS для SSD.
Устройство | Тип | IOPS | Интерфейс |
Intel X25-M G2 MLC | SSD | ~8 600 IOPS | SATA 3 Гбит/с |
OCZ Vertex 3 | SSD | ~60 000 IOPS (Произвольная запись 4K) | SATA 6 Гбит/с |
OCZ RevoDrive 3 X2 | SSD | ~200 000 IOPS (Произвольная запись 4K) | PCIe |
OCZ Z-Drive R4 CloudServ | SSD | ~1 400 000 IOPS | PCIe |
RAID пенальти
Любые операции чтения, которые выполняются на дисках, не подвергаются никакому пенальти, поскольку все диски могут использоваться для операций чтения. Но всё на оборот с операциями на запись. Количество пенальти на запись зависят от типа выбранного RAID-а, например.
В RAID 1 чтобы данные записались на диск, происходит две операции на запись (по одной записи на каждый диск), и следовательно RAID 1 имеет два пенальти.
В RAID 5 чтобы записать данные происходит 4 операции (Чтение существующих данных, четность RAID, Запись новых данных, Запись новой четности) тем самым пенальти в RAID 5 составляет 4.
В этой таблице приведено значение пенальти для более часто используемых RAID конфигурации.
RAID | I/O Пенальти |
RAID 0 | 1 (Edited by Reader) |
RAID 1 | 2 |
RAID 5 | 4 |
RAID 6 | 6 |
RAID 10 | 2 |
Характеристика рабочих нагрузок
Характеристика рабочей нагрузки в основном рассматривается как процент операции чтений и записей, которые вырабатывает или требует приложение. Например, в среде VDI процентное соотношение IOPS рассматривается как 80-90% на запись и 10-20% на чтение. Понимание характеристики рабочей нагрузки является наиболее критическим фактором, поскольку от этого и зависит выбор оптимального RAID для среды. Приложения которые интенсивно используют операции на запись являются хорошими кандидатами для RAID 10, тогда как приложения которые интенсивно используют операции на чтение могут быть размещены на RAID 5.
Вычисление IOPS
Есть два сценария вычисления IOPS-ов.
Один из сценариев это когда есть определенное число дисков, и мы хотим знать, сколько IOPS эти диски выдадут?
Второй сценарий, когда мы знаем сколько нам IOPS-ов надо, и хотим вычислить нужное количество дисков?
Сценарий 1: Вычисление IOPS исходя из определенного кол-ва дисков
Представим что у нас есть 20 450GB 15к RPM дисков. Рассмотрим два сценария Рабочей нагрузки 80%Write-20%Read и другой сценарий с 20%Write-80%Read. Также мы вычислим количество IOPS как для RAID5 и RAID 10.
Формула для расчета IOPS:
Total Raw IOPS = Disk Speed IOPS * Number of disks
Functional IOPS =(((Total Raw IOPS×Write %))/(RAID Penalty))+(Total Raw IOPS×Read %)
Есть определение Raw IOPS и Functional IOPS, как раз токи Functional IOPS-ы и есть те IOPS-ы которые включают в себя RAID пенальти, и это и есть “настоявшие” IOPS-ы.
А теперь подставим цифры и посмотрим что получится.
Total Raw IOPS = 170*20 = 3400 IOPS (один 15K RPM диск может выдать в среднем 170 IOPS)
Для RAID-5
Вариант 1 (80%Write 20%Read) Functional IOPS = (((3400*0.8))/(4))+(3400*0.2) = 1360 IOPS
Вариант 2 (20%Write 80%Read) Functional IOPS = (((3400*0.2))/(4))+(3400*0.8) = 2890 IOPS
Для RAID-1
Вариант 1 (80%Write 20%Read) Functional IOPS = (((3400*0.8))/(2))+(3400*0.2) = 2040 IOPS
Вариант 2 (20%Write 80%Read) Functional IOPS = (((3400*0.2))/(2))+(3400*0.8) = 3100 IOPS
Сценарий 2: Подсчет кол-ва дисков для достижения определенного кол-ва IOPS
Рассмотрим ситуацию где нам надо определить тип RAID-а и количества дисков для достижения определенного количества IOPS-ов 5000 и с определенными рабочими нагрузками, например 80%Write20%Read и 20%Write80% Read.
Опять же для начала формула по которой и будем считать:
Total number of Disks required = ((Total Read IOPS + (Total Write IOPS*RAID Penalty))/Disk Speed IOPS)
Total IOPS = 5000
Теперь подставим цифры.
Заметка: 80% от 5000 IOPS = 4000 IOPS и 20% от 5000 IOPS = 1000 IOPS с этими цифрами и будем оперировать.
Для RAID-5
Вариант 1 (80%Write20%Read) – Total Number of disks required = ((1000+(4000*4))/170) = 100 дисков.
Вариант 2 (20%Write80%Read) – Total Number of disks required = ((4000+(1000*4))/170) = 47 дисков приблизительно.
Для RAID-1
Вариант 1 (80%Write20%Read) – Total Number of disks required = ((1000+(4000*2))/170) = 53 диска приблизительно.
Вариант 2 (20%Write80%Read) – Total Number of disks required = ((4000+(1000*2))/170) = 35 дисков приблизительно.
Понимание и подсчет IOPS, RAID пенальти, и характеристик рабочих нагрузок очень критичны аспект при планировании. Когда нагрузка более интенсивна на запись луче выбирать RAID 10 и наоборот при нагрузках на чтение RAID 5.
Программы для измерения IOPS
IOmeter — тест IOPS
IOzone — тест IOPS
FIO — тест IOPS
CrystalDiskMark — тест IOPS
SQLIO — набор тестов для расчета производительности (IOPS, MB, Latency) под сервера БД
wmarow — калькулятор RAID групп по производительности IOPS
abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.
Предупреждение: много букв, долго читать.
- научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
- использование bonnie++
- использование iozone
- использование пачки cp с измерениема времени выполнения
- использование iometer с dynamo на 64-битных системах
Это всё совершенно ошибочные методы. Дальше я разберу более тонкие ошибки измерения, но в отношении этих тестов могу сказать только одно — выкиньте и не используйте.
bonnie++ и iozone меряют скорость файловой системы. Которая зависит от кеша, задумчивости ядра, удачности расположения FS на диске и т.д. Косвенно можно сказать, что если в iozone получились хорошие результаты, то это либо хороший кеш, либо дурацкий набор параметров, либо действительно быстрый диск (угадайте, какой из вариантов достался вам). bonnie++ вообще сфокусирована на операциях открытия/закрытия файлов. т.е. производительность диска она особо не тестирует.
dd без опции direct показывает лишь скорость кеша — не более. В некоторых конфигурациях вы можете получать линейную скорость без кеша выше, чем с кешем. В некоторых вы будете получать сотни мегабайт в секунду, при линейной производительности в единицы мегабайт.
С опцией же direct (iflag=direct для чтения, oflag=direct для записи) dd проверяет лишь линейную скорость. Которая совершенно не равна ни максимальной скорости (если мы про рейд на много дисков, то рейд в несколько потоков может отдавать большую скорость, чем в один), ни реальной производительности.
IOmeter — лучше всего перечисленного, но у него есть проблемы при работе в linux. 64-битная версия неправильно рассчитывает тип нагрузки и показывает заниженные результаты (для тех, кто не верит — запустите его на ramdisk).
Спойлер: правильная утилита для linux — fio. Но она требует очень вдумчивого составления теста и ещё более вдумчивого анализа результатов. Всё, что ниже — как раз подготовка теории и практические замечания по работе с fio.
(текущая VS максимальная производительность)
Сейчас будет ещё больше скучных букв. Если кого-то интересует количество попугаев на его любимой SSD'шке, ноутбучном винте и т.д. — см рецепты в конце статьи.
Все современные носители, кроме ramdisk'ов, крайне негативно относятся к случайным операциям записи. Для HDD нет разницы запись или чтение, важно, что головки гонять по диску. Для SSD же случайная операция чтения ерунда, а вот запись малым блоком приводит к copy-on-write. Минимальный размер записи — 1-2 Мб, пишут 4кб. Нужно прочитать 2Мб, заменить в них 4кб и записать обратно. В результате в SSD'шку уходит, например, 400 запросов в секундну на запись 4кб которые превращаются в чтение 800 Мб/с (. ) и записи их обратно. (Для ramdisk'а такая проблема могла бы быть тоже, но интрига в том, что размер «минимального блока» для DDR составляет около 128 байт, а блоки в тестах обычно 4кб, так что гранулярность DDR в тестах дисковой производительности оперативной памяти не важна).
Этот пост не про специфику разных носителей, так что возвращаемся к общей проблеме.
Мы не можем мерять запись в Мб/с. Важным является сколько перемещений головки было, и сколько случайных блоков мы потревожили на SSD. Т.е. счёт идёт на количество IO operation, а величина IO/s называется IOPS. Таким образом, когда мы меряем случайную нагрузку, мы говорим про IOPS (иногда wIOPS, rIOPS, на запись и чтение соотв.). В крупных системах используют величину kIOPS, (внимание, всегда и везде, никаких 1024) 1kIOPS = 1000 IOPS.
И вот тут многие попадают в ловушку первого рода. Они хотят знать, «сколько IOPS'ов» выдаёт диск. Или полка дисков. Или 200 серверных шкафов, набитые дисками под самые крышки.
Тут важно различать число выполненных операций (зафиксировано, что с 12:00:15 до 12:00:16 было выполнено 245790 дисковых операций — т.е. нагрузка составила 245kIOPS) и то, сколько система может выполнить операций максимум.
Число выполненых операций всегда известно и легко измерить. Но когда мы говорим про дисковую операцию, мы говорим про неё в будущем времени. «сколько операций может выполнить система?» — «каких операций?». Разные операции дают разную нагрузку на СХД. Например, если кто-то пишет случайными блоками по 1Мб, то он получит много меньше iops, чем если он будет читать последовательно блоками по 4кб.
И если в случае пришедшей нагрузки мы говорим о том, сколько было обслужено запросов «какие пришли, такие и обслужили», то в случае планирования, мы хотим знать, какие именно iops'ы будут.
Драма состоит в том, что никто не знает, какие именно запросы придут. Маленькие? Большие? Подряд? В разнобой? Будут они прочитаны из кеша или придётся идти на самое медленное место и выковыривать байтики с разных половинок диска?
- Тест диска (СХД/массива) на best case (попадание в кеш, последовательные операции)
- Тест диска на worst case. Чаще всего такие тесты планируются с знанием устройства диска. «У него кеш 64Мб? А если я сделаю размер области тестирования в 2Гб?». Жёсткий диск быстрее читает с внешней стороны диска? А если я размещу тестовую область на внутренней (ближшей к шпинделю) области, да так, чтобы проходимый головками путь был поболе? У него есть read ahead предсказание? А если я буду читать в обратном порядке? И т.д.
В результате мы получаем цифры, каждая из которых неправильная. Например: 15kIOPS и 150 IOPS.
Какая будет реальная производительность системы? Это определяется только тем, как близко будет нагрузка к хорошему и плохому концу. (Т.е. банальное «жизнь покажет»).
- Что best case всё-таки best. Потому что можно дооптимизироваться до такого, что best case от worst будет отличаться едва-едва. Это плохо (ну или у нас такой офигенный worst).
- На worst. Имея его мы можем сказать, что СХД будет работать быстрее, чем полученный показатель. Т.е. если мы получили 3000 IOPS, то мы можем смело использовать систему/диск в нагрузке «до 2000».
Ну и про размер блока. Традиционно тест идёт с размером блока в 4к. Почему? Потому что это стандартный размер блока, которым оперируют ОС при сохранении файла. Это размер страницы памяти и вообще, Очень Круглое Компьютерное Число.
Нужно понимать, что если система обрабатывает 100 IOPS с 4к блоком (worst), то она будет обрабатывать меньше при 8к блоке (не менее 50 IOPS, вероятнее всего, в районе 70-80). Ну и на 1Мб блоке мы увидим совсем другие цифры.
Всё? Нет, это было только вступление. Всё, что написано выше, более-менее общеизвестно. Нетривиальные вещи начинаются ниже.
- прочитать запись
- поменять запись
- записать запись обратно
Для удобства будем полагать, что время обработки нулевое. Если каждый запрос на чтение и запись будет обслуживаться 1мс, сколько записей в секунду сможет обработать приложение? Правильно, 500. А если мы запустим рядом вторую копию приложения? На любой приличной системе мы получим 1000. Если мы получим значительно меньше 1000, значит мы достигли предела производительности системы. Если нет — значит, что производительность приложения с зависимыми IOPS'ами ограничивается не производительностью СХД, а двумя параметрами: latency и уровнем зависимости IOPS'ов.
Начнём с latency. Latency — время выполнения запроса, задержка перед ответом. Обычно используют величину, «средняя задержка». Более продвинутые используют медиану среди всех операций за некоторый интервал (чаще всего за 1с). Latency очень сложная для измерения величина. Связано это с тем, что на любой СХД часть запросов выполняется быстро, часть медленно, а часть может попасть в крайне неприятную ситуацию и обслуживаться в десятки раз дольше остальных.
Интригу усиливает наличие очереди запросов, в рамках которой может осуществляться переупорядочивание запросов и параллельное их исполнение. У обычного SATA'шного диска глубина очереди (NCQ) — 31, у мощных систем хранения данных может достигать нескольких тысяч. (заметим, что реальная длина очереди (число ожидающих выполнения запросов) — это параметр скорее негативный, если в очереди много запросов, то они дольше ждут, т.е. тормозят. Любой человек, стоявший в час пик в супермаркете согласится, что чем длиннее очередь, тем фиговее обслуживание.
Latency напрямую влияет на производительность последовательного приложения, пример которого приведён выше. Выше latency — ниже производительность. При 5мс максимальное число запросов — 200 шт/с, при 20мс — 50. При этом если у нас 100 запросов будут обработаны за 1мс, а 9 запросов — за 100мс, то за секунду мы получим всего 109 IOPS, при медиане в 1мс и avg (среднем) в 10мс.
Отсюда довольно трудный для понимания вывод: тип нагрузки на производительность влияет не только тем, «последовательный» он или «случайный», но и тем, как устроены приложения, использующие диск.
Пример: запуск приложения (типовая десктопная задача) практически на 100% последовательный. Прочитали приложение, прочитали список нужных библиотек, по-очереди прочитали каждую библиотеку… Именно потому на десктопах так пламенно любят SSD — у них микроскопическая задержка (микросекундная) на чтение — разумеется, любимый фотошоп или блендер запускается в десятые доли секунды.
Трешинг. Я думаю, с этим явлением пользователи десктопов знакомы даже больше, чем сисадмины. Жуткий хруст жёсткого диска, невыразимые тормоза, «ничего не работает и всё тормозит».
По мере того, как мы начинаем забивать очередь диска (или хранилища, повторю, в контексте статьи между ними нет никакой разницы), у нас начинает резко вырастать latency. Диск работает на пределе возможностей, но входящих обращений больше, чем скорость их обслуживания. Latency начинает стремительно расти, достигая ужасающих цифр в единицы секунд (и это при том, что приложению, например, для завершения работы нужно сделать 100 операций, которые при latency в 5 мс означали полусекундную задержку. ). Это состояние называется thrashing.
Вы будете удивлены, но любой диск или хранилище способны показывать БОЛЬШЕ IOPS'ов в состоянии thrashing, чем в нормальной загрузке. Причина проста: если в нормальном режиме очередь чаще всего пустая и кассир скучает, ожидая клиентов, то в условии трешинга идёт постоянное обслуживание. (Кстати, вот вам и объяснение, почему в супермаркетах любят устраивать очереди — в этом случае производительность кассиров максимальная). Правда, это сильно не нравится клиентам. И в хороших супермаркетах хранилищах такого режима стараются избегать. Если дальше начинать поднимать глубину очереди, то производительность начнёт падать из-за того, что переполняется очередь и запросы стоят в очереди чтобы встать в очередь (да-да, и порядковый номер шариковой ручкой на на руке).
И тут нас ждёт следующая частая (и очень трудно опровергаемая) ошибка тех, кто меряет производительность диска.
Они говорят «у меня диск выдаёт 180 IOPS, так что если взять 10 дисков, то это будет аж 1800 IOPS». (Именно так думают плохие супермаркеты, сажая меньше кассиров, чем нужно). При этом latency оказывается запредельной — и «так жить нельзя».
Реальный тест производительности требует контроля latency, то есть подбора таких параметров тестирования, чтобы latency оставалась ниже оговоренного лимита.
И вот тут вот мы сталкиваемся со второй проблемой: а какого лимита? Ответить на этот вопрос теория не может — этот показатель является показателем качества обслуживания. Другими словами, каждый выбирает для себя сам.
Лично я для себя провожу тесты так, чтобы latency оставалась не более 10мс. Этот показатель я для себя считаю потолком производительности хранилища. (при этом в уме я для себя считаю, что предельный показатель, после которого начинают ощущаться лаги — это 20мс, но помните, про пример выше с 900 по 1мс и 10 по 100мс, у которого avg стала 10мс? Вот для этого я и резервирую себе +10мс на случайные всплески).
Выше мы уже рассмотрели вопрос с зависимыми и независимыми IOPS'ами. Производительность зависимых Iops'ов точно контролируется latency, и этот вопрос мы уже обсудили. А вот производительность в независимых iops'ах (т.е. при параллельной нагрузке), от чего она зависит?
Отдельно нужно говорить про ситуацию, когда хранилище подключено к хосту через сеть с использованием TCP. О TCP нужно писать, писать, писать и ещё раз писать. Достаточно сказать, что в линуксе существует 12 разных алгоритмов контроля заторов в сети (congestion), которые предназначены для разных ситуаций. И есть около 20 параметров ядра, каждый из которых может радикальным образом повлиять на попугаи на выходе (пардон, результаты теста).
С точки зрения оценки производительности мы должны просто принять такое правило: для сетевых хранилищ тест должен осуществляться с нескольких хостов (серверов) параллельно. Тесты с одного сервера не будут тестом хранилища, а будут интегрированным тестом сети, хранилища и правильности настройки самого сервера.
Последний вопрос — это вопрос затенения шины. О чём речь? Если у нас ssd способна выдать 400 МБ/с, а мы её подключаем по SATA/300, то очевидно, что мы не увидим всю производительность. Причём с точки зрения latency проблема начнёт проявляться задолго до приближения к 300МБ/с, ведь каждому запросу (и ответу на него) придётся ждать своей очереди, чтобы проскочить через бутылочное горлышко SATA-кабеля.
Но бывают ситуации более забавные. Например, если у вас есть полка дисков, подключенных по SAS/300x4 (т.е. 4 линии SAS по 300МБ каждая). Вроде бы много. А если в полке 24 диска? 24*100=2400 МБ/с, а у нас есть всего 1200 (300х4).
Более того, тесты на некоторых (серверных!) материнских платах показали, что встроенные SATA-контроллеры часто бывают подключены через PCIx4, что не даёт максимально возможной скорости всех 6 SATA-разъёмов.
Повторю, главной проблемой в bus saturation является не выедание «под потолок» полосы, а увеличение latency по мере загрузки шины.
Ну и перед практическими советами, скажу про известные трюки, которые можно встретить в индустриальных хранилищах. Во-первых, если вы будете читать пустой диск, вы будете читать его из «ниоткуда». Системы достаточно умны, чтобы кормить вас нулями из тех областей диска, куда вы никогда не писали.
Во-вторых, во многих системах первая запись хуже последующих из-за всяких механизмов снапшотов, thin provision'а, дедупликации, компрессии, late allocation, sparse placement и т.д. Другими словами, тестировать следует после первичной записи.
В третьих — кеш. Если мы тестируем worst case, то нам нужно знать, как будет вести себя система когда кеш не помогает. Для этого нужно брать такой размер теста, чтобы мы гарантированно читали/писали «мимо кеша», то есть выбивались за объёмы кеша.
Кеш на запись — особая история. Он может копить все запросы на запись (последовательные и случайные) и писать их в комфортном режиме. Единственным методом worst case является «трешинг кеша», то есть посыл запросов на запись в таком объёме и так долго, чтобы write cache перестал стправляться и был вынужден писать данные не в комфортном режиме (объединяя смежные области), а скидывать случайные данные, осуществляя random writing. Добиться этого можно только с помощью многократного превышения области теста над размером кеша.
Вердикт — минимум x10 кеш (откровенно, число взято с потолка, механизма точного расчёта у меня нет).
Разумеется, тест должен быть без участия локального кеша ОС, то есть нам надо запускать тест в режиме, который бы не использовал кеширование. В линуксе это опция O_DIRECT при открытии файла (или диска).
Итого:
1) Мы тестируем worst case — 100% размера диска, который в несколько раз больше предположительного размера кеша на хранилище. Для десктопа это всего лишь «весь диск», для индустриальных хранилищ — LUN или диск виртуальной машины размером от 1Тб и больше. (Хехе, если вы думаете, что 64Гб RAM-кеша это много. ).
2) Мы ведём тест блоком в 4кб размером.
3) Мы подбираем такую глубину параллельности операций, чтобы latency оставалось в разумных пределах.
На выходе нас интересуют параметры: число IOPS, latency, глубина очереди. Если тест запускался на нескольких хостах, то показатели суммируются (iops и глубина очереди), а для latency берётся либо avg, либо max от показателей по всем хостам.
Тут мы переходим к практической части. Есть утилита fio которая позволяет добиться нужного нам результата.
Нормальный режим fio подразумевает использование т.н. job-файла, т.е. конфига, который описывает как именно выглядит тест. Примеры job-файлов приведены ниже, а пока что обсудим принцип работы fio.
fio выполняет операции над указанным файлом/файлами. Вместо файла может быть указано устройство, т.е. мы можем исключить файловую систему из рассмотрения. Существует несколько режимов тестирования. Нас интересует randwrite, randread и randrw. К сожалению, randrw даёт нам зависимые iops'ы (чтение идёт после записи), так что для получения полностью независимого теста нам придётся делать две параллельные задачи — одна на чтение, вторая на запись (randread, randwrite).
И нам придётся сказать fio делать «preallocation». (см выше про трюки производителей). Дальше мы фиксируем размер блока (4к).
Ещё один параметр — метод доступа к диску. Наиболее быстрым является libaio, именно его мы и будем использовать.
При тесте диска запускать её надо от root'а.
Измерение случайных IOPS с помощью FIO
FIO - популярный инструмент для измерения IOPS на сервере Linux.
Достаточно гибкий и простой инструмент в пользовании.
В статье будет рассмотрено несколько вариантов проверки, а именно случайное чтение, случайная запись и их комбинация блоками по 4Кб с многопоточностью.
Установка в CentOS/RHEL
Установка в Debian/Ubuntu
Тест случайных операций на чтение/запись
Данный тест создаст файл размером 4Гб и выполнит чтение и запись 4Кб с использованием разделения 75%/25% в файле, причем одновременно будет выполняться 64 операции. На каждые 3 операции чтения - одна операция на запись.
Результат выполнения команды будет приблизительно следующим:
Исходя из полученной информации делаем вывод, что наш диск в среднем выполняет 32115 операций на чтение и 10709 на запись. (Соотношение 3/1)
Тест случайных операций на чтение
Для измерения количества случайных операций на чтение выполняем следующую команду:
Результат выполнения команды будет приблизительно следующим:
Результаты теста показывают 55763 операций чтения в секунду, что очень хорошо для локального SSD.
Тест случайных операций на запись
Для измерения количества случайных операций на запись выполняем следующую команду:
Результат выполнения команды будет приблизительно следующим:
Результаты теста показывают 28660 операций на запись в секунду.
Последним аспектом оценки производительности диска является измерение задержки по отдельным запросам. Один из способов выяснить это - воспользоваться утилитой ioping.
Среднее значение задержки 138.8 us (микросекунд), что в целом очень хорошо! Если данный параметр будет превышать несколько миллисекунд, то с диском или дисковым массивом наблюдаются проблемы. Необходимо провести диагностику и найти “узкое место”, либо источник проблемы.
Вычисление минимально необходимого IOPS
Предположим, что у нас есть приложение, которое требует 600 Read IOPS и
300 Write IOPS . Дисковый массив собран в RAID 5.
Чтобы вычислить минимальное количество IOPS (minReqdIops), добавьте количество требуемых IOPS чтения (reqdReadIops) к сумме количества требуемых IOPS записи (reqdWriteIops) и штрафа RAID (raidWritePenalty): minReqdIops = reqdReadIops + (reqdWriteIops * raidWritePenalty)
В нашем примере:
Минимальное количество IOPS, необходимое для обеспечения уровня производительности для нашего примера - 1800.
ПРИМЕЧАНИЕ. Этот расчет определяет минимальное количество IOPS, необходимое для соответствия спецификации производительности. Это означает, что дисковый массив НЕ должен работать ниже этого уровня производительности.
Читайте также: