Отклик при высоком i/o

Ядро патч, если хочешь избегать фризов при высоком io. Плюс, вроде как, в последнем ядре исправлено поведение медленных блочных устройств.

Какой именно патч?

Какой хочешь, можно ck- взять или pf- или ещё какие - их в достатке. Хорошо, если в репах ядра разные есть, можно несколько накатить.

Перешел на ядро 4.5 в дебиане и любые проявления 12309 исчезли.

ну ты конкретно какой пробовал и какой гарантировано работает? Так патч или шедулер сменить?

Ну я вот вот патчсетом Постфактума пользуюсь. Он комплексный и пользуюсь я не всем, но там есть патчи Коливаса, BFS, UKSM, march=native (или что-то в этом духе) и всякие мелкие ништяки россыпью. Есть там какие-то вещи для гибернации, например, которыми я не пользуюсь.

Так или иначе, с этим патчсетом я не страдаю от медленных блочных устройств или страдаю в куда меньших масштабах. Да и вообще отзывчивость получше стала.

C noop тоже тормозит, но уже резвее.

В патчсете пост-фактума для 4.5, кроме всего прочего, есть ещё и это:

http://git.kernel.dk/?p=linux-block.git;a=shortlog;h=refs/heads/wb-buf-throttle

Я же не буду перечислять всё, что есть в патчсете пост-фактума, тем более, что сам его вдоль и поперёк не смотрел.

Если в материнской плате нет поддержки ncq, то не один софтовый планировщик не обеспечит комфортной работы при высоком IO. Вариантов кроме как увеличить кол-во озу или купить новую материнскую плату - нет

в материнской плате нет поддержки ncq

а как это узнать на онтопике?

dmesg | grep -i ncq

[    0.527319] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 
[    0.994330] ata1.00: 500118192 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    1.001275] ata3.00: 1465149168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[10795.256443] ata2.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32), AA

гэта вельмі добра! Но использую noop:

CONFIG_IOSCHED_NOOP=y
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"

Вроде есть поддержка:

# dmesg | grep -i ncq
[    0.426821] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pmp pio slum part ems apst 
[    0.926404] ata1.00: 156301488 sectors, multi 1: LBA48 NCQ (depth 31/32)
[    2.037441] ata4.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)

у тебя похоже диски не AA-класса, как у меня.

Affordable Anal?

Androgyny Anonymous

В /etc/sysctl.d/dirtybytes.conf добавьте следующее:

vm.dirty_background_bytes = 4194304
vm.dirty_bytes = 4194304

sudo sysctl -p /etc/sysctl.d/dirtybytes.conf

Ты осознанно советуешь такие маленькие значения, да ещё и равные друг другу?

Лучше ратио 15 и 30 процентов, сирисли. В результате кэширование в оперативной памяти здорово повышает производительность.

Этот метод вполне работает, хотя если уменьшить в 2 раза ещё лучше будет (на деле нужно смотреть сколько набортного кэша у самого диска), но производительность, однако, падает.

Какой хочешь, можно ck- взять или pf- или ещё какие - их в достатке. Хорошо, если в репах ядра разные есть, можно несколько накатить.

Так какое из этих ядер избавляет от фризов?

Вроде бы это уже не тот самый 12309

Файловая система btrfs?

Да.

Да и вообще отзывчивость получше стала.

Тоже так казалось в первое время.

Никакое, если галимое железо или неправильно накручены настройки в sysctl.

У меня 1.5мб dirty, background 9мб чтобы не запускалось, система не лагает и скорости вроде нормальные.

Оно активируется какой-то опцией или нет?

Аналог CoDel для блочных устройств? А что, интересная мысль.

Ну это не плацебо, я тестировал на своём железе.

v4 нет, v5 ещё не разбирал.

Да.

Собираю тестовое ядро, там CONFIG_WBT=y без лишних вопросов.

Никакое, если галимое железо или неправильно накручены настройки в sysctl.

Хорошо, а как узнать какое железо галимое, а какое нет? Настройки в sysctl сейчас вернул в дефолт.

Ну это не плацебо, я тестировал на своём железе.

Говоря словами pf - «у вас не галимое железо». А мне, видимо, не повезло и при некоторых условиях его галимость проявляется во всей красе.

какое железо галимое, а какое нет?

Не знаю, я никогда 12309 не встречал.

Не знаю, я никогда 12309 не встречал.

Я тоже никак не могу его увидеть.

Не знаю, я никогда 12309 не встречал.

Звучит как «я 12309 не замечаю».

Не уверен, что должно звучать именно так. На медленные старые флешки я тоже пишу, но ничего при этом никогда не ловлю. Точнее, ловил один раз на компе, где мало ОЗУ, но настройка dirty помогла. Это не 12309.

Точнее, ловил один раз на компе, где мало ОЗУ, но настройка dirty помогла.

У меня при высоком IO система может стать колом. Это очень напрягает.

Это не 12309.

Да не важно, какой там номер бага. Факт, что это плохое поведение. Когда приложение, которому нужен диск при высоком IO становится колом, то это не беда. Беда, когда при этом становится колом вся система.