Я знаю, что это вброс, но на такое лучше ответить.Есть такая штука как Memory Overcommitment. Процесс попросил больше оперативной памяти чем вообще есть в системе и мы ему эту несуществующую память выделяем, предполагая, что процесс её запросил, но пользоваться ею не будет. Это особенно полезно когда речь идёт о виртуализации. Хост может выдать больше оперативной памяти виртуалкам несмотря на то что столько нет из расчёта, что установленные верхние лимиты памяти для виртуалок не достигаются. Хост даже может произвести дедупликацию некоторых страниц памяти, если виртуалки однотипные. Однако, если мы достигли пределов и истратили всю возможную память в системе, то чтобы не упасть, нужно что-то убить и вот тут начинает требоваться некоторый OOM-killer, который решит, что убить и убьют. И в этом-то и проблема, процесс будет завершен и всё.
Так вот! Ничего подобного в Windows нет и не было в помине никогда и вообще не будет. Windows не имеет функционала Memory Overcommitment, вместо этого у них там Dynamic Memory. А это концептуально другая штука. Windows может выделить процессу больше памяти чем есть физической оперативной памяти из расчёта, что в случае переполнения будет использоваться виртуальная память на диске тот самый pagefile.sys. Размер этого файла устанавливается в динамических пределах от-до и по умолчанию не фиксирован. Предельно возможные значения зависят от свободного места на диске под этот файл. В случае, если процесс запросил память, которой нет в системе и действительно начал пользоваться всей этой памятью и исчерпал физическую, то система начинает активно свопиться. Разные версии ОС делали это по-разному. Тролли выше писали о жутких проблемах зависания всей системы при таком свопе во времена XP - это правда, но уже в 7 это исправили. Во времена Windows 10, однако, добавили еще одну проблему с магазином и UWP. В 10 есть особые сервисы, и процессы которые выполняют служебную роль только для магазинных приложений или работают преимущественно в фоновом режиме. Dynamic Memory в этом случае сразу отправляет такой процесс в приостановленный режим в своп до тех пор пока к нему не обратятся, чтобы он не занимал память. В этом случае при запуске системы на магнитооптических дисках типа WD Green система сойдёт с ума при работе с диском из-за динамической памяти. Проблема, конечно, решается фиксацией размера файла pagefile.sys, система перестанет насиловать этот диск расширяя и увеличивая виртуальную память и загрузка и логин будет длиться не полчаса, а как обычно.
Вообще вся эта идея с нехваткой памяти имеет два решения
1) Запустить толстый процесс и убить, когда не хватит памяти
2) Не запускать толстый процесс понимая, что под него нет памяти.
Windows выбирает второй вариант, она просто не даст работать в случае нехватки памяти, будет выводить окна, запрещающие запускать новые процессы и будет просить пользователя самостоятельно убить старые. В случае с виртуализацией система та же. Их Hyper-V не может в overcommitment и не собирается. Тоже имеет специально оформленный своп и оверкоммитит только в его пределах.
> винда была лучше линукса - так это способность грамотно из коробки решать проблемы с переполнением памяти.
Они оба грамотно работают, просто настолько по-разному, что даже сравнивать нельзя. Тёплое и мягкое.
У Линукса есть ряд задач в этом направлении, опять же:
- инерактивно предоставить эту службу пользователю в интерфейс,
- назначить корректный дефолт, подходящий статистически под большую часть установок дистрибутива
- предоставить API в юзерспейс для управления
Но это всё очень высокоуровнево и пользователеориентировано, раньше жили без этого, а теперь линукс во всех докерах, серверах и облаках и нужен очень многим. А "многие" не привыкли настраивать что-то где-то глубоко... ну и дальше по тексту.
