IOPS — что это такое, и как его считать / Habr

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

Значит, для определения IOPS надо знать скорость и размер блока при операции чтения / записи. Параметр IOPS равен скорости, деленной на размер блока при выполнении операции.

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

Под линейными операциям чтения/записи, при которых части файлов считываются последовательно, одна за другой, подразумевается передача больших файлов (более 128 К). При произвольных операциях данные читаются случайно из разных областей носителя, обычно они ассоциируются с размером блока 4 Кбайт.

Ниже приведены основные характеристики:

Приблизительные значения IOPS

RAID пенальти

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

В RAID 5 чтобы записать данные происходит 4 операции (Чтение существующих данных, четность RAID, Запись новых данных, Запись новой четности) тем самым пенальти в RAID 5 составляет 4.

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

Характеристика рабочих нагрузок

Вычисление IOPS

Сценарий 1: Вычисление IOPS исходя из определенного кол-ва дисков

Формула для расчета 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

Для RAID-1

Сценарий 2: Подсчет кол-ва дисков для достижения определенного кол-ва IOPS

Опять же для начала формула по которой и будем считать:

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

Для RAID-1

Понимание и подсчет IOPS, RAID пенальти, и характеристик рабочих нагрузок очень критичны аспект при планировании. Когда нагрузка более интенсивна на запись луче выбирать RAID 10 и наоборот при нагрузках на чтение RAID 5.

Программы для измерения IOPS

Что такое IOPS и как его посчитать? — Geek Notes

IOPS используется для определения производительности диска или дискового массива.

IOPS означает Input/Output (operations) Per Second, количество “операций ввода/вывода в секунду”. Величина измеряет объем работы за определенный промежуток времени. По сути, IOPS это количество блоков, которое успевает считаться или записаться на носитель. Чем больше размер блока, тем меньше кусков, из которых состоит файл, и тем меньше будет IOPS, так как на чтение куска большего размера будет затрачиваться больше времени.

“Операция ввода/вывода” — это просто некая часть работы дисковой подсистемы, которая совершается в ответ на запрос хост-сервера и/или некоторых внутренних процессов. Обычно это чтение или запись с различными подкатегориями, например “чтение” (read), “повторное чтение” (re-read), “запись”(write), “перезапись” (re-write), “произвольный тип доступа” (

Основными измеряемыми величинами являются операции линейного (последовательного) и произвольного (случайного) доступа.

Под линейными операциям чтения/записи, при которых части файлов считываются последовательно, одна за другой, подразумевается передача больших файлов (более 128 К). При произвольных операциях данные читаются случайно из разных областей носителя, обычно они ассоциируются с размером блока 4 Кбайт.

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

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

Latency это мера того, сколько времени занимает выполнение одного запроса ввода/вывода, с точки зрения приложения.

Значительные объемы I/O wait это признак того, что источник проблем — хранилище (существуют и другие источники задержек, CPU и сеть — это обычные примеры). Даже в случае хороших показателей latency, если вы видите большое количество I/O waits — это значит, что приложение хотело бы больше скорости от системы хранения.

Определение производительности дисковой системы — это часто игнорируемый аспект проектирования систем. Поскольку дисковая система является самой медленной средой на компьютере, она должна быть одной из ПЕРВЫХ компонентов, спецификация которых правильно определена.

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

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

10K RPM Fibre Channel Disk: 130 IOPS
15K RPM Fibre Channel Disk: 180 IOPS

ПРИМЕЧАНИЕ. Для расчета фактического IOPS для диска требуется следующая информация: Average latency, Average seek time. Эту информацию можно получить от производителя

Вычислим максимальный IOPS для диска

Для примера возьмем диск: Seagate ST500DM002-1BC142

Average latency (avgLatency): 4.16ms или 0.00416s
Average seek time (avgSeek): 8.5ms или 0.0085s

Чтобы вычислить IOPS используем уравнение:

IOPS = 1/(avgLatency + avgSeek)
IOPS = 1/(0.00416 + 0.0085) = 78,9889415

Итого, максимальный IOPS — 79.

Вычисляем максимальное значение IOPS для дискового массива

В примечании к разработке системы хранения, вычисление производительности дисковой системы имеет решающее значение для работы данной системы. Большинство систем используют RAID для обеспечения избыточности хранилища. В этом разделе описывается, как вычисляются IOPS для RAID-массивов.

Максимальное значение IOPS для чтения

Вычисление максимального значения IOPS чтения (maxReadIops) для RAID-массива:

maxReadIops = numDisks * diskMaxIops

Соответственно для массива из 4 дисков максимальное значение IOPS чтения будет следующим:

maxReadIops = 4 * 79
maxReadIops = 316

Максимальное значение IOPS для записи

Вычисление максимального значения IOPS записи (maxWriteIops) — это совсем другое в отношении RAID-массивов. RAID-массивы имеют штраф на запись, а тип RAID-массива определяет серьёзность штрафа. Этот штраф является результатом избыточности, которую предоставляет RAID, поскольку массив обязательно должен записывать данные на несколько дисков/локаций для обеспечения целостности данных.

Штраф на запись RAID-массива

Наиболее распространенные типы RAID и их штрафы на запись определяются в следующей таблице:

Чтобы вычислить максимальное значение IOPS записи (maxWriteIops) для заданного RAID-массива, разделим максимальное значение IOPS чтения (maxReadIops) на штраф за запись RAID-массива (raidWritePenalty): maxWriteIops = maxReadIops / raidWritePenalty

Используя наш пример с 4-мя дисками и конфигурацией RAID 10, получаем следующие значения:

maxWriteIops = 316 / 2
maxWriteIops = 158

Итого, для нашего примера, максимальное значение IOPS на запись для массива RAID 10 — 158.

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

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

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

Что такое IOPS и что он показывает

Все чаще в обзорах накопителей информации – жестких дисков, SSD – помимо скорости чтения и записи используется такой параметр, как IOPS (Input/Output Operations Per Second – количество операций ввода/вывода в секунду). И если значение скорости чтения и записи вполне очевидно, то, что такое IOPS, и как он характеризует работу устройств, не всем бывает понятно. В данной статье я попробую разъяснить на пальцах значение данного параметра.

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

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

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

Теперь представим себе, что файл размером 4000 Кбайт разбит на равные блоки по 4 килобайта (то есть тысяча кусков), которые разбросаны по всему диску. Допустим, чтение такого файла идет со скоростью 400 Кбайт/с. Значит, за одну секунду совершается 100 операций чтения – то есть действий по считыванию каждого отдельного четырехкилобайтного блока. То есть в данном случае IOPS будет равен 100.

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

Значит, для определения IOPS надо знать скорость и размер блока при операции чтения / записи. Параметр IOPS равен скорости, деленной на размер блока при выполнении операции.

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

Какой смысл в этом параметре. Выбираем два устройства, у одного IOPS равен 100, а у другого – 300. Значит, скорее всего, при использовании жесткого диска в качестве загрузочного, он будет функционировать в три раза быстрее.

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

У обычных винчестеров значение IOPS составляет примерно 60-100. У SSD он может достигать 5000-10000. У последних сверхтехнологичных моделей SSD выше 50 000. Другими словами, если у жесткого диска максимальная скорость чтения 100 Мбайт/с, а у SSD – 500 Мбайт/с, то это означает, что пятикратная разница в скорости будет только при копировании больших файлов, когда идут последовательное чтение и запись больших массивов информации.  При работе же операционной системы скорость может отличаться в 20 и даже в 100 раз (то есть IOPS будет отличаться именно в такое количество раз).

Сравнение скоростей SSD (слева) и обычного жесткого диска (справа).
Измеряется скорость последовательного чтения (Seq), блоками 512К и 4К.
При меньшем размере блока скорость ниже.
Однако скорость SSD падает заметно медленнее, чем скорость классических винчестеров.
(изображение кликабельно)

Посмотрите на изображение. На нем сравниваются обычный жесткий диск и SSD. Линейные скорости у них отличаются не сильно (примерно в полтора раза). А вот на блоках 4 Кбайт — разрыв уже в 40 раз. А при записи с очередью в 32 команды еще больше — в 66 раз.

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

Получайте анонсы новых статей прямо на почту

Похожие материалы:

IOPS — это… Что такое IOPS?

IOPS (количество операций ввода/вывода – от англ. Input/Output Operations Per Second, произносится как «ай-опс») – один из ключевых параметров при измерении производительности систем хранения данных, таких как жесткие диски (НЖМД), твердотельные диски (SSD) и сети хранения данных (SAN). В любом случае, независимо от измеряющей программы, параметр IOPS, публикуемый производителем в сопроводительной документации не гарантирует таких же показателей в реальных условиях.

IOPS измеряется такими программами как Iometer, изначально разработанной Intel, а также IOzone, FIO и CrystalDiskMark.

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

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

Основными измеряемыми величинами являются операции линейного (последовательного) и произвольного (случайного) доступа. Под линейными операциям чтения/записи, при которых части файлов считываются последовательно, одна за другой, подразумевается передача больших файлов (более 128 К). При произвольных операциях данные читаются случайно из разных областей носителя, обычно они ассоциируются с размером блока 4 Кбайт.

Ниже приведены основные характеристики:

Для жестких дисков и других электромеханических устройств хранения данных IOPS при произвольном доступе зависит в первую очередь от времени поиска устройства, в то время как, в SSD и системах хранения, сделанных на их основе, количество IOPS в основном зависит от работы внутреннего микроконтроллера и скорости интерфейса памяти. На обоих типах устройств количество IOPS в линейных операциях (при большом размере блока) показывает максимальную пропускную способность, которой можно достичь на устройстве. Обычно линейные IOPS проще показать в Мбайт/с:

IOPS *Размер_блока_в_байтах = Байт_в_секунду (обычно преобразуется в МБайт/с)

В то время как традиционные жесткие диски имеют примерно одинаковое число IOPS на запись и чтение, большинство SSD на основе флэш-модулей NAND обладают значительно меньшим IOPS на запись, нежели на чтение вследствие невозможности записать в ячейку напрямую. Перед этим необходимо выполнить процедуру очистки (т. н. Сбора мусора).

Примеры

Приблизительные значения IOPS для жестких дисков:

Приблизительные значения IOPS для SSD

См. Также

Ссылки

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

Статьи

База знаний: Управление IOPs при аренде виртуальной инфраструктуры. How many IOPs is enough?

При аренде виртуальной инфраструктуры заказчику не всегда просто определиться с требуемым объемом ресурсов, необходимым конкретно под его задачу. Базовый набор облачных ресурсов включает в себя вычислительные ресурсы процессора, исчисляемые в GHz, оперативную память в GB и дисковое пространство в GB. Что касается дискового пространства, к выбору требуемого объема нужно подходить особенно тщательно. Так как на эффективную работу приложения влияет не сколько объем диска, сколько производительность дисковой подсистемы. Потому важно, чтобы сервис провайдер давал возможность управления IOPs-ами и раскрывал информацию об используемых дисковых массивах своей инфраструктуры.

Как же заказчику определиться с объемом и производительностью дискового пространства. 

Предположим, нашему заказчику необходимо разместить в облаке сервис, для работы которого требуется 10GHz процессорной мощности, 20GB оперативной памяти и 100GB дискового пространства. Приобретая такой сервис без заявленных характеристик производительности дисковой подсистемы, заказчик рискует столкнуться с проблемами производительности дисковой подсистемы, обусловленными скоростью носителей данных. Например, запрошенные 100GB дискового пространства возможно предоставить с использованием одного единственного физического носителя (или не менее двух для обеспечения отказоустойчивости), и производительность такого хранилища будет жестко определяться производительностью данного носителя, например, 150 IOPS. Однако, такой производительности может оказаться недостаточно для функционирования сервиса в штатном режиме либо при пиковых нагрузках. Поэтому прежде чем заказывать инфраструктуру под свои цели необходимо определиться не только с тремя основными количественными характеристиками сервиса, но и с требуемой производительностью дисковой подсистемы, исчисляемой в IOPS.

IOPS (количество операций ввода/вывода – от англ. Input/Output Operations Per Second) – один из ключевых параметров при измерении производительности систем хранения данных, жестких и твердотельных дисков и других устройств хранения.

Как заказчику понять, сколько IOPS ему необходимо?

Если приложение уже стоит на инфраструктуре заказчика, но планируется его перенос в облако:

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

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

Мы предоставляем возможность гибкого управления производительностью дисков виртуальных машин. Базово на 1 Gb дискового пространства предоставляется производительность в 1 IOPS. В случае нехватки такого уровня производительности для конкретного сервиса, возможно увеличить производительность, заказав дополнительные IOPS без изменения объема дискового пространства. Такая возможность обеспечивается передовыми технологиями используемых компанией ИТ-ГРАД систем хранения данных.

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

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

Программы для измерения IOPS
IOmeter — тест IOPS
IOzone — тест IOPS
FIO — тест IOPS
CrystalDiskMark — тест IOPS
SQLIO — набор тестов для расчета производительности (IOPS, MB, Latency) под сервера БД
wmarow — калькулятор RAID групп по производительности IOPS

Назад к списку статей

Что такое IOPS? | about NetApp

Сегодня очередной перевод одного из моих любимых авторов, инженера NetApp Dimitris Krekoukias, пишущего в блоге recoverymonkey.org. Текст крайне важный и заставляющий задуматься. Казалось бы, все мы знаем, что такое “IOPS”, но знаем ли мы это на самом деле, и не упускаем ли мы, говоря про IOPS-ы, нечто важное из виду? Насколько полнятие IOPS является однозначно идентифицируемым и можно ли показатели “в IOPS” трактовать однозначно, и сравнивать различные результаты, различных вендоров между собой?

IOPS: Возможно наиболее известный показатель производительности системы хранения.

IOPS означает Input/Output (operations) Per Second, «операций ввода-вывода в секунду». Смысл величины выглядит довольно очевидно. Он измеряет объем работы за определенный промежуток времени (и это не то же самое, что мегабайты в секунду, MB/s).

Кто из вас не видел вендоров, которые превозносят достоинства своих систем хранения, демонстрируя огромные величины IOPS ими достигнутые? Кто из вас не принимал решения покупки системы хранения, основываясь на обещаниях вендорами этих величин? Однако: как часто вендоры, приводя свои результаты, в действительности четко определяли то, что они понимали под аббревиатурой «IOPS», публикуя эти результаты?

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

А теперь подробнее…

Стотыщпицот миллионов IOPS…

Я не раз видел, что некоторые вендоры обещают пользователям высокие показатели по IOPS. На небольшой системе, с числом обычных жестких дисков 15KRPM менее сотни, некоторый трехбуквенный вендор обещает своим пользователям полмиллиона IOPS. Другой — аж миллион. Конечно, пользователи впечатлены, ведь это много, много больше, чем то, что можем предложить мы. Но как обстоят дела на самом деле?

Кое-что я могу объявить прямо вот сейчас: самый маленький нетапповский сторадж, например NetApp FAS2020 может дать миллион IOPS. А может быть даже и целых два миллиона.

Вот, и попробуй, докажи что это не так?

Опровергнуть это невозможно, по той простой причине, что не существует стандартного способа измерения IOPS, и официальное определение IOPS (operations per second, «операций в секунду») не определяет ряд крайне важных параметров. Выполняя любое измерение числа операций ввода-вывода вы автоматически принимаете то «определение IOPS», которым оперирует используемый вами тест.

Что такое «операция»? Какая из множества возможных операций использовалась?

Ответ на этот вопрос может стать довольно сложным и запутанным.

«Операция ввода-вывода» это просто некая часть работы дисковой подсистемы, которая совершается в ответ на запрос хост-сервера и/или некоторых внутренних процессов. Обычно это чтение или запись, с различными подкатегориями, например «чтение» (read), «повторное чтение»(re-read), «запись»(write), «перезапись» (re-write), «произвольный тип доступа» (random), «последовательный тип доступа» (sequential), и размер оперируемого блока данных.

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

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

1. Операция random 4KB read
2. Операция random 4KB read следующая за другими операциями чтения 4KB-блоков, в логической связности с первой
3. Просмотр метаданных блоками по 512 байт, и последующее их обновление
4. Операция чтения блока 256KB, следующая за другими операциями чтения 256KB-блоков, в логической связности с первой
5. Чтение 64MB
6. Последовательность произвольных записей блоком 8KB, за которыми следует последовательное чтение блоком 256KB тех же данных, что были только что записаны
7. Random 8KB перезапись
8. Random 32KB чтение и запись
9. Комбинация всего вышеперечисленного в одном треде
10. Комбинация всего вышеперечисленного в нескольких тредах

…и так далее.

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

? тут мы подобрались к самому важному месту (если вы хотите вынести из этого длинного поста какую-то одну единственную ценную мысль, то она тут):

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

Я хочу это дополнительно подчеркнуть:

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

Latency

?так, мы определили, что не все IOPS одинаковы, но еще более важным параметром для системы хранения является latency, и то, как именно она связана с IOPS.

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

Проще говоря, latency это мера того, сколько времени занимает выполнение одного запроса ввода-вывода, с точки зрения приложения.

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

Базы данных в особенности являются чувствительными к значению latency – они работают таким образом, что формируемые запросы к базе должны быть выполнены максимально быстро (в идеальном случае менее чем за 10ms, записи менее чем 5ms). Обычно записи redo должны выполняться почти мгновенно для высоконагруженной на запись базы, предпочтительно менее чем за 1ms.

Стабильно высокий уровень latency в случае mission-critical приложения может дать крайне неприятный эффект — если база данных не может записать в redo log свою запись, то все встает до тех пор, пока эта запись не будет произведена, и только тогда двинется дальше. Однако, если она постоянно не может записать в redo log достаточно быстро, то ощущения конечного пользователя будут неприемлемы, и запросы к базе начнут массово тормозиться, а база данных может при этом быть бэкэндом к, например, web-фронтэнду для интернет-продаж. Задержки в работе БД в бэкэнде затормозят операции на фронтэнде, и компания может начать терять тысячи пользователей и миллионы долларов продаж из за этих тормозов. Некоторые компании также могут столкнуться с проблемами, более существенными, чем просто невовремя обработанные запросы, если их работа нарушит SLA.

С другой стороны, приложения, имеющие характер доступа преимущественно секвентальный, ориентированный на максимальную пропускную способность в MB/s (это, например, резервное копирование, архивация, или DSS) обычно не являются столь уж чувствительными к значению latency (и, обычно, не нуждаются в высоких показателях по IOPS, а вместо этого требуют высоких показателей по MB/s).

Вот пример с Oracle DB – система показывает около 15.000 IOPS при 25ms latency. Сделать больше IOPS было бы неплохо, но базе гораздо нужнее улучшение результатов по latency, чтобы увидеть значительное улучшение результатов производительности — отметьте, что значения IO waits и latency довольно велики, и что больше всего времени система просто ожидает ввода-вывода (колонка waits):

А теперь сравним с этой системой (формат вывода разный, но это несущественно):

Отметьте, что в данном случае система ожидала, в основном, процессора, а не стораджа.

Значительные объемы I/O wait это признак того, что источник проблем — сторадж (существуют и другие источники задержек, CPU и сеть — это обычные примеры). Даже в случае хороших показателей latency, если вы видите много I/O waits, это значит, что приложение хотело бы больше скорости от системы хранения.

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

Это возможно (но нежелательно) получить одновременно высокие значения IOPS и высокие значения latency.

Как? Вот снова сверх-упрощенный пример:

Представим себе два разных автомобиля, оба они имеют максимальную скорость 150 км/ч.

• Автомобиль #1 затрачивает 50 секунд на достижение скорости 150 км/ч километров в час
• Автомобиль #2 затрачивает 200 секунд на достижение скорости 150 км/ч

Максимальная скорость этих двух автомобилей одинакова.

У кого-нибудь есть сомнения в том, какой автомобиль на практике будет считаться быстрее? Конечно же автомобиль #1 будет ощущаться в четыре раза быстрее, чем автомобиль #2, даже несмотря на то, что они оба в конечном счете достигают одной максимальной скорости.

Теперь давайте сделаем еще один важный шаг, продолжая автомобильную аналогию, так как она довольно понятна большинству людей (но прежде всего потому, что мне нравятся автомобили):

• Автомобиль #1 имеет максимальную скорость 120 км/ч и затрачивает 30 секунда на достижение скорости 120 км/ч
• Автомобиль #2 имеет максимальную скорость 180 км/ч, затрачивает 50 секунд на достижение 120 км/ч, и затем 200 секунд на достижение 180 км/ч

В этом примере автомобиль #2, фактически, имеет гораздо большую максимальную скорость, чем автомобиль #1. Многие люди смотрят только на максимальную скорость, когда определяют быстрейший автомобиль.

Однако автомобиль #1 достигает своей максимальной скорости (120 км/ч) гораздо быстрее, чем автомобиль #2 достигает той же скорости, что и автомобиль #1 (120 км/ч).

Автомобиль #2 продолжает разгоняться (и, конечно, обходит по скорости автомобиль #1), но процесс разгона до максимальной скорости в 180 км/ч занимает непомерно большой интервал времени.

Снова – какой из этих двух автомобилей, как вам кажется, будет ощущаться более быстрым с точки зрения его водителя?

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

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

?менно поэтому и были придуманы популярные автомобильные бенчмарки, типа «гонки на четверть мили»: сколько секунд понадобится для прохождения четверти мили (402 м), в нашем случае это «рабочая нагрузка», «workload», и какая скорость на финише дистанции будет достигнута?

(Я искренне надеюсь, что мои читатели, по совместительству являющиеся фанатами автоспорта, не начнут в этом месте спорить о деталях: подвесках, двигателях, направлении и силе ветра, силе сцепления, трения, и так далее, это просто пример, который иллюстрирует разницу между throughput и latency, я не имел выше ввиду никаких конкретных автомобилей, правда).

Ну и, наконец, несколько примеров…

Вендоры обещают… и некоторые примечания мелким шрифтом по каждому утверждению:

“Наша система делает миллион IOPS!”
…блоками по 512 байт, последовательного чтения из кэша.

“Наша система делает четверть миллиона random 4K IOPS – не из кэша!”
…при 50ms latency.

“Наша система делает четверть миллиона 8K IOPS, не из кэша, при 20ms latency!”
…но только при работе 1000 параллельных тредов.

“Наша система делает сто тысяч 4K IOPS, при менее 20ms latency!”
…но только если к данным обращается один хост, так что дисковая система не отвлекается на ввод-вывод других хостов.

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

На что обратить внимание, когда кто-то обещает грандиозные результаты по IOPS

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

Например, возьмем информацию с вебсайта:

Весьма часто в описаниях встречаются такие ничем не подтвержденные обещания по IOPS. Никакой информации о том, какой блок ввода-вывода использовался, соотношении операций чтения и записи, sequential или random, какой тип дисков такое значение IOPS показал, ну и, конечно, значения latency…

Однако, очень похожая система честно достигла 200.000 SPC-1 IOPS с хорошими показателями по latency в аудированном тесте SPC-1:

На момент, когда я это проверил, 200.000 это в 20 раз меньше, чем 4.000.000. Не поймите меня неправильно, 200.000 IOPS с низкой latency это отличный результат для SPC-1, но это НЕ 4 миллиона SPC-1 IOPS.

Посмотрите мою предыдущую статью про SPC-1, и то как правильно читать его результаты. ? если вендор не публикует результаты своей платформы — спросите его почему он их не хочет опубликовать.

Откуда вообще берутся эти IOPS?

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

1. Что контроллер будет иметь теоретически неограниченные бэкэнд-ресурсы.
2. Что контроллер будет работать исключительно с данными из кэша.
3. Что контроллер будет иметь данные непосредственно в буферах порта FC (“Чоа? 8-/” это правильная реакция, только один трехбуквенный вендор таким промышляет, так что это не широкораспространенная практика).
4. Что контроллер будет настроен под одну специально сформированную конфигурацию рабочей нагрузки, с определенным порогом latency.

Полученные в результате такого подхода величины IOPS могут существовать на самом деле, в контексте того, как проведен тест тем или иным вендором, и как именно он трактует понятие «IOPS». Однако можно ли трактовать такие результаты, как отражающие реальную производительность системы хранения на данных вашего приложения?

Что если кто-то показывает вам большие величины IOPS на Proof-of-Concept или демосистеме?

Proof-of-Concept или демо-инсталляция это отличный способ доказать реальность заявленных показателей. Но помните, что, как всегда: «garbage in – garbage out«, на «входе мусор — на выходе мусор».

Если кто-нибудь показывает вам то, как IOmeter показывает сумасшедшую производительность в IOPS, используйте информацию в этом посте для того, чтобы понять в точности то, как сконфигурирован бенчмарк. Каков выбран размер блока, каково соотношение рандомных операций и секвентальных, сколько хостов выполняют ввод-вывод, и так далее. Не настроена ли система при тестировании так, чтобы использовался «короткоходовый» (short-stroked) доступ к тестируемым данным? Не идет ли доступ к данным преимущественно в кэш?

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

Факторы, влияющие на производительность системы

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

1. Контроллер, CPU, память, число внешних соединений с хостами, их скорость и тип.
2. Число random-записей. Это наибольший влияющий фактор так как, в зависимости от типа RAID, операции ввода-вывода на бэкэнде составляют от 2 (RAID-10) до 6 (RAID-6) операций ввода-вывода на одну операцию записи с хоста, исключая случаи, когда используются определенные способы оптимизации записей, как, например, используемые в WAFL. (advanced form of write management).
3. Строгие требования по времени задержек – отдельные системы демонстрируют периодические скачки latency, происходящие время от времени, даже если они используют SSD (а иногда в особенности, если они используют SSD).
4. Множество перезаписей одной и той же логической области дисков. Это, даже при использовании средств autotiering или megacashing (во flash) все еще приводит к значительной перегрузке ограниченного набора дисков (неважно, вращающихся, или SSD).
5. Тип и количество используемых устройств хранения – различные типы устройств хранения имеют крайне разнообразные характеристики производительности, даже в пределах одного семейства (например, производительность разных моделей SSD может отличаться чудовищно).
6. Средства CDP (Continuous Data Protection) – иногда они приводят к трехкратному увеличению числа операций записи на бэкэнде.
7. Снэпшоты по алгоритму Copy on First Write при высокой рабочей нагрузке на запись.
8. Неверное выравнивание партиций данных.
9. ?нтенсивное использование техник повышения эффективности хранения, таких как компрессия и дедупликация.
10. Сильная зависимость от возможностей autotiering (в результате вы можете начать использовать слишком мало дисков и/или слишком много медленных дисков в попытке сэкономить деньги).
11. Недостаточный для данного рабочего набора данных объем кэша, вкупе с неэффективным алгоритмом кэширования, слишком крупный размер блока и низкая утилизация.
12. Малая глубина очереди порта.
13. Невозможность правильной работы с различными видами ввода-вывода от нескольких различных хостов.
14. Невозможность распознать паттерны поведения в потоке ввода-вывода (например множественные параллельные табличные сканы в базе данных).
15. Невозможность интеллектуальной пред-выборки данных.

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

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

Предоставьте вендору для сайзинга следующую информацию:

1. ?спользуемые приложения, объемы данных для каждого из них (и, идеально, логи производительности для каждого приложения)
2. Число подключаемых серверов
3. Желаемые методы резервного копирования и репликации
4. Размер блока random ввода-вывода приложения по чтению и записи
5. Размер блока sequential ввода-вывода приложения по чтению и записи
6. Определите процентное соотношение по операциям чтения и записи для каждого приложения и каждого типа ввода-вывода
7. Рабочий объем данных (working set), то есть объем данных, с которым активно работает приложение
8. Определите, какие дополнительные возможности системы хранения, такие как thin provisioning, pools, CDP, autotiering, компрессия, дедупликация, снэпшоты и репликация, будут использованы, и какой оверхед они добавят к производительности
9. Определите тип RAID (RAID-10 требует совершить 2 дисковых операции ввода-вывода на каждую операцию random write с хоста, RAID-5 — 4 операции, RAID-6 — 6 операций, это то, что должно быть учтено)
10. Поймите влияние всего вышеперечисленного на общую производительность системы хранения.

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

D.

зачем так много? / Kingston Technology corporate blog / Habr

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

Отметим, что несмотря на схожесть терминов, два последних — это алгоритмически разные задачи. ML обучает компьютер на основе структурированных данных, а DL — на основе отклика от нейронной сети. Пример, помогающий понять различия, довольно прост. Предположим, что компьютер должен отличать фото кошек и собак, которые загружаются с СХД. Для ML следует подать набор изображений с множеством тегов, каждый из которых определяет какую-то одну особенность животного. Для DL достаточно загрузить намного большее число изображений, но всего лишь с одним тегом «это кошка» или «это собака». DL очень похоже на то, как учат маленьких детей — им просто показывают изображения собак и кошек в книжках и в жизни (чаще всего, даже не объясняя детальное различие), а мозг ребенка сам начинает определять тип животного после некоторого критического числа картинок для сравнения (по оценкам, речь идет всего о сотне-другой показов за все время раннего детства). Алгоритмы DL еще не настолько совершенны: чтобы также успешно могла работать над определением образов нейронная сеть, необходимо подать и обработать в GPU миллионы изображений.

Итог предисловия: на базе GPU можно строить HPC-приложения в области Big Data, ML и DL, но существует проблема — наборы данных настолько велики, что время, затрачиваемое на загрузку данных из системы хранения в GPU, начинает снижать общую производительность приложения. Иными словами, быстрые графические процессоры остаются недогруженными ввиду медленного ввода-вывода данных, поступающих от других подсистем. Разница в скорости ввода/вывода GPU и шины к CPU/СХД может быть на порядок.

Как работает технология GPUDirect Storage?

Дженсен Хуанг, генеральный директор NVIDIA, презентует GPUDirect Storage как разновидность GPUDirect RDMA на выставке SС-19. Источник: NVIDIA

Разница между GPUDirect RDMA и GPUDirect Storage — в устройствах, между которыми осуществляется адресация. Технология GPUDirect RDMA переназначена для перемещения данных непосредственно между входной картой сетевого интерфейса (NIC) и памятью GPU, а GPUDirect Storage обеспечивает прямой путь передачи данных между локальным или удаленным хранилищем, таким как NVMe или NVMe через Fabric (NVMe-oF) и памятью GPU.

Оба варианта, GPUDirect RDMA и GPUDirect Storage, избегают лишних перемещений данных через буфер в памяти CPU и позволяют механизму прямого доступа к памяти (DMA) перемещать данные от сетевой карты или хранилища сразу в память GPU или из нее — и все это без нагрузки на центральный процессор. Для GPUDirect Storage местоположение хранилища не имеет значения: это может быть NVME-диск внутри юнита с GPU, внутри стойки или подключен по сети как NVMe-oF.

Схема работы GPUDirect Storage. Источник: NVIDIA

Hi-End СХД на NVMe востребованы на рынке HPC-приложений

СХД на базе 10 накопителей DC1000M U.2 NVMe достойно дополняет сервер с графическими ускорителями. Источник: Kingston

Такая СХД выполняется в виде стоечного юнита 1U или больше и может масштабироваться в зависимости от числа дисков DC1000M U.2 NVMe, где каждый емкостью 3.84-7.68 ТБ. DC1000M является первой моделью NVMe SSD в форм-факторе U.2 в линейке накопителей Kingston для дата-центров. Он обладает рейтингом выносливости (DWPD, Drive writes per day), позволяющим перезаписывать данные на полную емкость один раз в день в течение гарантированного срока службы накопителя.

В тесте fio v3.13 на операционной системе Ubuntu 18.04.3 LTS, Linux kernel 5.0.0-31-generic выставочный образец СХД показал скорость чтения (Sustained Read) 5.8 млн IOPS при устойчивой пропускной способности (Sustained Bandwidth) 23.8 Гбит/с.

Ариэль Перес, бизнес-менеджер SSD в Kingston, так охарактеризовал новые СХД: «Мы готовы снабдить следующее поколение серверов SSD-решениями U.2 NVMe, чтобы устранить многие узкие места в передаче данных, которые традиционно были связаны с системой хранения. Сочетание накопителей NVMe SSD и нашей премиальной оперативной памяти Server Premier DRAM делает Kingston одним из самых полных в отрасли поставщиков комплексных решений для обработки данных».

Тест gfio v3.13 показал пропускную способность 23.8 Гбит/с для демонстрационной СХД на дисках DC1000M U.2 NVMe. Источник: Kingston

Как будет выглядеть типичная система для HPC-приложений, где реализована технология GPUDirect Storage или аналогичная ей? Это архитектура с физическим разделением функциональных блоков в пределах стойки: один-два юнита на оперативную память, еще несколько на вычислительные узлы GPU и CPU и один или несколько юнитов под СХД.

С анонсом GPUDirect Storage и возможным появлением аналогичных технологий у других вендоров GPU, для Kingston расширяется спрос на СХД, рассчитанные на применение в высокопроизводительных вычислениях. Маркером будет скорость чтения данных из СХД, сопоставимая с пропускной способностью 40- или 100-Гбитных сетевых карт на входе в вычислительный юнит с GPU. Таким образом, ультраскоростные СХД, в том числе внешние NVMe через Fabric, из экзотики станут мэйнстримом для HPC-приложений. Кроме науки и финансовых расчетов, они найдут применение во многих других практических областях, таких как системы безопасности уровня мегаполиса Safe City или центров наблюдения на транспорте, где требуется скорость распознавания и идентификации на уровне миллионов HD-изображений в секунду», — обозначил рыночную нишу топовых СХД

Дополнительную информацию о продуктах Kingston можно найти на официальном сайте компании.