Можно ли разделить время обработки запроса на время в ядре и время в СХД?

# time dd if=/dev/sda of=/dev/null bs=$((1024*1024)) count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 6,9825 s, 154 MB/s

real    0m6.984s
user    0m0.007s
sys     0m0.671s

Команда выполнялась 6984 ms из них 7ms чето делалось в юзерспейсе 671ms в кернелспейсе и соотвецтвенно 6306ms ожидали завершения операций ввода/вывода

Спасибо, но это немного не то. ИМХО, запрос может подождать в ядре и не тратя sys

И что с того ? Без разницы тратит он сис или нет. Просто если запрос выполняется 10 секунд реального времени и при этом он потребляет CPU только одну секунду (user + sys) то очевидно что оставшиеся 9 секунд он чегото-там ожидает. Если мы зарание знаем что запросы идут на ввод/вывод то ожидает он какраз ввода/вывода. Конечно если команда не тривиальная (как dd) то там могут появится простои на синхронизации и тд. Тогда это можно все собрать через strace или iotop (если приложение работает довольно долго).

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

Опять же, в случае нагрузочного тестирования через fio, время в ядре может тратиться на переключение контекста и любые другие системные вызовы, не связанные с обработкой IO запроса. Доля времени в ядре может сильно зависеть от скорости поступления запросов и глубины очереди всех элементов ( aio max_nr, device queue depth, hba queue depth, queue depath массива, queue depth lun'а на массиве ) и т.д.

Есть конкретный профиль нагрузки, и нужно в нём отделить мух от котлет

Причем тут это все. Что показывает time: У каждого контекста процесса (структура внутри ядра) есть 2 щетчика: 1 включается когда процесс (поток) размещается на CPU в ring 3 (ну или в userspace для 64 бит), второй включается когда процесс размещается на CPU в кернел спейс. Оба сщетчики останавливаются когда процесс теряет CPU. Если у нас не нагружена система (активных процессов меньше чем CPUs) то процесс может потерять CPU только по своей инициативе: уйти в слип, запросить некий ресурс (например семафор/мутекс) и ожидать его, запросить ввод/вывод и ожидать завершения опирации. В примере с dd было видно что всего дд отрабатывал (грубо говоря) 7 секунд (реального времени). Из этих 7 секунд 1 секунду он чтото реально делал (не важно что и не важно где в юзерспейсе или кернел спейсе) а 6 секунд он просто спал (но мы знаем что в dd слипа нету а есть ожидание ввода/вывода) соотвецтвенно можно сказать что 6 секунд мы ожидали завершения ввода/вывода.

Вопрос, возможно ли как-то оценить время, которое запрос ждёт в ядре?

Время от входа в ядро до выдачи запроса в fc?

запустить приложение в отдельной cgroup и посмотреть там blkio.io_wait_time ?

Возможно ли снять статистику не с дисков, а с HBA?

Почему бы не снять статистику с массива?

Да, или наоборот время в fc. в общем, разбить clat avg ( ~= await ) на две части - в ядре и в СХД

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

Я не настаиваю, что прав. Возможно, прав окажешься ты.

Но на текущем уровне знаний я считаю, что всё несколько сложнее.

У каждого контекста процесса (структура внутри ядра) есть 2 щетчика: 1 включается когда процесс (поток) размещается на CPU в ring 3 (ну или в userspace для 64 бит), второй включается когда процесс размещается на CPU в кернел спей

В тесте fio я использую libaio, асинхронные запросы. Приложение не ждёт завершения IO. Отправило запрос и то ли время от времени проверяет, то ли вообще какой callback повесило

Если у нас не нагружена система (активных процессов меньше чем CPUs) то процесс может потерять CPU только по своей инициативе: уйти в слип, запросить некий ресурс (например семафор/мутекс) и ожидать его, запросить ввод/вывод и ожидать завершения опирации.

Ну не совсем. На процессор претендуют много других потоков, в т.ч. потоки ядра. В т.ч. не связанные с IO

В общем, когда речь идёт о миллисекундах ( а при меньшей глубине очереди - микросекундах ), гадать на косвенных признаках не очень удачная мысль, ИМХО.

Почему бы не снять статистику с массива?

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

Вопрос, возможно ли как-то оценить время, которое запрос ждёт в ядре?

Время от входа в ядро до выдачи запроса в fc?

Да,

Я думаю, это возможно только с SystemTap.

время в СХД?

WTF?

Я думаю, что в

blkio.io_serviced
blkio.io_service_time
blkio.io_wait_time
blkio.leaf_weight
blkio.time

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

Гм. Интересно, а столько сотых долей процента программ используют AIO ?

По-моему ты что-то усложняешь.

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

Это может иметь какой-то смысл если у тебя 100% загрузка процессора и ядро конкурирует с чем-то ещё за время CPU. Да и в этом случае - зачем тебе эти наносекунды, если на СХД всё равно всё гораздо дольше.

Ещё один момент - массив полностью на ssd, hp 3par %)

Потому и сомневаюсь, что 4 мс для ssd это офигенно много. И svctm с iops'ом показывают, что один отдельный запрос обрабатывается 0.13 мс, даже если в это время идёт серьёзная нагрузка в 1024 одновременных запроса. А вот ОСь - rhel 4, т.к. дальше на том же массиве будут тестировать одну интересную БД под oracle 9 :\

время в СХД?

WTF?

сеть хранения данных, san.

// К.О. и гугл

З.Ы. я вот тут подумал, что можно ещё посмотреть на текущую очередь, т.к. гугл и netapp подсказывают формулу iops * time = min queue depth, причём я бы сказал, что в качестве time нужно брать не svctm ( в произведении по определению получится единица ), а await

2 чая этому регистранту!

Там RHEL4, так что никакого чая в этот раз.

У меня на all-flash схд среднее время отклика 0.5-1мс через FC 8Gbit. Пиками бывает и до 3.5-4мс, но редко.

0.13мс это как-то нереально, по идее оно даже меньше чем время полёта пакета FC туда-обратно с обработкой в стеках протоколов.

гугл и netapp подсказывают формулу iops * time = min queue depth

Формулу подсказывает Литтл из ТМО, а гугл и netapp - плагиаторы =)
https://en.wikipedia.org/wiki/Little's_law