Почему частично полное ОЗУ вызывает задержку?

Question

Почему частично полное ОЗУ (скажем, 80%) заставляет устройство сильно зависать, даже если есть место для хранения большего количества данных? То, что я ожидаю, - то, что это продолжает работать хорошо до 99%.

Я замечаю, что на мобильном телефоне больше, чем на ПК, так как он имеет меньше оперативной памяти, например, мой мобильный имеет 2 ГБ оперативной памяти; когда у меня меньше 1 ГБ свободной памяти, это сильно отстает! Почему это происходит, несмотря на то, что он все еще имеет ~ 1 ГБ для использования?

Answer 1

Здесь многое задействовано, но я постараюсь объяснить это настолько просто, насколько смогу, и способом, применимым практически к любой ОС.

Здесь есть 2 основных принципа:

1. Общая сумма всего, что должно быть в ОЗУ, и тех вещей, которые могут быть полезны в ОЗУ, почти всегда больше, чем размер ОЗУ. Вещи, которые могут быть полезны в ОЗУ, включают рабочие наборы процессов и резервный список. Последний содержит данные и код, которые когда-то были в активном использовании, но с тех пор перестали работать. Многое из этого будет использовано снова, а некоторое - довольно скоро, поэтому полезно хранить его в оперативной памяти. Эта память действует как своего рода кеш, но на самом деле она не так важна, как в категории доступной памяти. Как и свободная память, она может быть быстро предоставлена любой программе, которая в этом нуждается. В интересах производительности резервная память должна быть большой.

2. Частота использования блоков памяти далеко не случайна, но может быть предсказана со значительной точностью. Память делится на блоки, часто по 4 Кбайт. Доступ к некоторым блокам осуществляется много раз в секунду, в то время как другие блокировались без доступа в течение многих минут, часов, дней или даже недель, если система работала достаточно долго. Между этими двумя крайностями существует широкий диапазон использования. Диспетчер памяти знает, какие блоки были доступны недавно, а какие нет. Разумно предположить, что блок памяти, к которому недавно обращались, скоро снова понадобится. Память, к которой недавно не обращались, вероятно, не понадобится в ближайшее время. Многолетний опыт доказал, что это действительный принцип.

Диспетчер памяти использует преимущества второго принципа, чтобы в значительной степени смягчить нежелательные последствия первого. Для этого он выполняет балансировку, сохраняя данные, к которым недавно обращались, в ОЗУ, в то время как хранит редко используемые данные в исходных файлах или в файле подкачки.

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

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

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

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

Answer 2

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

Answer 3

Этот ответ был в основном переписан, чтобы реорганизовать структуру и сделать сообщение более понятным. Я также открыл его как ответ сообщества вики; Не стесняйтесь редактировать.

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

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

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

В то время как выделенная RAM доступна непосредственно через материнскую плату из CPU, что обеспечивает быстрое соединение, виртуальная RAM должна проходить через кабели между платой и местом расположения vRAM.

Это, однако, вызывает лишь незначительное влияние на производительность. Когда скорость подкачки к vRAM резко увеличивается (когда объем выделенной ОЗУ приближается к емкости), происходит перегрузка.

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

Допустим, вы хотите записать число 30 цифр. Вы можете либо сидеть рядом со своим экраном с помощью блокнота и писать его (используя выделенную память), либо вы помните куски по 5, бегать в следующую комнату и записывать его в свой блокнот (используя виртуальную память). Оба выполнили свою работу, но что будет быстрее?

Узнайте больше о разбивке здесь !

Большое спасибо авторам этого ответа, включая Дэниела Б, Ксеноида и Джона Бентли.

Answer 4

Помните, что жесткие диски на порядок медленнее, чем ОЗУ, а само ОЗУ не так уж и быстро (в общей архитектуре). В порядке скорости доступа (где каждая ступенька на порядок медленнее, чем та, что указана выше) у вас есть

1. Регистры процессора - На практике регистры доступны в течение 1 цикла процессора. Учитывая, что процессоры выполняют миллиарды циклов в секунду (3 ГГц = 3 миллиарда циклов в секунду), это безумно быстро.
2. Кэш процессора - зависит от уровня, но он все еще довольно быстрый (доступность 3-5 циклов для кэша L1).
3. Оперативная память (RAM) - случайная часть означает, что вы не знаете, в каком состоянии она находится, когда вы получаете к ней доступ. Подумайте о доставщике посылок, который должен остановиться, поднять посылку, пройти к двери, позвонить в дверь и ждать ответа. Может быть, вы совсем не ждете, или, может быть, вы подождете минуту или две, пока миссис Смит не перетасовывает дверь к задней части дома. С практической точки зрения, мы говорим где-то от 14-27 циклов (в зависимости от того, в каком состоянии была ОЗУ, когда мы обращались к ней).
4. Жесткий диск - здесь сейчас идет физический процесс, и, хотя он происходит настолько быстро, насколько это возможно, вы ожидаете перемещения головок и дорожек для перемещения под этими головками. С практической точки зрения, жесткий диск на 7200 об / мин может совершить оборот примерно за 4 мс, или где-то около 750 000 циклов для процессора с частотой 3 ГГц. Это медленно.

Менеджер виртуальной памяти является игроком. Он делает ставку на то, что вам не нужна вся ваша оперативная память все время, поэтому он делает обоснованное предположение и бросает кубик, что ваша программа для документов (которая находилась в фоновом режиме в течение последних 10 минут, пока вы читали это) не является действительно важно, и он толкает его на жесткий диск.

Но затем вы возвращаетесь к документу! Теперь VMM должен загрузить все эти данные обратно с жесткого диска. Хуже того, если у вас мало оперативной памяти, теперь нужно перенести другие данные (больше азартных игр) на жесткий диск, чтобы освободить используемое пространство. Linux любит жить на грани. Он заполнит большую часть оперативной памяти часто используемыми данными (отлично подходит для серверов с небольшим количеством процессов).

Answer 5

Это связано с тем, что ОС должна выполнять много операций подкачки страниц (загрузка частей активных программ) и подкачки (перемещение данных из ОЗУ на HD и наоборот), чтобы поддерживать работу программного обеспечения. Когда нужно будет загружать новые страницы, которым может потребоваться больше места, чем 20% свободных ресурсов, ОС придется выгрузить существующие страницы в ОЗУ, которые, по ее мнению, в ближайшее время не будут использоваться. Особенно при запуске других программ. Обмен и возврат в страницы занимает много времени и резко снижает производительность вашего ПК, потому что вы сейчас работаете на скорости HD, а не RAM.

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

Answer 6

Поразительные ответы в значительной степени прибивают это. Если вы можете, вы можете минимизировать, насколько быстро это происходит, уменьшив перестановку (сколько оперативной памяти система будет использовать, прежде чем перемещать объекты в пространство подкачки). Я хотел бы, чтобы системы оставались вне обмена, пока оперативная память не достигнет 99% для серверных приложений, поскольку значение по умолчанию фактически означало бы, что мне нужно было бы кодировать вещи, чтобы использовать только 80% оперативной памяти, чтобы использовать преимущества кэширования без наказания за подталкивание система в пространство подкачки.