service irqbalance restart срабатывает?

Да, от 12309 только SSD спасает, но поди-ка напасись этих дорогущих игрушек!

vm.dirty_bytes и vm.dirty_background_bytes помогать перестали с каких пор?

12309 - продолжаем наблюдения

Продолжайте вести набледения. Мы с вами свяжемся. Свободны!...

12309 - продолжаем наблюдения

Продолжайте вести наблюдения. Мы с вами свяжемся. Свободны!...

У меня только с ssd и проявляется. А без ssd например mpv периодически подлагивает. На ssd в mpv иногда после перемотки включается режим слайдшоу, так и не получилось 100% воспроизвести, но бесит неимоверно. Мультики ещё туда-сюда, там в любом случае 5 кадров в секунду, а кино просто невозможно смотреть. Может быть это как-то связано?

А в dmesg сёра ошибками от видеодайвера нет?

Всё чисто, но вроде пару раз заметил что при этом начинается небольшой рассинхрон (в консольке видно). Nvidia, последний блоб. Mpv кеширует файлы, так что не понимаю с чего бы такие серьёзные проблемы.

Они никогда и не помогали на 100%. Еще с тех пор, как я обратил внимание году в 2008 на эту проблему, и мне советовали то да се, немного прогресс был, но все равно тормоза дичайшие при хорошем обращении к IO оставались. Есть, конечно, вариант сильно ограничить ресурсы на дисковые операции, но в этом случае работать с носителями становится адски жутко!

Да. :(

smilessss, включён это точно. Настроен ли правильно не знаю, я его не настраивал самостоятельно.

sudo systemctl is-active irqbalance
active

есть такая буква на барабане

vm.vfs_cache_pressure=1000
vm.dirty_background_bytes = 16777216
vm.dirty_bytes = 134217728
да ниасоба, в самом деле

озу сколько? материнка какая?

У фрактала интол.

оффтоп

Неужели 12309 еще жив? Вроде как пофиксили 2 года назад , окончательно.

Сколько раз его окончательно фиксили, не напомнишь?

Ты говори с каким ядром его окончательно пофиксили.

Я его в первый раз на 4.10 и увидел.

12309 не существовал изначально. Были, есть и скорее всего будут набор симптомов от разных «болячек» которые притягивают к единой проблеме и ищут виновных в самом неподходящем для этого месте - в ядре.

К примеру ни одного реального теста показывающего наличие 12309 не существует.

Эффект то вполне наблюдаемый и 100% воспроизводимый. Расскажите тогда как залоггировать это зависание. Ядро любит зависнуть просто так и все подождут. Отличный пример исчерпание всей памяти (своп можно отключить чтобы эффект максимально яркий быстрый был). Как сохранить в логе чем ядро занимается эти 5 минут до прихода OOM?

Эффект то вполне наблюдаемый и 100% воспроизводимый.

Давай свой тест.

Отличный пример исчерпание всей памяти (своп можно отключить чтобы эффект максимально яркий быстрый был).

Спокойно живу без свопа проблем схожих с 12309 не наблюдаю.

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

Запусти 100500 вкладочек в браузере и убанту в виртуалке и ещё жрущего памяти софта до полного исчерпания озу, для полного катарсиса при этом копируй с ssd на тормозную флэшку несколько гигов.

не существовал изначально. Были, есть и скорее всего будут

Манёвры уровня маркетинг. То, что оно нифига не починено значит, что те люди которые должны разбираться в ядре нифига не разбираются, а потому хомячковые названия проблемы ничуть не хуже тн «правильных» названий от недоэкспертов.

Запусти 100500 вкладочек в браузере и убанту в виртуалке и ещё жрущего памяти софта до полного исчерпания озу, для полного катарсиса при этом копируй с ssd на тормозную флэшку несколько гигов.

Ок. Только это будет вовсе не 12309. Попытка не очень если на чистоту. Попробуй ещё раз.

Манёвры уровня маркетинг.

Если у тебя внезапно исчерпано всё ОЗУ и некое IO копиование/перемещение выполнявшееся в тот же момент вдруг встало раком так это скорее закономерно.

То, что оно нифига не починено

Трудно починить несуществующий баг который нельзя ни определить или описать конкретно его условия ни зафиксировать место где он возникает.

несуществующий

Думаю, встречающие его пользователи тебя за такую формулировку никем хорошим не назовут.

Думаю, встречающие его пользователи тебя за такую формулировку никем хорошим не назовут.

Как "встречающие его пользователи" за столько времени так и не смогли дать конкретное опрделение мифу про жуткий 12309?

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

Ну или как вариант они этот баг тупо игнорят, хотя прекрасно знают что к чем, как тормоза от флэшек и зависания при oom.

Это пожалуй наиболее вероятный вариант.

Гм. А ведь настала пора хвастаться.
С 4.19.0-0.bpo.5-amd64 и bfq по дефолту хуком udev всё идельно плавно.

Сейчас легко играется 4k видеопоток с файлопомоечного винта, который трешат парой торрент и compsize.
Перемотка туда-сюда с минимальным фризом.

Это пришёл он: год Linux на десктопе.

Это пришёл он: год Linux на десктопе.

… презентировал слайды на опсосконференции 2017 Джим Землин из под макоси …

походу как решено, вот уже месяц никаких подлаживаний в браузере.
весь корень зла 12309 у меня получается был вот из-за этой муйни:

irqbalance

удалил её. и вот тестировал сейчас чуть менее месяца.

Зачем ты её ставил?

не ставил

А какой-то клоун недано как раз предлагал ставить ставить это для «решения» проблемы, кек.

Но заплатки, конечно, производительность не снижают, нееее))

Снижают только на старых процессорах. На Skylake и новее не так заметно (на Cofeelake вообще не замечаю, мб из-за избыточной мощности).

Всё прекрасно заметно, производительность слишком большая просто.

- Ты суслика видишь? - Нет. - А он есть.

Простой тест на наличие проблемы 12309:

dd if=/dev/zero of=~/tmp/12309_1 bs=1024 count=10000000

Вот результат запуска трёх 'dd' на четырёх ядерной системе (шапка утилиты top):

%Cpu0  :  2,1 us,  0,7 sy,  0,0 ni, 12,2 id, 85,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu1  :  2,7 us,  0,3 sy,  0,0 ni, 34,6 id, 62,4 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu2  :  1,5 us,  0,4 sy,  0,0 ni,  1,5 id, 96,7 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu3  :  0,7 us,  0,0 sy,  0,0 ni,  0,7 id, 98,6 wa,  0,0 hi,  0,0 si,  0,0 st
КиБ Mem : 16346176 total,  6124656 free,  4277604 used,  5943916 buff/cache
КиБ Swap: 17037308 total, 17037308 free,        0 used. 11401404 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                                                                  
24851 aaaaaaaa  20   0    8732    840    776 D   5,3  0,0   0:02.39 dd                                                                                                                                                                       
24850 aaaaaaaa  20   0    8732    920    856 D   5,0  0,0   0:03.96 dd                                                                                                                                                                       
24852 aaaaaaaa  20   0    8732    936    872 D   5,0  0,0   0:01.26 dd   

Обратите внимание на такой показатель у ядер %CpuX как 'wa', что, если не ошибаюсь, расшифровывается как Wait Access или по-нашенскому — «Ожидание завершения операции ввода вывода».
Т.е. каждое ядро проводит большую часть времени ожидая когда завершится операция записи на диск, вместо выполнения какой-либо полезной работы.
То что современные системы не тормозят при наличии такой проблемы — результат многоядерности и шаманства разработчиков графических оболочек — они просто ограничивают скорость копирования. А если начнёте копировать большие файлы через командную строку, например, 'dd' или 'cp', да ещё одновременно запустите несколько экземпляров, то «сулик сразу появиться»...

У меня посточнно процессы в disk sleep висят не проявляя активности, наверное это discard.

результат многоядерности и шаманства разработчиков графических оболочек

ещё как тормозят, тут заслуга скорее ядра.

Херню написал, уровня вендузных дураков, у которых процеесс «бездействие системы» «жрёт» 98% процессора. Смекаешь? Нет? WA это то же самое, что IDLE, но при наличии при этом дисковой активности. Оно ничего не «жрёт».

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

Сам-то попробуй осознать суть своего опуса.
«Бездействие системы», оно же 'id' в терминах top'a при необходимости легко конвертируется либо в 'us', либо в 'sy'. А 'wa' ни во что не конвертируется — грубо говоря крутиться пустой цикл, который проверяет «а можно ли уже отправить очередную порцию данных на диск, или он ещё занят записью предыдущих данных». А вместо этого цикла ядро могло бы заниматься другим каким-либо делом, да в том же 'id' простаивать...
Сударь Вам бы матчасть чуток подтянуть...

Можете попробовать установить систему на базе ядра 2.6.16, вроде как это последнее ядро, на котором этой проблемы не было (или 2.6.14 ... в общем не помню точно). Там с показателем 'wa' всё в порядке и тормозов нет даже на одноядерных системах.

Лучше попробуй осознать как оно работает, вместо выдумывания опусов.

Никакой «пустой цикл» там не крутится, что можно проверить запуском программы зкргужающей все ядра. Диск использует DMA без участия процессора и сообщает ему о завершении операций прерываниями.

Стоит забыть тут о хабровской привычке репоста ламерских домыслов, и начать уже разираться в том, о чём берёшься рассуждать.

А ты думаешь, что DMA это бесконечная память?
Попробуй раскинуть мозгами: процесс накидывает в область памяти DMA данные для записи на диск и полностью заполняет эту область. И вот тут планировщик процессов в ядре такой процесс вроде должен «отодвинуть» в сторону, потому как для остальных данных нет места пока их не заберёт диск (запись-то у диска не такая быстрая). А планировщик вместо этого этот ожидающий процесс пихает «на выполнение». Этот процесс видит, что память отведённая ему в виде DMA забита под завязку и занимая процессорное время ждёт пока диск из этого DMA не выкачает данные. Вот это самое время как раз и помечается как 'wa'. Хотя при нормальном планировщике такой процесс сидел бы в очереди ожидания пока от DMA не пришёл бы сигнал, что есть свободное место. И нормальный планировщик ставил бы в очередь на выполнение такой процесс только после получения сигнала, а не «до» как сейчас происходит.
И раскинь мозгами ещё раз (только смотри не перестарайся): почему проблема проявляется только при записи на диск БОЛЬШОГО объёма данных? Да потому что этот большой объём данных забивает все доступные буферы, как на диске, так и в памяти. И проблема начинается после переполнения всех этих буферов.
Учи матчасть ещё раз...

Сколько ты уже будешь выдумывать офигенных историй, вместо того чтобы проверить в реальности, как занятый диск не влияет на время исполнения не заружающей диск, а только процессор программы?

Хочешь жить в своём виртуальном мирке, где нет ни какой проблемы — живи. Мне от этого не холодно, не жарко.
Разбирающиеся люди поймут, о чём мои офигенные истории повествуют.

Я прекрасно понимаю - ты, как вантузные хомячки считаешь, что «бездействие системы» жрёт процессор (ты это сам написал другими словами).

А дальше ты пошёл составлять оправдывающие и базирующиеся на этом легко опровергаемом экспериментом, утвержении офигительные истории. Вместо того, чтобы проверить, и убедится, что оно не соответствует действительности.

ни какой проблемы

Упомянутые выше мной проблемы есть, но они не имеют никакого отношения к вот таким вот заблуждениям, как в твоих историях.

проявляется только при записи на диск БОЛЬШОГО объёма данных? Да потому что этот большой объём данных забивает все доступные буферы, как на диске, так и в памяти

Вот это уже ближе но всё так же не имеет отношения к WA.

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

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

но тогда, это же тотальное кривожопие того, кто планировщик ОЗУ писал

Молодой человек, это не для вас писали.

Имелся в виду код в ядре.

поспешил. хер то там.
при компиляции ядра всё равно лажает.
потоков хотя 6 из 8 на 8320. и даже не особо греется.
браузер тормозит.

к браузеру вопросов у меня тоже есть. почему в 2019 году до сих пор не могут отключить дисковый кеш в браузерах?
или это к планировщику io вопрос, почему он не может закешировать тупой браузер в кеш ОЗУ?

5.1.0-pf4pf