почему часть моей области подкачки использует, когда у меня все еще есть неиспользованная RAM?

Больше любопытства, чем проблема; и, я признаю, что-то вроде смущающе основного вопроса:

Я заметил, что во многих случаях, в моей машине Linux у меня будет ~500MB области подкачки используемым, даже при том, что у меня есть ~600MB неиспользованной RAM.

Мое наивное высокоуровневое понимание было, область подкачки не умирает, пока RAM не исчерпывается.

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

Который приводит к вопросу, почему ядро заблаговременно использовало бы область подкачки? Эта часть некоторого настраивающего алгоритма производительности? Это выгружает к дисковым частям памяти, которую это считает маловероятно, чтобы быть полученным доступ (схема LRU, возможно)? Если так, только имело бы смысл оставлять все в RAM, и только при приближении к исчерпанию, затем и только затем подкачивать части LRU от RAM до области подкачки?

Я должен разъясниться, мой сервер Linux имеет 2 ГБ RAM и 2 ГБ области подкачки.

9
задан 04.03.2010, 09:30

4 ответа

Неиспользованная часть RAM на самом деле используется в качестве кэша жесткого диска. Если Вы думаете об этом, Вы на самом деле читаете части своего диска чаще, что Вы получаете доступ к некоторым частям RAM. Который имеет смысл помещать эту RAM на диск при использовании RAM для кэширования данных жесткого диска.

11
ответ дан 07.12.2019, 13:08

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

Например, скажем, Вы хотите открыть большое изображение. Когда изображение загружается, требуется 300 МБ RAM. Если ядро использует всю RAM, это может, загружение Вашего изображения требует, чтобы ядро передало 200 МБ от RAM до диска. Если это заранее освободило RAM заранее, Вы сохраняете несколько миллисекунд.

7
ответ дан 07.12.2019, 13:08

2 причины:

  1. (@dtrosset) Linux подкачает неиспользованные биты программ для предоставления большего количества кэша и буферов.
  2. Вы, возможно, использовали больше памяти в прошлом и выгрузили некоторый материал, и это не было загружено, потому что это не использовалось, даже при том, что, независимо от того, что вытеснено это теперь пошло.
7
ответ дан 07.12.2019, 13:08

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

Чрезмерные обязательства памяти и боязнь уничтожителя OOM не являются необходимыми частями опыта Linux, как бы то ни было. Просто установка sysctl параметра vm/overcommit_memory к 2 выключает превышать возможности поведение и сохраняет уничтожителя OOM навсегда в безвыходном положении. Большинство современных систем должно иметь достаточно дискового пространства для обеспечения вполне достаточного файла подкачки для большинства ситуаций. Вместо того, чтобы пытаться помешать любимым процессам уничтожаться, когда перегруженная память заканчивается, могло бы быть легче только избежать ситуации в целом. [Отсрочка от уничтожителя OOM]

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

Поскольку процессам дарят их собственное адресное пространство или "представление" (это - то, как подкачка работает во-первых), ядро имеет много дрейфа в том, как это управляет этим. Используя пример ветвления также от статьи, связанной выше, так как это, намного более вероятно, будет иметь страницы общей памяти, чем он, должен недавно выделить большой объем неиспользованной памяти, память может быть выделенной копией на записи, увеличив количество использования подкачки. Когда это на самом деле записано в (которого не могло бы произойти), затем это "фиксировавшая подкачка" может быть заменено любой неиспользованной RAM (затем увеличивающий использование RAM и уменьшающий использование подкачки). Вообразите процесс с 500 МБ выделенным который ветвления на машине со всеми или почти всей RAM используемый. Если существует 500 МБ, доступных в подкачке (и дисковое пространство является дешевым, насколько большой 1% сегодняшних дисков емкостью? :P), никакая память еще не должна быть скопирована (и возможно никогда), но ядро может гарантировать, что те выделения "успешны" и продолжают использовать страницы общей памяти максимально долго.

Таким образом возможности уничтожителя OOM избегают, и намного более просто разработать большую часть программного обеспечения учитывая, что выделения памяти (включая "неявные" выделения через что-то как ветвление) или успешно выполняются или сразу перестали работать с практическим пониманием, что, если память должна быть подкачана затем, она могла бы повлиять на производительность. То влияние является почти всегда небольшим, но в худшем случае ведет для свопинга перегрузки (все еще иногда предпочтительный для прямого катастрофического отказа ядра или уничтожителя OOM).

Хотя я не знаю точные детали того, как диспетчер памяти Linux работает, этот ответ является моим собственным обобщенным пониманием и что я не забываю читать за эти годы. Я попытался переиздать этот ответ, таким образом, минимальное понимание дизайна ОС требуется (это значительно сложно и не что-то, что я ужасно интересуюсь мной), но это, кажется, околачивается немного; сообщите мне, видите ли Вы, как это могло быть улучшено. На держащей руке это не мог бы быть такой смущающе основной вопрос.

1
ответ дан 07.12.2019, 13:08

Теги

Похожие вопросы