понимание blktrace из тестов fio

Question

Я купил виртуальный сервер с 8 виртуальными ЦП, памятью 16 ГБ и томом ssd 500 ГБ (который поддерживается ceph rbd). Затем я использовал fio для проверки производительности ввода-вывода сервера. Чтобы лучше понять результаты fio, во время теста я также использовал blktrace для захвата трассировки ввода-вывода блочного уровня.

1. seqwriete

   fio --filename = / dev / vdc --ioengine = libaio --bs = 4k --rw = write --size = 8G --iodepth = 64 --numjobs = 8 --direct = 1 --runtime = 960 --name = seqwrite --group_reporting

вывод fio для seqwriteпроанализированный вывод blktrace для seqwrite

2. случайный

   fio --filename=/dev/vdc --ioengine=libaio --bs=4k --rw=randread --size=8G --iodepth=64 --numjobs=8 --direct=1 --runtime=960 --name=randread --group_reporting

вывод fio для randread проанализированный вывод blktrace для randread

Я пытаюсь понять разницу на уровне блоков между seqwrite и randread.

1. почему randread имеет большую часть I2D, а seqwrite - нет?
2. почему у randread нет Q2M?

Answer 1

(Обратите внимание, что на самом деле это не вопрос программирования, поэтому Stackru - неправильное место, чтобы задавать это... Может быть, Super User или Serverfault были бы лучшим выбором?)

почему randread имеет большую часть I2D, а seqwrite - нет?

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

почему у randread нет Q2M?

Трудно поддержать объединение случайных операций ввода-вывода с существующими операциями ввода-вывода в очереди, так как они часто являются несмежными!