IOps (операций в секунду) не рекомендуем использовать для расчета оборудования

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

Наоборот, такая оценка может сформировать ложное представление о высокой производительности дисковой подсистемы, в то время как при эксплуатации в продуктивных условиях может выясниться недостаточная мощность СХД.

К примеру, можете ли Вы сказать, что конкретно делает «операция» из метрики IOps? Какого размера данные читаются/пишутся? Корректно ли сравнивать IOps для обычных жестких дисков и SSD? Как учитывают методики подсчета IOps замедления скорости на SSD по мере «износа» или когда на SSD мало свободного места? Можете сказать чем отличаются  Raw IOPS и Functional IOPS?

Примечание. Total Raw IOPS = Disk Speed IOPS * Number of disks
Functional IOPS =(((Total Raw IOPS×Write %))/(RAID Penalty))+(Total Raw IOPS×Read %)

Уверены ли Вы что разные программы измерения иопс Вам дадут одинаковые результаты?

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

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

Или еще скажем точно ли методика подсчета IOps учитывает время отклика с диска и пропускную способность?

Чтобы понять почему не все просто, нужно рассмотреть простой пример и аналогию.
По дороге следует переместить из А в Б большое количество человек. Возможно два варианта: мы можем перевозить их в их личных автомобилях или же усадить в автобусы. Пропускная способность дороги конечно же будет выше в случае перевозки людей автобусами, то есть «большими блоками». Однако методы общественного транспорта обычно вступают в конфликт с индивидуальными целями и маршрутами. Хорошо если в Б у нас огромный завод, на который устремлен основной поток из А. Можно погрузить все «байты» в один большой пакет-автобус на входе, и выгрузить его на остановке у завода, куда собственно и направляются все наши «байты».
Однако если наши байты не едут на завод, а разъезжаются по индивидуальным и независимым делам-«операциям», каждый имея индивидуальный маршрут, то доставка их «автобусом»-большим пакетом приведет напротив к большим потерям времени. В этом случае транспортировка индивидуальными автомобилями будет более выгодна. Однако общий пропускной объем дороги заполненной индивидуальными «пакетами»-авомобилями везущими по нескольку байт каждый, разумеется будет ниже, чем при перевозке большим пакетом-«автобусом».
Таким образом увеличение пропускной способности в MB/s за счет укрупнения пакетов приводит к снижению IOPS, и наоборот, рост операций в секунду «доставленных к цели пассажиров» нашей дороги-интерфейса, запруженной автомобилями, приводит к снижению ее пропускной способности в MB/s. Нельзя одновременно достичь высоких показателей в IOPS и в MB/s просто по физическим свойствам существующего оборудования.
Либо большие пакеты-«автобусы» и их мало («операций в секунду»), либо маленькие индивидуальные пакеты-«автомобили», каждый осуществляющий индивидуальную «операцию» по доставке данных, но заполняющие всю дорогу, и общий human traffic в результате невелик.

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

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