LINUX.ORG.RU
ФорумAdmin

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

 , , ,


0

3

Доброго времени суток.

Есть результат запуска fio ( libaio, рандомное чтение, блок 4k, queue depth 32, process count 4 ) и одновременно сбор данных через

( date; iostat -x 2 ) > iostat.log

fio выдал

  • clat avg 4.3 мс
  • iops 29548

При этом iostat в это же время показывает

  • await ~ 4.0 - 4.5 мс
  • svctm ~ 0.13 - 0.15 мс

svctm хорошо сходится с iops ( 4 fc пути, нагрузка раскидывается равномерно, и это подтверждается графиками await(t), kbps(t) для отдельных путей ), поэтому

$ echo '1/(29548/4) ' | bc -l
.00013537295248409367

Но. судя по исходникам sysstat, svctm - синтетика, вычисляется исходя из загрузки диска, числа выполненных запросов и интервала измерения )

Потребитель видит 4.3 мс, это понятно. Но при этом может быть 4.16 мс запрос в ядре, потом один запрос улетает в fc и возвращается за 0.14 мс . А может быть и наоборот, в ядре время почти не тратится, пачка запросов улетает в fc и каждый в среднем выполняется 4.3, но выполняются одновременно.

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

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

★★★★★

# 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 ожидали завершения операций ввода/вывода

zaz ★★★★ ()
Ответ на: комментарий от router

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

zaz ★★★★ ()
Ответ на: комментарий от zaz

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

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

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

router ★★★★★ ()
Ответ на: комментарий от router

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

zaz ★★★★ ()

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

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

tailgunner ★★★★★ ()

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

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

bigbit ★★★★★ ()
Ответ на: комментарий от vel

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

router ★★★★★ ()
Ответ на: комментарий от zaz

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

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

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

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

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

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

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

router ★★★★★ ()
Ответ на: комментарий от bigbit

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

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

router ★★★★★ ()
Ответ на: комментарий от router

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

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

Да,

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

tailgunner ★★★★★ ()
Ответ на: комментарий от router

Я думаю, что в

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

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

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

vel ★★★★★ ()

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

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

router ★★★★★ ()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от Oxdeadbeef

время в СХД?

WTF?

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

// К.О. и гугл

router ★★★★★ ()
Ответ на: комментарий от router

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

router ★★★★★ ()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

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

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

blind_oracle ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.