Когда линь перестанет виснуть при исчерпании памяти? (2022)

Надо успеть пошутить, а то вдруг что.

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

Для меня это эталонный переусложнённый bloatware от астронавтов архитектуры, который потерпел провал по сути.

Для меня это эталонный переусложнённый bloatware от астронавтов архитектуры, который потерпел провал по сути

Ты про гуй в ядре? Его же давно вынесли в системную службу, не?

Ты про гуй в ядре?

Не только. В ядре NT всё слишком переусложнено и требует много кода даже для больших вещей. Под провалом я в первую очередь понимаю провал ядра NT на рынке серверов и встраеваимоего ПО, оказавшаяся бесполезной концепция подсистем. Сейчас везде кроме x86 десктопа доминирует Линукс.

Его же давно вынесли в системную службу, не?

К сожалению нет. win32k.sys всё ещё в ядре. dwm.exe – это только композитор, логикой окон он не занимается.

Ну, что, как идут дела, удалось ли составить план первоочередных мероприятий по борьбе за дела добра?

Михал Хоко поясняет https://lore.kernel.org/lkml/YbcNUEZ08lmbv0RM@dhcp22.suse.cz/

Когда линь перестанет виснуть при исчерпании памяти? (2022)

У меня не виснет, что я делаю не так?

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

Но принципиально не отключаете его?

В линуксе fork() нет, есть clone() и разработчики монстров типа java, с garbage collection, который и создаёт проблемы, могли бы заморочиться.

Я считаю оптимистичное выделение памяти никсами фундаментально провальным. Причем, с этим ничего не сделать, потому что есть fork, который делает copy-on-write и под него нельзя резервировать память.

Дело не в overcommit / CoW, на который тут крошат батон уже N-ный год. У венды (и, вангую, мака), ВНЕЗАПНО, всё то же самое - процесс на 90%+ начинается с shareable working set и private растёт по мере инициализации. Проблема именно в отсутствии логики защиты shared pages от сброса, что позволяет любому однострочнику на баше загнать систему в вечный цикл чтения страниц с накопителя.

Не всё так просто. Много софта и библиотек спроектированы под overcommit, например современные аллокаторы памяти.

Может быть, но мне такой не встречался (или я его старательно избегаю). С 2005 года vm.overcommit_memory=2; vm.overcommit_ratio=80; swap около 10 Гб.

У венды (и, вангую, мака), ВНЕЗАПНО, всё то же самое - процесс на 90%+ начинается с shareable working set и private растёт по мере инициализации. Проблема именно в отсутствии логики защиты shared pages от сброса, что позволяет любому однострочнику на баше загнать систему в вечный цикл чтения страниц с накопителя

Сказанное тобой актуально только при активном свопе в винде. Если своп выключен, то отказы выделения памяти начинаются в районе 75-80%. Причем, ошибки эти получает именно тот, кто память выделяет, а не как в лине - случайный процесс отдувается за всех.

Сказанное тобой актуально только при активном свопе в винде

Лол, нет. Машинерия запуска процесса на исполнение от наличия свопфайла не зависит вообще никак.

Если своп выключен, то отказы выделения памяти начинаются в районе 75-80%.

Кому ты затираешь? Я последний раз своп использовал на постоянку (а не как разовое решение для особо глючного софта) в прошлом тысячелетии. Если память выжирается, то она выжирается на все 100% и отказы по ней идут любому процессу, который её запрашивает. Просто для показа менеджера процессов нужны считанные страницы памяти в private working set, поэтому три кнопки отрабатывают и можно спокойно убить самого опухшего.

Ну, и самое главное, замапленные read only страницы из {ntdll, kernel32, user32, etc}.dll не выброшены из памяти, поэтому процессы как минимум могут шевелить дескрпиторами и вводо-выводить.

Если память выжирается, то она выжирается на все 100% и отказы по ней идут любому процессу, который её запрашивает

Это да. Но в большинстве случаев это значит, что какая-то программа упадет по assert-у или Access Violation, что как бы эквивалентно OOM-killer-у.

замапленные read only страницы из {ntdll, kernel32, user32, etc}.dll не выброшены из памяти, поэтому процессы как минимум могут шевелить дескрпиторами и вводо-выводить

Так и я об этом. Правда, насколько мне известно, никаких ограничений на свапание системных либ в винде нет — само устройство винды приводит к фактическому резервированию 20-25% памяти под кэши, плюс невыгружаемая память ядра (порядка 100 МБ для семерки).

К слову, я сам на винде пришел к необходимости иметь своп, чтобы все-таки доходить до 90-95% выделения физической памяти, поскольку обычно в системе все-таки есть данные, которые можно безболезненно выкинуть в кэш и они не будут читаться лишний раз, но своп должен быть как раз порядка 20-25% размера физической памяти.

насколько мне известно, никаких ограничений на свапание системных либ в винде нет — само устройство винды приводит к фактическому резервированию 20-25% памяти под кэши

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

идея давно в фундаменте… зарыта…
писать качественный продуманный софт комммммэрчески не выгодно. жри то шо дают

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

помнится мне, тут один персонаж, кажись хакавлад, толкал патчи, у меня на ноуте с 4 гигами норм даже при лютом свапе...

А какая операционная система не зависает, когда исчерпывается свободная оперативная память?

256 GB

Лiл.

Windows

И давно?

Ну вообще да. Как минимум с 2000-го года.

Начиная с win95

sudo apt install earlyoom

Хорошая шутка.

Так не виснет же, если своп есть. А маздай без свопа что не виснет?

У меня новая мегагипотеза.

Факты таковы:
1) иногда UI «подвисает» и долго отвечает
2) иногда лампочки клавиатуры реагируют на нажатия не сразу (например numlock зажигается/выключается через 10 минут после нажатия)
3) иногда курсор мыши ездит по экрану и можно выделять прямоугольники на десктопе, но при этом окон как будто бы не существует.

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

Моя гипотеза заключается в том, что причина всех этих явлений иная, и каким-то образом связана с багами в Xorg сервере. И/или ещё каком-то софте типа «шин сообщений».

Факты таковы:
1) иногда UI «подвисает» и долго отвечает
2) иногда лампочки клавиатуры реагируют на нажатия не сразу (например numlock зажигается/выключается через 10 минут после нажатия)
3) иногда курсор мыши ездит по экрану и можно выделять прямоугольники на десктопе, но при этом окон как будто бы не существует

Факты таковы: SSD диск загружен на 100%, и при этом диск не поврежден — система прекрасно загружается заново, более того, у меня почти получалось логиниться в консолечку — что, очевидно, никак не связано с иксами.

Консоль тоже тормозит, это верно.

Но может всё-таки дело не в памяти,
а тогда в работе ядра с дисковой подсистемой?

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