LINUX.ORG.RU

freebsd размер i/o чанка в сисколле read() и в gstat

 , gstat,


1

1

Раньше я делал read() на 1048576 байт, в gstat он показывался как 8 чтений по 131072 байт, которые отправлялись очередью. После обновления 12 -> 13 в gstat оно стало видно как 1 чтение 1048576 байт, и ухудшилась скорость работы. Такая зависимость скорости от размера блока - будем считать, особенности железа, речь не про неё.

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

Это всё с O_DIRECT если что, а диски multipath.

Уточнения:

1) от multipath не зависит.

2) несмотря на O_DIRECT он походу делает read-ahead, потому что см. ниже

проверял dd iflag=direct с разными bs

размер в read()     размер в geom было - стало
1K                  32K            32K
2K                  33K            33-34K
4K                  35K            36K
8K                  39K           42K
16K                 50-51K         62K
32K+                128K           1M
Начало тоже отличается, но резкая смена поведения на 32к+ блоках выглядит странно.

Если кто захочет у себя потестить, код для узнавания размера geom-чанка

while true; do X=`gstat | grep -F тут_шаблон_для_грепа_строки_с_нужным_диском` ; rs=`echo $X | awk '{print $3}'` ; kbs=`echo $X | awk '{print $4}'` ; bs=`expr $kbs / $rs` ; echo "$rs $kbs $bs"; done
выводит чтения в секунду, килобайты в секунду и деление второго на первое (т.е. килобайты на 1 чтение)

Само чтение:

dd iflag=direct if=путь_к_большому_файлу_на_нужном_диске of=/dev/null bs=1024
запускаем с разными bs, смотрим в другом окне вывод первой команды в это время, проверять с не степенями двойки смысла наверно нет. Если на диске в это время параллельно есть небольшая активность - пофиг, а вот большая испортит статистику наверно.

★★★★★

Последнее исправление: firkax (всего исправлений: 6)

Нашёл kern.maxphys который был 131072 а стал 1048576, видимо дело в нём. Надо будет проверить попозже. Непонятно только откуда он подтянул это 1048576, в конфиге ядра написано что дефолт 128К и он вроде нигде не был переопределён. Или может там просто забыли комментарий исправить.

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