12309

Enjoy your open source!

А чего ты хотел от студенческой поделки?

vm.dirty_bytes и vm.dirty_background_bytes.

Записывал сегодня с помощью winusb iso-образ.

Малополезно в случае съемных жестких дисков. Таки единственным универсальным способом что-то записать для нормального бута является UltraISO.

На правах оффтопика.

По сути, шло копирование с помощью ntfs-3g.

ntfs-3g

this

вангую аппаратно-программный баг, на который разработчики ядра не обращают внимания.

возможно в стане конкурентов более щепетильно отнеслись к данному вопросу или проконсультировались у производителя чипсетов :)

за все время разговоров про 12309 ни разу не видел его, хотя юзал разные воркстейшены и сервера. бешенные LA видел, 12309 не видел. уверен проблема на стыке какого-то странного железа (контроллера) который я не юзал и его дров.

Говнокодеры потому что.

какого-то странного железа (контроллера)

Да, интеловские чипсеты это очень странное железо. Прям экзотика экзотическая.

на стыке какого-то странного железа (контроллера)

Asrock h97 Anniversary

Enjoy your open source!

Последний раз я встречал 12309 на Windows при копировании кучи файлов на 100МБ/c-сети на слабом компьютере. Так что не всё так однозначно.

тем не менее , странности и выгорания в юсб именно у интеля широко освещались.

поэтому... что-то в консерватории правят регулярно, но оно опять октавит, протекает и хрипит.

Регулярно ловится, io в linux великолепное :) Не знаю как в венде, а даже в сра^W испорченной макоси такого нет :)

В венде это штатное поведение.

Главное эту мантру повторять почаще.

Скажи ещё, что это не так.

Да не работают эти параметры. Если ты выкрутишь их в околоноль, то лимит dirty memory забьётся за секунду, а не за минуту, и система всё равно встанет раком.

winusb iso-образ

localhost.localdomain 4.7.2-1-ARCH

Вот как-то так.

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

Ну вот не скажи. Когда сбрасываю файлы на флешку, запускаю watch -n 0,3 grep Dirty proc/meminfo и вижу, что когда в dirty набивается около гига, цифры иногда замирают на секунды. Внезапно ядро не хочет писать? Что-то странное происходит.

Если поставить лимит на 16 МБ, ничего подобного не видно.

У меня есть немного другой опыт. Винда постоянно тормозила на ровном месте. На двух абсолютно разных компах - ноут на жирном интеле и полудесктоп на десктопном же интеле. Тогда узнал про всякие страшные dpc latency и прочее непомню что.

С другой стороны, тут меня преследует баг с копированием файлов по кабелю на андроид. Периодически возникает со старым телефоном. Графика, клавиатура, мышь - всё намертво виснет до окончания процесса копирования. Проявляется не всегда и в последнее время всё реже. Опять же, на нескольких разных компах.

я как-то раз в живую встретил он?

this

А как может userspace утилитка вешать систему?

Слишком много жрёт. У меня так фирефохэ часто делает (обычно при соучастии флеша).

У меня ntfs-3g жрет не более 20% одного процессорного ядра, а всего 4 ядра.

Когда был на gentoo эти sysctl действительно помогали бороться с 12309, однако, при этом начинал сегфолтиться emerge-deltawebsync или как его там.

универсальным

UltraISO

Туда ли ты зашёл, петушок?

Какие тут клёвые пятизвёздочники проскакивают. ls /proc/sys/vm, что ли. Ну и man sysctl; man sysctl.conf заодно

К сожалению, да. Даже для того, чтобы толком бутнуться со съемного жесткого диска, пришлось привлекать валявшийся рядом комп с Windows и UltraISO, ибо линуксовыми методами (копирование, WinUSB, dd) Windows ставиться, выдавая ошибку на то, что у нее драйверов на девайс, с которого оно уже бутнулось (!), нету.

Повторюсь, на правах оффтопика.

Windows ставиться

Хехехе, буквоед на свои же грабли наступил :)

Повторюсь, на правах оффтопика

У оффтопика здесь нет прав.

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

Круто. Теперь ты специалист. Ты видел один комп с вендой.

Хехехе, буквоед на свои же грабли наступил :)

Ой, лол, спасибо, не замечено.

У оффтопика здесь нет прав.

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

Запросто оно это делает. Ещё может повесить системку при записи в свап.Это вообще жестоко. На зузе я до 13.1 и не сталкивался с такой проблемой, а оказывается она живее всех живых. Ну и при чтении или записи с использованием ntfs-3g стабильно получаем подвисания системки.

Это пятикратный звиздец, товарищи.

Это тонкий намёк на то, что неплохо бы и значения указать, при которых 12309 не проявляется. Ибо пост выглядит как 'запустить это, чтобы сделать хорошо'.

Да, это известная проблема GNU/Linux. На FreeBSD такого нет.

Как-то ловил на распаковке архива с кучей файлов в mc. Но это было давно.

Немного оффтопа. А как лечить когда компиляция в 5 потоков выжирает 8Гб памяти и система встает раком? Даже повторить могу, сборкой vigra в 5 потоков. Да, выставил в 2 потока сборку и всё нормально, но меня не устраивает ситуация, когда система перестаёт отзываться из-за этого и приходится на ресет жмакать. Пусть к компилятору пушной зверь приходит, но чтобы даже tty переставали переключаться это как-то совсем не дело.

Компилировал vigra-1.11.0_1 на AMD Phenom II X4 810/11,5ГБ ОЗУ именно в 5 потоков. Десктоп Xfce4 на FreeBSD 11 - никаких тормозов не ощущал.

Ну, я, кстати, 12309 в итоге встречал только на интеловских контроллерах. Когда доводилось тягать сотни гигабайт с одного харда на другой - на моём ПеКа никаких лагов, спокойно пользовался системой, смотрел кинцо и слушал музыку.

А вот когда копировал аналогично с харда на хард на ПК с интел - таки были адовые лаги, курсор мышки шевелился с большой задержкой, ни про музыку, ни про видео речи быть не может. Такие дела. Был 2012 год, ПК - intel i5 какой-то на материнке ASRock. Там ещё у одного компа, на который ставили 4 плашки ОЗУ, была бракованная материнка. Стартует с 1-2-3 плашками, с 4-мя не стартует. Поменяли по гарантии - новая плата - тот же результат. Поменяли ещё раз - та же фигня. Перепрошил - не помогает. В итоге сдал ASRock, купил Asus на 500 рублей дороже и всё заработало. Так что может косяк в материнке был - я хз.

при копировании фильма с сети или записи на флешку не удавалось. А линукс делал это легко и непринужденно.

Как вы это делаете? Я тягал сотни гигабайт между хардами, по сети с одного линукса на другой - нету там никаких лагов, никаких «вставаний колом» и прочей фигни.

Просто ты не умеешь считать подходящий vm.dirty_background_bytes, который выставляется по большему количеству кэша на контроллере, на рейде или на пуле, а если кэш небольшой, а памяти много, то просто выставляется выставляется в два раза больше размера кэша.
Например если у 64 мб кэша, то ты выставляешь vm.dirty_background_bytes в 1/4, т.е в 16777216, а vm.dirty_bytes в 67108864 (64мб)
На системах с большим количеством памяти, обычно значение само выставляется достаточно оптимально, а вот на десктопах, значение практически всегда очень маленькое. Но в случае ТС проблема действительно в ntfs-3g, скорей всего.

с помощью ntfs-3g

Это который через fuse работает, то бишь через цепочку memcpy() данные «копирует»? Да, был такой багг, о нём писали N-дцать лет назад...

Купи ещё 8 гб в магазине.

Просто ты не умеешь считать подходящий vm.dirty_background_bytes

Не умею, но я безрезультатно перебирал очень много значений.

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

И что это даст?

а вот на десктопах, значение практически всегда очень маленькое

На десктопах дефолт даёт гораздо большие значения, чем у тебя.

Вчера собирал с -j5, каждый процесс c11pp(как-то так называется) отожрал по 1,5Гб и повесил мне всю машину. Как говорили в 90-е, "И тремя пальцами не поднимешь".

ЗЫЖ только счас заметил что у тебя бздя, а это скорее всего исключительно линуксовая проблема.

Купи ещё 8 гб в магазине.

Так тогда захочется 8ядерный проц и собирать в 10 потоков и все равно закончится память и всё повиснет. Вопрос то в том чтобы к виновнику OOMKiller приходил, а не система колом вставала.

И что это даст?

Когда dirty забиваются все становится очень печально, особенно для бд.

На десктопах дефолт

Большинство дефолтных sysctl значение не оптимальны, и их значения были бы актуальны для оборудования 6-8 лет давности или для калькуляторов, но потому-что ядро linux нужно запускать в том числе и на всяком embedded значения переползают из одной версии ядра в другую.

а вот на десктопах, значение практически всегда очень маленькое

На десктопе обычно по дефолту dirty_ratio 20-10, что очень конкретно много для 8 и более гб рам.

Там ещё у одного компа, на который ставили 4 плашки ОЗУ, была бракованная материнка. Стартует с 1-2-3 плашками, с 4-мя не стартует. Поменяли по гарантии - новая плата - тот же результат. Поменяли ещё раз - та же фигня. Перепрошил - не помогает. В итоге сдал ASRock, купил Asus на 500 рублей дороже и всё заработало. Так что может косяк в материнке был - я хз.

Это от контроллера ОЗУ, находящегося в процессоре, зависит и в меньшей степени от платы и модулей памяти. У меня такая же ситуация: Phenom II X4 не работает с 4 модулями памяти (косяк в контроллере самого процессора), зато нормально работает с 2-я и 3-я модулями (сейчас у меня 3x4ГБ, 512МБ из которых идёт на встроенное видео AMD 785G).