в дополнение к другим ответам, вы можете настроить Linux так, чтобы требовалось резервное копирование для любой выделенной памяти, даже если программы не используют ее.
перерасход памяти и боязнь убийцы OOM не являются необходимыми частями опыта Linux, однако. Просто установка параметра sysctl vm / overcommit_memory в 2 отключает поведение overcommit и держит убийцу OOM навсегда в страхе. В большинстве современных систем должно быть достаточно места на диске, чтобы большинство ситуаций. Вместо того, чтобы пытаться уберечь процессы pet от уничтожения при исчерпании избыточной памяти, может быть проще просто избежать ситуации в целом. [передышка от ООМ убийцы]
Если программа выделяет память, ядро может просто несколько страниц своп как совершенные. Этот признак хранится в менеджере памяти ядра, фактическое дисковое пространство еще не затронуто. Пока эта память не используется, на самом деле ничего не имеет чтобы быть заменены. Если они никогда не используются, то использование подкачки будет колебаться, не влияя на производительность.
поскольку процессы представлены с их собственным адресным пространством или "представлением" (в первую очередь так работает swap), ядро имеет большую свободу действий в том, как оно управляет этим. Используя пример форка также из статьи, связанной выше, так как это гораздо более вероятно, чтобы иметь общие страницы памяти, чем это недавно выделить большой объем неиспользуемой Памяти, памяти может быть выделенное копирование при записи, увеличивающее количество использования подкачки. Когда он фактически записывается (что может не произойти), то этот "фиксированный своп" может быть заменен любым неиспользуемым ОЗУ (затем увеличение использования ОЗУ и уменьшение использования свопа). Представьте себе процесс с выделенным 500 МБ, который разветвляется на машине со всей или почти всей используемой оперативной памятью. Если в swap доступно 500 МБ (и дисковое пространство дешево, насколько велик 1% современных дисков ТБ? : P), никакая память не должна быть скопирована (пока, и, возможно, никогда), но ядро может гарантировать, что эти выделения "успешны" и продолжают использовать страницы общей памяти как можно дольше.
таким образом, возможность убийцы OOM избегается, и гораздо проще спроектировать большинство программ с предположением, что выделение памяти (включая "неявное" выделение через что-то вроде fork) либо успешно, либо не сразу, с практической реализацией, что если память должна быть заменена, то это может повлиять на производительность. Это воздействие почти всегда небольшое, но в худшем случае приводит к своп-трэшу (все же иногда предпочтительнее прямого сбоя ядра или убийцы OOM).
хотя я не знаю точных деталей того, как работает менеджер памяти Linux, этот ответ-мое собственное обобщенное понимание и то, что я помню, читая на протяжении многих лет. Я попытался повторно отредактировать этот ответ, поэтому требуется минимальное понимание дизайна ОС (это значительно сложно, а не то, что меня очень интересует), но это, кажется, бродят немного; пожалуйста, дайте мне знать, если вы видите, как это может быть улучшено. На сжимающей руке это может быть не такой смущающе простой вопрос.
Komp
3677
