ИМХО, показатель хорошего нагрузочного теста - автор в состоянии внятно объяснить КАЖДЫЙ параметр, который он использует. Без "обычно", "в теории это должно быть так" и т.д. Либо метрики снятые с инфраструктуры/нагрузки или на основании ранее проведённого теста.

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

Liveoptics от туда и берет данные для bare-metal систем. И да, они агрегированные, но зато их можно супер просто/быстро получить и в большинстве случаев этого достаточно

гм.. давай по другому. в линуксе есть io sсheduler. он будет раскидывать очередь запросов в рамках одного потока по разным ядрам? на примере dd это очень легко увидеть..

да, это факт. делал выгрузки туда и строил на их базе неплохие диаграммы..

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

ну у тебя же идёт как. fio -> ядро -> драйвер СХД -> очередь тома
таким образом если даже в fio 4 потока и в ядре 4 очереди (blk-mq), а в драйвере СХД 1 поток - то запросы из 4 потоков fio просто сольются в 1 поток
то что ты говоришь по разным ядрам - это не шедулер, а blk-mq (шедулер только запросы переставляет/мержит)
и при этом как я понимаю кроме NVMe / NVMeoF НЕТ интерфейсов, которые бы умели несколько очередей, поэтому фактически всегда такая ситуация что запросы к 1 тому сливаются в 1 поток

хотя как бы возможно "в драйвере" и "в ядре" это одно и то же и именно драйвер СХД (iscsi, что там ещё) должен поддерживать blk-mq, чтобы было несколько очередей

но и при этом в итоге тоже не факт что потом эти несколько очередей не сольются в одну например на уровне HBA

давайте вообще по другому. Вменяемую СХД сложно одним хостом прогрузить не зависимо от очереди количества джобов )

ну почему, если она на жёстких дисках и создать много томов

если будет много томов то это уже много джобов

но и это не даст нормально прогрузить

ну хотя да, в интерфейс подключения всё равно упрётся

у меня есть масивчик алл хдд

Если она не за много миллионов - то вообще не вопрос. Главное чтобы на хосте было достаточно путей до СХД

ну вот я и говорю к тому, что вопрос в числе томов и да, хостов с которых тестишь

а не numjobs fio

Если на хосте 100+ ядер - то всё упирается только в полосу от хоста до стораджа, латенси SAN и количество путей

ну если искать во что все может теоритически уперется, то все упрется в один nlsas drive установленый в схд