Что значит кэширование оперативной памяти
Кэшировано много оперативной памяти Windows 10
Можно увидеть, что кэшировано много оперативной памяти в диспетчере задач Windows 10. Пользователям не совсем понятно что это за память. И как большое её количество может повлиять на производительность. Думаю понятно, чем больше ОЗУ тем меньше проблем.
Эта статья расскажет, что такое кэшированная память и почему её очень много в Windows 10. Во время эксперимента файл подкачки был отключён на всех дисках. Многие процессы, службы, библиотеки и программы, при включении компьютера, уже попадают в оперативную память.
Что значит кэшировано памяти
Этот объём памяти (включает зарезервированную и изменённую память), в которой содержаться кэшированные данные и код, предназначены для мгновенного доступа и использования процессами, драйверами и операционной системой.
Например, в диспетчере задач показывает кэшировано 6.0 Гб. В строке Структура памяти смотрим Зарезервировано (5832 Мб). Это и есть память, содержащая кэшированные данные и код, которые прямо сейчас не используются.
В первую очередь система использует свободную память. При нехватке памяти, кэшированная будет переводиться в свободную. Размер кэша уменьшается и менее нужные (давно используемые) данные очищаются.
Монитор ресурсов имеет более подробное описание. Это зарезервированная память, в которой содержаться кэшированные данные, и которая недоступна для использования. При необходимости память освобождается.
Важно! Операционная система установлена на твердотельный SSD накопитель. Сразу исключаем версии с использованием виртуальной памяти Windows 10. Файл подкачки полностью отключён на всех дисках. И все нужные данные кэшируются непосредственно в ОЗУ.
Как очистить кэшированную оперативную память
Удалите неиспользуемые приложения
Все неиспользуемые приложения, особенно те, которые добавляются в автозагрузку, попадают в память. В системе множество программ, которые пользователи не используют, кэшируются, занимают ОЗУ. Вспомните только не убираемую автозагрузку uTorrent в Windows 10.
Запретите использование данных для открытия приложений после перезапуска или обновления. В новой версии параметр назыв. Автоматически сохранять мои перезапускаемые приложения при выходе из системы и перезапускать их после входа.
Много писали о тонкой настройке автозапуска программ Windows 10. Перейдите в расположение Параметры > Приложения > Автозагрузка. И выключите запуск всех ненужных программ перетягиванием ползунков.
Отключение ненужных служб
В системе с каждым обновлением становиться всё больше и больше служб. Хотя для обычного пользователя далеко не все они нужны. Смотрите, как отключить на примере службы криптографии. Более подробно: оптимизация и ускорение Windows 10 для слабых ноутбуков.
Откройте управление службами выполнив команду services.msc в окне Win+R. Теперь достаточно изменить тип запуска ненужной службы на Отключено. Внимательно читайте описание службы, которую Вы отключаете и смотрите её зависимости.
Очистка оперативной памяти
Самый простой способ очистки оперативной памяти — это перезагрузка компьютера. Все данные, которые кэшируются непосредственно в ОЗУ будут очищены. Включение компьютера повторно покажет ситуацию с количеством занятой памяти.
Можно воспользоваться различным софтом для очистки оперативной памяти. В ближайшем будущем такая функциональность будет непосредственно в ОС. Смотрите подробней: как очистить оперативную память на Windows 10.
Содержание:
↑ Кэшированная оперативная память
Такие разные кэши
Перед тем как приступать к разбору обозначенного вопроса, следует сказать о том, что кэши бывают разные. Есть всем известный браузерный кэш — каталог файловой системы, в котором веб-обозреватели хранят временные данные; не менее известным типом кэша является располагающийся на физическом жёстком диске файл подкачки, в который система сбрасывает непомещающиеся в оперативную память данные; существуют и так называемые промежуточные кэши, например, служащая буфером между ОЗУ и центральным процессором кэш-память, реализованная в виде высокоскоростной микросхемы SRAM. Рассмотрим принцип её работы чуть более подробно.
Что такое кэш процессора, и как он работает
Когда ЦП обращается к оперативной памяти, чтобы считать или записать в неё данные, он сначала идентифицирует ячейку, с которой собирается работать. Для этого он формирует и отправляет в память запрос, RAM же его обрабатывает и открывает доступ процессору к хранящимся в соответствующей ячейке данным. Эта процедура занимает некоторое время, а поскольку процессор гораздо шустрее оперативной памяти, он вынужден ждать ответа от ОЗУ. Чтобы ускорить получение процессором данных из оперативной памяти, была придумана так называемая быстрая оперативная память, или иначе кэш-память.
Таким образом, кэшированная память сокращает время отклика и повышает общую производительность компьютера. Соответственно, чем больше у вас на компьютере такой памяти, тем быстрее он должен работать. Тут, наверное, у многих из наших читателей возникнет такой вопрос: если быстрая память так хороша, почему ею не заменяют обычную оперативную память? Ответ прост — всё дело в цене, кэш-память намного дороже обычной памяти, поэтому она используется в ограниченных объёмах.
↑ Что такое кэшированная память в Диспетчере задач
Кстати, сведения об этой памяти указаны также в оснастке «Монитор ресурсов», в котором она обозначена секцией синего цвета «Ожидание». По сути, кэшированная память представляет собой часть свободной оперативной памяти, выделенной под неиспользуемые данные наиболее приоритетных процессов.
В то же время кэшированная память не привязана жёстко к данным процессам, поэтому её страницы могут быть использованы для записи других, менее приоритетных процессов. Убедиться в этом вы можете сами, открыв пару десятков вкладок в браузере. Вы увидите, что объем доступной кэшированной памяти сразу станет меньше, а всё потому, что зарезервированные страницы были переданы браузеру для записи в них данных вкладок. Из этого следует, что беспокоиться вам нужно не о увеличении размера кэшированной памяти, а скорее наоборот — об уменьшении доступного объёма кэша при отсутствии свободной памяти, выделенной в Мониторе ресурсов голубым цветом.
Нужно ли очищать кэшированную память
Особой нужды в очистке кэшированной памяти нет, более того, постоянная принудительная её очистка может привести к неравномерной нагрузке процессора, более частому обращению к файлу подкачки и общему снижению производительности. Исключения составляют те случаи, когда вы точно установили связь между увеличением объёма кэшированной памяти с падением производительности, что иногда бывает в играх. Тогда на собственный страх и риск вы можете включить очистку кэша оперативной памяти.
Очистка кэшированной памяти в RAMMap и EmptyStandbyList
Самый простой способ обнулить кэш оперативную память — это воспользоваться бесплатной тулзой RAMMap, разработанной одним из сотрудников Microsoft Марком Руссиновичем. Утилита не требует установки, чтобы очистить в ней память, выберите в главном меню Empty → Empty Standby List. Объем кэшированной памяти тут же уменьшится в несколько раз, но уже через несколько минут система опять её зарезервирует. 
Также вы можете воспользоваться такой утилитой как EmptyStandbyList, работающей по тому же принципу что и функция Empty Standby List в утилите RAMMap. В отличие от RAMMap, тулза EmptyStandbyList не имеет графического интерфейса, чтобы очистить с её помощью кэшированную память, достаточно просто запустить исполняемый файл. Естественно, через некоторое время кэш снова будет заполнен, если вы хотите это предотвратить, в Планировщике заданий вам нужно создать задачу, которая станет запускать исполняемый файл EmptyStandbyList.exe каждые 2, 3, 5, 10 или сколько вам нужно минут.
Откройте Планировщик командой taskschd.msc, справа нажмите «Создать» задачу
и выставьте настройки как показано на скриншоте. Обратите внимание, что в качестве пользователя мы указываем Систему, тогда как по умолчанию задание будет выполняться от имени учётной записи администратора. В условиях запуска (триггеры) указываем интервал между запусками задачи, на вкладке «Действия» указываем путь к исполняемому файлу утилиты. Сохраняем задание и проверяем его работу.
Использовать этот трюк или нет, решать вам. Если вы наблюдаете чрезмерное заполнение RAM-кэша, сопровождающееся снижением производительности в играх или при работе с «тяжёлыми» приложениями, пробуйте, в остальных случаях особого смысла в очистке кэша памяти мы не видим.
Оперативное вмешательство: разбираемся с утечками памяти
Оперативной памяти много не бывает: любой доступный объём достаточен лишь «до поры, до времени», а там найдётся, куда его применить. Хорошо, когда это действительно полезные задачи. Работа. Игры. Исследования. Плохо, когда оперативка заканчивается не по вине пользователя, но по раздолбайству разработчика.
Причин тому много, способов же решения… давайте обо всём по порядку.
Верните мой 97-й
Незаконный захват оперативной памяти приложениями – прямое следствие технологического прогресса. Вычислительных ресурсов, спасибо закону Мура, становится больше (да и цена их падает год от года), а стоимость работы высококвалифицированного специалиста, увы (и вновь к счастью для нас, IT’шников), следует обратной динамике. Приложения обрастают новыми возможностями, для быстрой разработки вводятся очередные слои абстракций… Двадцать лет назад код был куда ближе к «железу», нежели сейчас. Огромное число прослоек и промежуточных технологий – одно из многих зол, приводящих к плачевной ситуации. 15 мегабайт оперативной памяти для (!) калькулятора. Кошмар!
И ладно бы ситуация улучшалась, так нет: разработчики берут старые инструменты, придумывают еще более простые и многофункциональные новые, проходит несколько лет и цикл повторяется. Подумать только, недавно мы радовались CSS 3.0 и скругленным уголкам простым свойством объекта, затем Bootstrap’у, сейчас – очередной надстройке-комбайну. Write less, do more во все поля.
Комфортабельные троллейбусы из хлеба
Современные браузеры – это не только ценный гипертекст, но и три-четыре десятка полезных фич. Воспроизведение видео, работа с документами, и другие расширения – почти что операционка в миниатюре. С кучей собственных модулей от разных разработчиков, и всё это соединено кое-как. Работает зачастую так же. Миллион открытых вкладок, сложная вёрстка, фреймворк на фреймворке – одни из основных генераторов утечек.
Как бороться? Поставить какой-нибудь блокировщик рекламы и экстеншн типа The Great Suspender, который выгружает из памяти неиспользуемые страницы и сохраняет во вкладке «минимум» – удобно и эффективно снижает фоновый отжор памяти.
Не все adblock’и одинаково полезны
Да, софт, который вырезает назойливые баннеры и код всяких отслеживалок, в определенных случаях снижает нагрузку и на процессор, и на оперативку. Но не всегда. Эффективность данного решения зависит напрямую от качества его исполнения. Софт, работающий на уровне системы в роли прокси-сервера (отсекающий трафик с рекламных площадок до того, как он попадёт в браузер) сам по себе потребляет некоторый объём памяти, но он более-менее статичен. А вот расширения и модули для популярных браузеров создают монструозные конструкции на месте вырезанных рекламных фреймов. Да, рекламы на странице становится меньше, вот только потребление памяти данной вкладкой может вырасти не на каких-то 10-15%, а в несколько раз.
Проблемы кэширования ресурсов
Этим страдают в большинстве своём игры-песочницы, как стационарные, так и запускаемые внутри браузера: Factorio, Rim World, Minecraft с кучей модов… При определённом стечении обстоятельств (например, оставили производство на ночь, чтобы игра зарабатывала, пока вы спите) можно проснуться с наглухо повисшим компьютером. Ну или очень медленно работающим. При этом в плане оперативной памяти всё будет «ок» – сколько потребляла игра, столько и потребляет.
В 90% случаев такого поведения у пользователей установлен SSD и включены одновременно файл подкачки и режим гибернации. Игра сбрасывает неиспользуемые ресурсы из оперативки в своп, «Винда» кэширует их и сохраняет на случай ухода в сон, далее графика используется повторно и вновь откладывается в «долгий ящик». Вот только старые копии никуда не удаляются – спустя несколько часов, в зависимости от объёма накопителя, свободное место на нём заканчивается, система падает до перезагрузки и очистки временных файлов. Не пытайся игра «оптимизировать» расход оперативной памяти, выгружая и вновь подкачивая ресурсы – текла бы как обычно, с постепенным замедлением работы и последующим крашем.
Варианты решения: проверка гипотезы какой-нибудь утилитой типа TreeSize, удаление накопленных мусорных asset’ов, перенос подкачки на объёмный HDD или отключение гибернации в Windows 10, написание багрепорта на форум, ожидание патча.
У разработчика лапки
Иногда утечки – это просто утечки. Фотошоп любит и умеет отжирать большие объёмы памяти, особенно сразу после выхода нового номерного релиза. Благо в самом приложении есть инструмент ограничения доступного объёма оперативки (не стоит выделять больше 66%), назначения кэширующих дисков и всего такого. В качестве альтернативы можно подождать полгода и дождаться стабильной версии. Киллерфичи редко бывают настолько нужны, чтобы мириться с багами.
Торрент-клиенты. Множество одновременно установленных подключений, столько же одновременно скачиваемых файлов, проблемы с соединением – и соответствующий расход памяти. Решение – ограничение на количество исходящих соединений и скорости отдачи. Правильные коэффициенты подбираются вручную.
Софт принтеров / сканеров / камер. В анамнезе – написанный за еду индусский код: кривой, как камасутра. Медицина в этом случае бессильна – тут уж ибо использовать открытые / универсальные аналоги, либо писать багрепорты и молиться Шиве, чтоб тот покарал проклятых халтурщиков.
Майнер-малварь. Иногда утечка памяти «в никуда» – повод расчехлить антивирус. Главная защита криптовалют от «оптимизации» их добычи аппаратным методом – увеличение сложности алгоритма в направлении «нужно больше памяти для расчётов». Поэтому фоновые майнилки могут спалиться на потреблении оперативки. Причём приобщиться к числу «шахтёров» можно и незаметно для себя: чего стоит только известный скандал с uTorrent, «бонусом» к которому пользователи получали приложение-майнер Epic Scale. Да и один популярный трекер минувшей осенью засветился в фоновой добыче криптовалюты прямо в браузерах посетителей.
Война без конца
Пройдёт ещё немало времени до того, как будет написан качественный ИИ, способный разгрести завалы кривого кода. А пока приходится бороться с утечками памяти проверенными методами: с бубном, плетью и багрепортом. Или наращивать объёмы и не замечать этих самых утечек. Конечно, иметь на борту 16, 32 или даже 64 гига быстрой оперативки – это хорошо, и у Kingston всегда найдётся подходящее решение. Важно помнить, что кривому софту любой объём не помеха – просто с хорошим запасом оперативной памяти он дольше проработает без проблем.
Есть интересные примеры утечек памяти в системе? Пишите в комментах – всем будет интересно.
Как оптимизировать и очистить память Windows7,8 и 10.
Многие пользователи хотят, что бы компьютер постоянно «летал». Есть много способов оптимизации скорости работы ПК. Вот 3 статьи на нашем сайте: один, два и три. Но сегодня речь пойдет об оптимизации работы оперативной памяти. На сайте Майкрософт есть интересная статья но без литра водки не разберешься :-). Мы пойдем в обход, как настоящие герои.
Дальше будет много картинок, почти компьютерный комикс с рецептом для приготовления :-).
Запускаем диспетчер задач Ctrl+Shift+Esc, переходим на вкладку быстродействие и смотрим на циферки, в данном случае объём оперативной памяти составляет 12279 МБ. Кэшировано 521 МБ. Доступно 10646 МБ. И свободно 10200 МБ. По центру внизу нажимаем кнопку Монитор ресурсов.
Наблюдаем примерно такую же картину, Свободная память совпадает, но есть еще пункт Ожидание 433 МБ.
Теперь переключимся на вкладку процессы на данный момент их 53 плюс минус 1-2, бывает отложенный запуск программ на старте Windows, системный процесс запускается, делает свою работу и выгружается. Поэтому цифры могут плавать в небольшом диапазоне.
Теперь поработаем с нормальной нагрузкой, например браузер Firefox с кучей вкладок, штук 50 или больше. Плюс еще парочка небольших программ.
Как видим, оперативная память начинает «таять». Если у Вас установлено 4 ГБ оперативной памяти, то уже нормальной работы не получится. При 8 ГБ всё еще будет хорошо. Теперь опять смотрим в монитор ресурсов и сравниваем цифры.
Доступно, кэшировано, свободно всё совпадает, но вот полоска ожидание разрослась до 7027 МБ. то есть 7 ГБ. Теперь закрываем Firefox и другие запущенные программы и смотрим в диспетчер задач.
Оперативная память освободилась, это видно по графику, да и цифры красивые.
В мониторе ресурсов цифры совпадают, но синяя полоса ожидание (она же кэшировано), означает, что в оперативной памяти еще висит информация, с которой мы работали. Так как пункт свободно показывает нам 3786 МБ.
Теперь представьте, что вы работали полдня, запускали большое количество программ, в оперативной памяти висят куски непонятно чего, и как сам Windows управляет всем этим КЭШИРОВАНО абсолютно не понятно. Наверное, сами программисты из Microsoft не знают, как работает оперативка :-). А Вам нужно запустить видеоредактор, фотошоп или погонять в любимую игрушку (лара крофт, farcry 5 или подобные монстры) без лагов и фризов.
Есть очень простой выход, скачиваем маленькую бесплатную программу Mem Reduct.
Устанавливаете и запускаете, от имени администратора! Программа на русском языке.
Mem Reduct показывает свои циферки. Так же можно сравнить с AIDA 64, интересен пункт виртуальная память, цифры совпадают. В AIDA 64 так же можно промониторить файл подкачки, в данном случае задав минимальный объём 1024 МБ, а максимальный 6144 МБ. Чётко видно текущую и пиковую загрузку файла подкачки. Таким образом, при запущенной AIDA 64 можно поработать дней пять при своей типовой нагрузке на компьютер и определить нужный конкретно Вам объём файла подкачки. Так как споры по поводу его объёма на просторах интернета не утихают.
Далее в опциях программы Mem Reduct нужно сделать настройки. Для Windows10 есть еще дополнительный пункт, можете попробовать у кого стоит 10-ка.
Далее нажимаем кнопку внизу Очистить память.
Появится окошко, можно поставить галочку и нажимаем Да.
Теперь картина совершенно другая. Свободной памяти море, ожидание всего 505 МБ. файл подкачки слегка распух до 613 МБ. виртуальная память почти не изменилась.
В диспетчере задач всё тоже чудесно, причем свободной памяти еще больше, чем при старте компьютера, Mem Reduct какие-то объёмы оперативной памяти сбрасывает (загоняет) в файл подкачки.
Так же хотелось бы сказать пару слов любителям игр, особенно которые смотрят чудо-блогеров на ютубе и любят статистику из MSI Afterburner. Так вот, скриншот для Вас. Где указано RAM 10565 МБ. Это не загрузка оперативной памяти. Это скорее всего сумма кешировано+занято, а вот ниже параметр RAM usage 6970 МБ соответствует правде.
Сами «Танки» кушают всего 1415 МБ оперативной памяти.
Вот еще любопытный скриншот, как разные программы по разному считают объём оперативной памяти.
Надеемся, статья была полезной и интересной.
Присоединяйтесь к нашей группе в VK, чтобы, не пропустить новые статьи, скидки и другие вкусняшки. Для подписчиков группы действует скидка 10% на все виды работ.
Есть минимум три основных пути как отремонтировать компьютер: 1. Обратиться к знакомому или другу (гуру), который хорошо разбирается в компьютерах. 2. Вызвать мастера на дом. 3. Обратиться в сервисный центр. Рассмотрим поподробнее все три варианта ремо.
В статье Вы научитесь: • Как подключить компьютер к смартфону по wi-fi для передачи файлов со смартфона. • Как подключить смартфон к смартфону по wi-fi для передачи файлов между ними. • Как подключить смартфон к компьютеру по wi-fi для передачи файлов с.
В статье обсудим, как быстро и удобно настроить автозагрузку Windows 10, 8, 7 абсолютно любому пользователю. С помощью Autorun Organizer.
Page-кэш, или как связаны между собой оперативная память и файлы
Ранее мы познакомились с тем, как ядро управляет виртуальной памятью процесса, однако работу с файлами и ввод/вывод мы опустили. В этой статье рассмотрим важный и часто вызывающий заблуждения вопрос о том, какая существует связь между оперативной памятью и файловыми операциями, и как она влияет на производительность системы.
Что касается работы с файлами, тут операционная система должна решить две важные проблемы. Первая проблема – удивительно низкая скорость работы жестих дисков (особенно операций поиска) по сравнению со скоростью оперативной памяти. Вторая проблема – возможность совместного использования единожды загруженного в оперативную память файла разными программами. Взглянув на процессы с помощью Process Explorer, мы увидим, что порядка 15 МБ оперативной памяти в каждом процессе тратится на общие DLL-библиотеки. На моем компьютере в данный момент выполняется 100 процессов, и, если бы не существовала возможность совместного использования файлов в памяти, то около 1,5 ГБ памяти тратилось бы только на общие DLL-библиотеки. Это, конечно, неприемлемо. В Linux, программы тоже используют разделяемые библиотеки типа ld.so, libc и других.
К счастью, обе проблемы можно решить, как говорится, одним махом – с помощью страничного кэша (page cache). Страничный кэш используется ядром для хранения фрагментов файлов, причем каждый фрагмент имеет размер в одну страницу. Для того, чтобы лучше проиллюстрировать идею страничного кэша, я придумал программу под названием render, которая открывает файл scene.dat, читает его порциями по 512 байт и копирует их в выделенное пространство в куче. Первая операция чтения будет осуществлена так, как показано на рисунке вверху.
После того, как будут прочитаны 12 KБ, куча процесса render и имеющие отношения к делу физические страницы будут выглядеть следующим образом:
Кажется, все просто, но на деле все, много чего происходит. Во-первых, даже несмотря на то, что наша программа использует обычные вызовы read(), в результате их выполнения в страничном кэше окажется три 4-килобайтных страницы с содержимым файла scene.dat. Многие удивляются, но все стандартные операции файлового ввода / вывода работают через страничный кэш. В Linux на x86-платформе, ядро представляет файл в виде последовательности 4-килобайтных фрагментов. Если запросить прочтение всего навсего одного байта из файла, то этого приведет к тому, что 4-килобайтный фрагмент, содержащий данный байт, будет целиком прочитан с диска и помещен в страничный кэш. Вообще говоря, в этом есть смысл, потому что, во-первых, производительность при непрерывном чтении с диска (sustained disk throughput) является достаточно высокой, и, во-вторых, программы обычно читают более одного байта из некоторой области файла. Страничный кэш знает о том, какое место в файле занимает каждый скэшированный его фрагмент; это изображено на рисунке как #0, #1, и т.д. В Windows используются 256-килобайтные фрагменты (называемые “view”), которые по своему предназначению аналогичны страницам в страничном кэше Linux.
При использовании обычных операций чтения, данные сначала попадают в страничный кэш. Программисту данные доступны порционально, через буфер, и из него он копирует их (в нашем примере) в область в куче. Данный подход к делу является крайне неэффективным – не только тратятся вычислительные ресурсы процессора и оказывается негативное влияние на процессорные кэши, но также происходит напрасная трата оперативной памяти на хранение копий одних и тех же данных. Если взглянуть на предыдущий рисунок, то будет видно, что содержимое файла scene.dat хранится сразу в двух экземплярах; любой новый процесс, работающий с этим файлом, скопирует эти данные еще раз. Таким образом, вот чего мы добились – несколько уменьшили проблему задержки при чтении с диска, но в остальном потерпели полную неудачу. Однако, решение проблемы существует – это «отображение файлов в память» (memory-mapped files):
Когда программист использует отображение файлов в память, ядро мэппирует виртуальные страницы напрямую в физические страницы в страничном кэше. Это позволяет добиться значительного прироста производительности – в Windows System Programming пишут об ускорении времени выполнения программы на 30% и более по сравнению со стандартными файловыми операциями ввода/вывода. Аналогичные цифры, только теперь уже для Linux и Solaris, приводятся и в книге Advanced Programming in the Unix Environment. С помощью данного механизма можно писать программы, которые будут использовать значительно меньше оперативной памяти (хотя тут многое также зависит от особенностей самой программы).
Как всегда, главное в вопросах производительности – это измерения и наглядные результаты. Но даже и без этого, отображение файлов в память вполне себя окупает. Интерфейс программирования – достаточно приятный и позволяет читать файлы как обычные байты в памяти. Ради всех преимуществ данного механизма не придется чем-то особенным жертвовать, например, читаемость кода никак не пострадает. Как говорится, флаг вам в руки – не бойтесь экспериментировать со своим адресным пространством и вызовом mmap в Unix-подобных системах, вызовом CreateFileMapping в Windows, а также разными оберточными функциями, доступными в высокоуровневых языках программирования.
Когда создается отображение файла в память, его содержимое попадает туда не сразу, а постепенно – по мере, того, как процессор отлавливает page faults, вызванные обращением к еще незагруженным фрагментам файла. Обработчик для такого page fault отыщит нужный page-фрейм в страничном кэше и осуществит мэппирование виртуальной страницы в данный page-фрейм. Если нужные данные до этого не были скэшированы в страничном кэше, то будет инициирована операция чтения с диска.
А теперь, вопрос. Представим, что программа render завершила выполнение, и никаких ее дочерних процессов тоже не осталось. Будут ли при этом тут же высвобождены страницы в страничном кэше, хранящие фрагменты файла scene.dat? Многие думают, что да – но это было бы неэффективно. Вообще, если попытаться проанализировать ситуацию, то вот что приходит в голову: достаточно часто мы создаем файл в одной программе, она завершает свое выполнение, затем файл используется в другой программе. Страничный кэш должен предусматривать такие ситуации. И вообще, зачем ядру в принципе избавляться от содержимого страничного кэша? Мы же помним, что скорость работы жесткого диска на пять порядков медленнее оперативной памяти. И если случается так, что данные ранее уже были скэшированы, то нам крупно повезло. Именно поэтому, из страничного кэша ничего не удаляется, по крайней мере до тех пор, пока есть свободная оперативная память. Страничный кэш не зависит от какого-то конкретного процесса, наоборот – это такой ресурс, который совместно использует вся система. Неделю спустя, вновь запустим render, и если файл scene.dat все еще находится в страничном кэше — ну, что ж, нам везет! Вот почему размер страничного кэша постепенно растет, а затем его рост вдруг останавливается. Нет, не потому что операционная система – полная фигня, которая съедает всю оперативу. А потому, что так и должно быть. Неиспользуемая оперативная память – это тоже своего рода напрасно растрачиваемый ресурс. Лучше использовать как можно больше оперативной памяти под страничный кэш, чем вообще никак не использовать.
Когда программа делает вызов write(), данные просто копируются в соответствующую страницу в страничном кэше, и она помечается флагом «dirty». Запись непосредственно на сам жесткий диск не происходит сразу же, и нет смысла блокировать программу в ожидании, пока дисковая подсистема станет доступной. Есть у этого поведения и свой недостаток – если компьютер упадет в синий экран, то данные могут так и не попасть на диск. Именно поэтому критически важные файлы, как например, файлы журнала транзакций баз данных, нужно синхронизировать специальным вызовом fsync() (но вообще, есть еще кэш контроллера жесткого диска, так что и здесь нельзя быть абсолютно уверенным в успешности операции записи). Вызов read() напротив блокирует программу до тех пор, пока диск не станет доступным и данные не будут прочитаны. Для того, чтобы несколько смягчить данную проблему, операционные системы используют т.н. «метод нетерпеливой загрузки» (eager loading), и примером этого метода является «опережающее чтение» (read ahead). Когда задействуется опережающее чтение, ядро производит упреждающую загрузку определенного количества файловых фрагментов в страничный кэш, предвосхищая тем самым последуюшие запросы на чтение. Можно помочь ядру с выбором оптимальных параметров для опережающего чтения, выбрав параметр в зависимости от того, как Вы собираетесь читать файл – последовательно или в произвольном порядке (вызовы madvise(), readahead(), в Windows — cache хинты). Linux использует опережающее чтение для файлов, отраженных в память; насчет Windows я не уверен. Наконец, можно вообще не использовать страничный кэш – за это ответственны флаги O_DIRECT в Linux и NO_BUFFERING в Windows; базы данных так довольно часто и поступают.
Мэппинг файла в память может быть двух типов – или private, или shared. Эти термины обозначают только то, как система будет реагировать на изменение данных в оперативной памяти: в случае с shared-мэппингами любое изменение данных будет сбрасываться на диск или будет видимым в других процессах; в случае с private-мэппингами этого не произойдет. Для реализации private-мэппингов, ядро опирается на механизм copy-on-write, который основан на определенном использовании записей в page-таблицах. В следующем примере, наша программа render, а также программа render3d (а у меня талант на выдумывание названий программ!) создают private-мэппинг для файла scene.dat. Затем, render пишет в область виртуальной памяти, которая поставлена в соответствие файлу:
То, что записи в page-таблицах являются read-only (см. на рисунке) не должно нас смущать; и это еще не означает, что мэппинг будет доступен только на чтение. Это просто такой прием, с помощью которого ядро обеспечивает совместное использование страницы разными процессами и оттягивает необходимость создавать копию страницы до самого последнего момента. Глядя на рисунок понимаешь, что термин “private” возможно и не самый удачный, но если вспомнить, что он описывает исключительно поведение при изменении данных, то все нормально. У механизма мэппирования есть и еще одна особенность. Допустим, есть две программы, которые не связаны отношениями «родительский процесс – дочерний процесс». Программы работают с одним и тем же файлом, но мэппирют его по-разному – в одной программе это private-мэппинг, в другой – shared-мэппинг. Так вот, программа с private-мэппингом (назовем ее «первой программой») будет видеть все изменения, вносимые второй программой в некоторую страницу, до тех пор, пока первая программа сама не попытается записать что-нибудь в эту страницу (что приведет к созданию отдельной копии страницы для первой программы). Т.е. как только отработает механизм copy-on-write, изменения, вносимые другими программами, уже видны не будут. Ядро не гарантирует подобного поведения, но в случае с x86-процессорами так и происходит; и в этом есть определенный смысл, даже с точки зрения того же API.
Что же касается shared-мэппингов, то здесь дела обстоят следующим образом. На страницы выставляются права «read/write», и они просто мэппируются в страничный кэш. Таким образом, кто бы не вносил изменения в страницу, это увидят все процессы. Помимо этого, данные сбрасываются на жесткий диск. Ну и наконец, если страницы на предыдущем рисунке были бы действительно read-only, то page fault, отловленный при обращении к ним, повлек бы за собой ошибку сегментации (segmentation fault), а не отработку логики copy-on-write.
Разделяемые библиотеки также отображаются в память как и любые другие файлы. В этом нет ничего особенного — все тот же private-мэппинг, доступный программисту через вызов API. Далее приводится пример, показывающий часть адресного пространства двух экземпляров программы render, использующих механизм отображения файлов в память. Помимо этого, показаны соответствующие области физической памяти. Таким образом мы можем увязать вместе те концепций, с которыми познакомились в данной статье:
На этом завершим нашу серию из трёх статей, посвященных основам работы памяти. Надеюсь информация была для вас полезной и позволила составить общее представление по данной теме.