Mark ☢️
( у меня есть догадки, но я спрашиваю у эксперта)
Mark ☢️
и да, йопсы тоже возросли
Mark ☢️
а почему иопсы возросли?
Mark ☢️
да уж понятно
Mark ☢️
вначале 1 а потом 2
Roman
и?
Mark ☢️
что и
Mark ☢️
почему иопсы возросли?
Roman
т.е. с iodepth=2 у тебя удвоилось число iops?
Mark ☢️
да
Mark ☢️
замечу, что это линейная запись
Roman
а ты продолжи график
Mark ☢️
а я продолжил
Mark ☢️
иодепс 4: write: io=92064KB, bw=1913.2KB/s, iops=478, runt= 48122msec
Roman
сколько будет при 8, 16, 32, 64, 128 ?
Mark ☢️
8: write: io=65088KB, bw=3740.5KB/s, iops=935, runt= 17401msec
Sergei
а что за устройство-то?
Mark ☢️
да диск обычный
Mark ☢️
ЛИНЕЙНАЯ запись, ребят
Mark ☢️
16: write: io=278344KB, bw=6589.6KB/s, iops=1647, runt= 42240msec
Mark ☢️
32: write: io=185192KB, bw=7249.4KB/s, iops=1812, runt= 25546msec
Mark ☢️
так вот. вопрос — почему при оидепс 1 и 2 в этом режиме иопсы возрастали?
Mark ☢️
м?
Mark ☢️
64: write: io=551940KB, bw=13837KB/s, iops=3459, runt= 39890msec
Mark ☢️
эмммм
Sergei
а вопрос в чем?
у тебя головка уже там где надо, перепозиционирование не нужно. предположу, что мозги диска выстраивают две (или более) последовательные операции и пишут их за одно вращение блина.
Mark ☢️
Mark ☢️
это оно ведь?
Roman
если у тебя после 32 будет рост - значит, не оно.
Mark ☢️
ага, значит мои предположения верны. сейчас напишу в одном сообщении несколько....
Mark ☢️
64: write: io=551940KB, bw=13837KB/s, iops=3459, runt= 39890msec
128: write: io=613372KB, bw=25944KB/s, iops=6486, runt= 23642msec
256: write: io=1024.0MB, bw=43587KB/s, iops=10896, runt= 24057msec
Mark ☢️
ну короче вот
Mark ☢️
так что происходит ?
Roman
тебе не кажется странным, что у тебя рост и после 64 команд в очереди?
Roman
сколько у тебя nr_requests ?
Mark ☢️
дефолтное.. 128 тоесть
Mark ☢️
хотя. лучше убедиться
Roman
ну и 10k iops - это что-то странное
Roman
покажи iostat при этом
Mark ☢️
fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=test —bs=4k —iodepth=256 —size=1G —readwrite=write —filename=/dev/sdb
Roman
а..
Roman
сделай —bs=1k
Roman
подскочат у тебя iops в 4 раза или нет? :)
Mark ☢️
Mark ☢️
оба-на
Mark ☢️
что за нах
Mark ☢️
а средняя длина очереди всеравно 32
Mark ☢️
а средний размер запроса больше.
Mark ☢️
ну понятно. склеивает, сука
Mark ☢️
ну, тоесть, кросаучег
Mark ☢️
(я отлучусь на 10 минут)
Polnoch
Roman
я тебе об этом и говорил: глубина очереди в 128 команд перекрывает всё ncq.
Roman
и будет оно склеивать, а с deadline ещё и переупорядочивать.
Mark ☢️
так
Mark ☢️
дак получается, что NCQ нужно только если ОС не умеет склеивать ?
Mark ☢️
или склеивание отключили через noop
Roman
выстави nr_requests=1
Roman
и посмотри
Mark ☢️
возрастают ли иопсы?
Mark ☢️
начал смотреть. результаты напишу большим паком
Mark ☢️
1: write: io=10312KB, bw=490568B/s, iops=119, runt= 21525msec
2: write: io=13424KB, bw=982220B/s, iops=239, runt= 13995msec
4: write: io=36256KB, bw=1912.7KB/s, iops=478, runt= 18956msec
8: write: io=49952KB, bw=2422.9KB/s, iops=605, runt= 20617msec
16: write: io=54208KB, bw=2418.3KB/s, iops=604, runt= 22416msec
32: write: io=52704KB, bw=2418.4KB/s, iops=604, runt= 21793msec
64: write: io=51768KB, bw=2412.5KB/s, iops=603, runt= 21459msec
Roman
гм
Roman
32 и 64
Mark ☢️
ну каг-бы вот.
Mark ☢️
после 8 ничего не растёт
Mark ☢️
ещё раз — @pragus что это означает, как доктор мне расскажите ?
Mark ☢️
(это всё с nr_requests=1 и cfq)
Mark ☢️
странный вывод.
а какой должен быть вывод если ты скзаал что линуксный шедулер перекрывает NCQ ?
Roman
а какой должен быть вывод если ты скзаал что линуксный шедулер перекрывает NCQ ?
ну шедулер можно "отключить", выставив размер очереди в 1
Mark ☢️
буханка и троллейбус