Почему обсуждения «подкачки» ведут себя так, будто информация может находиться только в одном месте одновременно?

Question

Я читал о настройке «подкачки» в Linux, которая контролирует, насколько агрессивно ядро ​​выполняет замену памяти приложений на диск, когда они не используются.Если вы загуглите этот термин, вы получите много страниц, таких как этот обсуждаем плюсы и минусы.Вкратце аргументация звучит так:

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

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

Для меня этот аргумент не имеет смысла.Если у меня есть неактивное приложение, которое использует массу памяти, почему ядро ​​не выгружает свою память на диск И не оставляет еще одну копию этих данных в памяти?Кажется, это дает лучшее из обоих миров:если другому приложению нужна эта память, оно может немедленно запросить физическую оперативную память и начать запись в нее, поскольку другая ее копия находится на диске и может быть заменена обратно, когда неактивное приложение просыпается.А когда исходное приложение просыпается, любые его страницы, которые все еще находятся в оперативной памяти, можно использовать как есть, без необходимости удалять их с диска.

Или я что-то упускаю?

Answer 1

Согласно этому 1 именно это и делает Linux.

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

Answer 2

Если у меня есть неактивное приложение, которое использует массу памяти, почему ядро ​​не выгружает свою память на диск И не оставляет еще одну копию этих данных в памяти?

Допустим, мы это сделали.Мы записали страницу на диск, но оставили в памяти.Через некоторое время другому процессу понадобится память, поэтому мы хотим выкинуть страницу из первого процесса.

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

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

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

Так стоит ли это делать?Честно говоря, я не знаю.Я просто пытаюсь объяснить, почему оставить страницу в памяти не так уж и очевидно, как кажется.

(*) Все это очень похоже на механизм копирования при записи, который используется, когда процесс разветвляется().Дочерний процесс, скорее всего, выполнит всего несколько инструкций и вызовет exec(), поэтому было бы глупо копировать все родительские страницы.Вместо этого у ребенка отбирают разрешение на запись, и ребенку просто разрешают бегать.Copy-On-Write — это выигрыш, потому что ошибка страницы почти никогда не возникает:ребенок почти всегда немедленно вызывает exec().

Answer 3

Даже если вы выгрузите память приложения на диск и сохраните ее в памяти, вам все равно придется решать, когда приложение следует считать «неактивным», и именно это контролируется подкачкой.Пейджинг на диск требует больших затрат с точки зрения ввода-вывода, и не стоит делать это слишком часто.В этом уравнении есть еще одна переменная: Linux использует оставшуюся память в качестве дисковых буферов/кэша.

Answer 4

Первое, что делает виртуальная машина — очищает страницы и перемещает их в чистый список.
При очистке анонимной памяти (вещи, которые не имеют фактического резервного хранилища файлов, вы можете видеть сегменты в /proc//maps, которые являются анонимными и не имеют за собой хранилища vnode файловой системы), первое, что собирается сделать виртуальная машина, это возьмите «грязные» страницы и «очистите», а затем запишите содержимое страницы на своп.Теперь, когда виртуальная машина испытывает нехватку полностью свободной памяти и беспокоится о своей способности предоставлять для использования новые свободные страницы, она может просматривать список «чистых» страниц в зависимости от того, как недавно они использовались и какой тип памяти. они переместят эти страницы в список свободных.

Как только страницы памяти помещаются в список свободных, они больше не связаны с содержимым, которое у них было раньше.Если программа ссылается на ячейку памяти, которую страница обслуживала ранее, программа выполнит серьезную ошибку, и страница (скорее всего, совершенно другая) будет извлечена из списка свободных, и данные будут прочитаны в страницу с диска.Как только это будет сделано, страница по-прежнему останется «чистой», поскольку она не была изменена.Если виртуальная машина решит использовать эту страницу при обмене на другую страницу в ОЗУ, тогда страница снова будет «грязной», или если приложение запишет на эту страницу, она будет «грязной».И тогда процесс начинается снова.

Кроме того, возможность подкачки довольно ужасна для серверных приложений в деловой/транзакционной/онлайн-среде/среде, чувствительной к задержкам.Когда у меня есть компьютеры с 16 ГБ ОЗУ, на которых я не использую много браузеров и графических интерфейсов, я обычно хочу, чтобы все мои приложения были почти закреплены в памяти.Большую часть моей оперативной памяти составляют Java-кучи размером 8–10 ГБ, которые я НИКОГДА когда-либо, и весь доступный мусор — это такие процессы, как mingetty (но даже там страницы glibc в этих приложениях используются другими приложениями и фактически используются, поэтому даже размер RSS этих бесполезных процессов в основном разделяется, используется страницы).Обычно я не вижу более нескольких 10 МБ из 16 ГБ, фактически очищенных для замены.Я бы посоветовал очень, очень низкие значения подкачки или нулевую подкачку для серверов — неиспользуемые страницы должны составлять небольшую часть общей оперативной памяти, и попытка вернуть этот относительно небольшой объем оперативной памяти для буферного кэша рискует поменять местами страницы приложений и получить удары по задержке. работающее приложение.