Я последовательно читаю большой файл с диска и пытаюсь понять вывод iostat во время чтения.
Вывод iostat выглядит следующим образом
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 833.00 14.00 103.88 0.05 251.30 6.07 5.69 2.33 205.71 1.18 100.00
Вычисление среднего размера запроса ввода-вывода = (rMB / s, деленное на r / s) дает ~ 128 KB, что является значением упреждающего чтения. Похоже, это указывает на то, что, хотя системный вызов чтения указал буфер размером 4 КБ, фактический дисковый ввод-вывод происходит в соответствии со значением опережающего чтения.
Когда я увеличил значение упреждающего чтения до 256 КБ, результат iostat был следующим:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 28.00 412.00 12.00 102.50 0.05 495.32 10.78 12.15 4.76 265.83 2.36 100.00
Опять же, средний размер запроса ввода-вывода составил 256 КБ, что соответствует времени упреждающего чтения.
Это сохранялось до тех пор, пока я не установил 512 КБ в качестве значения упреждающего чтения, и не сохранялся, когда я перешел к значению упреждающего чтения 1024 КБ - средний размер запроса ввода-вывода по-прежнему составлял 512 КБ. Увеличение max_sectors_kb (максимальный объем данных на запрос ввода-вывода) со значения по умолчанию 512 КБ до 1024 КБ также здесь не помогло.
Почему это происходит - в идеале я хотел бы максимально уменьшить количество операций ввода-вывода в секунду при чтении и читать больший объем данных на запрос ввода-вывода (более 512 КБ на запрос). Кроме того, я во всех случаях достиг 100% использования диска - я бы хотел ограничить себя чтением при использовании диска 50-60% с хорошей последовательной пропускной способностью. Вкратце, каковы оптимизированные настройки приложения / ядра для последовательного чтения ввода-вывода.
Вы говорите, что хотите минимизировать количество операций ввода-вывода в секунду при чтении и максимизировать размер каждого запроса ввода-вывода. Я подозреваю, что вам это не принесет пользы. Обычно я бы хотел максимизировать пропускную способность при минимизации задержки и найти хороший баланс этих двух для конкретного приложения.
Обратите внимание, что когда вы перешли от опережения чтения 128 КБ к опережающему чтению 256 КБ, пропускная способность чтения фактически упала с 103,88 МБ / с до 102,50 МБ / с. Я бы не ожидал, что эта тенденция изменится на противоположную при увеличении размера головки чтения. Более высокое значение опережения чтения также создает риск большего количества бесполезных операций ввода-вывода, если данные не являются чисто последовательными, что снизит производительность полезного ввода-вывода.
Если вам интересно, ограничение в 512 КБ, вероятно, исходит от другого уровня в стеке хранения, такого как драйвер SCSI, микропрограмма контроллера или шина.
Чтобы ограничить ввод-вывод, вы можете посмотреть на следующее: Как ограничить количество операций ввода-вывода до максимального предела?
Если вы читаете из файловой системы поверх тома LVM, это кажется ожидаемым поведением. Я также написал в списке рассылки LVM, но мне никто не ответил.
Я подозреваю, что код LVM внутренне управляет блоками / запросами размером не более 512 КБ, поэтому увеличение max_sectors_kb параметр, превышающий этот жесткий предел, не действует