По материалам статьи Slava Oks: A look at Windows Virtual Memory mechanisms (continuation of "A look at Virtual Address Space - VAS")
Как я обещал в прошлый раз, это будет следующая статья о памяти. Как Вы помните, моей целью является демонстрация того, как в SQL Server устроено управление использованием памяти. Но для читателя, чтобы в этом хорошо разобраться, я думаю важно также уяснить, как управляет памятью операционная система Windows. Важно понимать детали такого управления памятью, однако сейчас я хочу, чтобы Вы поняли заложенные в это концепции! В некоторых случаях я нарочно буду пропускать подробности, потому что в данном случае они не очень важны, и многие из них могут отличаться в разных версиях операционной системы. И так, позвольте приступить!
В моей предыдущей статье упоминалось, что участки VAS могут быть немедленно привязаны к физической памяти или после использования VirtualAlloc API. Как и большинство операционных систем, Windows осуществляет привязку физической памяти по требованию, при первом обращении к странице на участке VAS (это поведение немного отличается от тех случаев, когда Вы не используете файл подкачки, и страница VAS немедленно привязывается к странице физической памяти). Одновременно привязывается только одна страница. Когда первое обращение к памяти идёт от аппаратных средств, генерируется исключение, называемое отсутствием страницы. Исключение обрабатывается Windows и операционная система проверяет, был ли закреплён текущий участок VAS, используя для этого соответствующую этому участку структуру - Virtual Address Descriptor (VAD). Если участок закреплён, и к нему происходит первое обращение, операционная система отыщет в оперативной памяти физическую страницу, которую можно для этого использовать (стоит иметь в виду, что эта страница будет предварительно заполнена нулями, прежде чем она будет задействована, что обусловлено соображениями безопасности). Наконец, после этого будет выполнена привязка участка VAS к странице, которая будет заполнена соответствующими структурами данных, и эта информация будет загружена в процессор, что бы продолжить работу с того момента, когда было обнаружено отсутствие страницы.
Из-за недостаточности оперативной памяти Windows может принять решение отобрать физические страницы у процесса. Используя политику самостоятельного исправления, операционная система будет отыскивать свободные страницы. Для этого она проверяет, присутствует ли актуальный образ страницы в файле подкачки на диске, и при необходимости инициирует листание для страницы, что бы переместить её в файл подкачки. Как только страница попадёт на диск, операционная система сможет так настроить необходимые структуры данных, чтобы при следующем обращении к странице было известно, где её найти. После этого, физическая страница заполняется нулями и отмечается в списке свободных страниц, который используется для последующих запросов памяти.
Как я говорил ранее, процессор инициирует исключение отсутствия страницы, когда не может найти физическую страницу, при попытке обращения к соответствующим виртуальным адресам. Приложение может генерировать исключение отсутствия страницы двумя путями. Во-первых, если запрашивается участок VAS, закреплённый впервые. Во-вторых, если операционная система до этого переместила страницу данных на диск во время листания (когда приложение обращается к странице VAS, которая не была закреплена, Windows всё-таки инициирует исключение). Ошибки такого тип, когда страница должна быть возвращена с диска, называют "тяжёлыми" ошибками страниц (hard page fault). Если приложение впервые запрашивает закреплённый участок VAS, будет инициировано исключение "demand zero page fault". Существует и другой тип ошибок страниц - это "мягкие" ошибки отсутствия страниц (soft page fault). Мягкие ошибки наблюдаются тогда, когда Windows может найти страницу в физической памяти и работать с ней не считывая её с диска.
Используемый в Windows механизм виртуальной памяти позволяет отображать в разное время одни и те же физические страницы на разные VAS в разных местах. Физические страницы, которые могут быть отображены только на единственное VAS, называются приватными (private physical pages), потому что они не могут разделятся между несколькими VAS. Физические страницы, которые единовременно отображаются на несколько VAS, называются разделяемыми физическими страницами (shared physical pages).
Все закреплённые с помощью интерфейсов VirtualAlloc * участки VAS привязаны к тем физическим страницам, которые не могут быть разделены между разными VAS. Их можно считать приватными физическими страницами. Сумму всех приватных физических страниц в оперативной памяти и на диске называют приватными байтами (private bytes), если используют терминологию Системного Монитора, или размером виртуальной (выделяемой) памяти, согласно терминологии Диспетчера Задач. Сумму всех приватных физических страниц, которые располагаются в оперативной памяти, называют рабочим множеством, которое отображается в виде значения "Выделение памяти" (Memory Usage) в строке состояния Диспетчера Задач.
Как я упоминал ранее, зависимость Windows от потребности в физической памяти приводит к тому, что операционная система может изымать физические страницы из рабочего множества процесса. Обычно это проявляется в виде листания. Операционная система имеет возможность предотвратить листание этих участков VAS. За это отвечает механизм блокировки участков VAS в физической оперативной памяти. Как Вы могли догадаться, приложение, которое пробует блокировать свои участки VAS, может дестабилизировать всю систему. Чтобы сгладить этот эффект, в Windows привилегия "Lock pages in memory" по умолчанию выключена, из-за чего только те приложения, которым администратором дано на это разрешение, могут блокировать страницы в памяти. Кроме того, операционная система имеет возможность, в случае необходимости, подвергнуть листанию рабочее множество процесса целиком.
Не смотря на то, что размер регистров на платформе x86 всего 32 бита, платформа предоставляет возможность операционной системе оперировать 64 Гб оперативной памяти, для этого используется расширение физической адресации - Physical Address Extensions (PAE). Включение для Windows режима PAE может быть выполнено редактированием файла boot.ini. Если режим PAE не включен, Windows будет способна управлять максимум 4GB оперативной памяти, не смотря на то, что компьютер может иметь при этом больше оперативной памяти.
Некоторым пользовательским приложениям необходимо иметь VAS больше чем 2 Гб. В Windows имеется возможность увеличить VAS для пользовательского приложения до 3 Гб. Этот режим имеет серьёзный недостаток. В таком режиме будет ограничен до 1 Гб доступный ядру объём VAS. Увеличить размер VAS для пользователя можно добавив ключ /3GB в файл boot.ini. После внесения таких изменений необходима перезагрузка системы.
Ограничение VAS для ядра до 1 Гб влияет на весь компьютер, а не только на приложение, которому нужен большой объём VAS. Например, установка ключа /3GB влияет на размер доступный операционного системе объёма памяти, если включён режим PAE, то он снижается с 64 Гб до 16 Гб. Ключ /3GB влияете на все компоненты ядра, включая все драйверы. Включение /3GB может вызвать такие отрицательные эффекты, как снижение производительности и отказы распределения памяти с остановкой системы. Мое мнение - нужно избегать использования ключа /3GB, если в этом нет большой необходимости.
Как я уже писал, для платформы x86 объём VAS ограничен 2 Гб или 3 Гб, в зависимости от ключей в файле boot.ini. На AMD64, 32 битное приложение может иметь до 4 Гб. Такой маленький объём VAS может быть существенным недостатком для высокопроизводительных серверов с гигабайтами и терабайтными базами данных, обслуживаемых SQL Server. Также я говорил, что ключ PAE предоставляет Windows возможность оперировать с памятью до 64 Гб. Но как же в действительности один процесс обращается к такому большому объёму памяти? Чтобы предоставить одному процессу возможность работать с превышающим VAS объёмом оперативной памяти, Windows использует механизм Address Window Extension (AWE) (вспомните былые годы под DOS). Будьте внимательны, многие из авторов используют термин AWE память. Не бывает AWE памяти, нельзя пойти и купить AWE память в магазине 
AWE API может использоваться даже на компьютерах с памятью меньшей объёма VAS процесса. На самом деле, AWE можно использовать для того, чтобы избавиться от любого типа листания (вспомните, что при блокировке страниц в памяти с использованием механизмов VirtualLock, у Windows ещё остаётся возможность подвергнуть листанию целиком весь процесс). При использовании же AWE механизма, операционная система не сможет никак вмешаться. Такая гибкость создаёт некоторые трудности. Неправильное использование AWE механизма может привести к остановке всего компьютера, преодолеть которую можно будет только путём перезагрузки.
Хорошо, я думаю, на сегодня достаточно информации. В этой и предыдущих статьях я хотел, что бы Вы поняли общую концепцию, которая действительно очень важна! Вот, что можно представить в виде краткого резюме:
Каждый процесс имеет свою собственную область VAS.
Разработчики часто не учитывают особенности VAS.
VAS является ограниченным ресурсом, даже на 64 - битной платформе.
Windows управляет VAS точно так же, как управляется хип (динамическая память).
Объём самого маленького участка VAS равен 64 Кб.
Управление участком VAS происходит посредством передачи ядру VAD - структуры.
VAD описывает состояние участка VAS: распределён, зафиксирован или нейтрален (allocated, committed, uncommitted).
Страница VAS привязывается к физической странице оперативной памяти по запросу, при первом обращении к странице, если не используется файл подкачки.
Физические страницы могут быть приватными или разделяемыми (private / shared).
Набор всех приватных, физических страниц процесса называется приватными байтами - "Private Bytes" (PM) или размером виртуальной памяти - "Virtual Memory Size" (TM).
Набор приватных, физических страниц оперативной памяти называют рабочим множеством процесса - "Working Set".
Физические страницы, привязанные к определенной участку VAS, могут быть блокированы в памяти.
Ключ PAE позволяет поддерживать в Windows до 64 Гб оперативной памяти.
На платформе x86 для VAS возможны следующие ограничения: 2 Гб, 3 Гб или 4 Гб.
Ключ /3GB увеличивает объём пользовательской VAS до 3 Гб и уменьшает VAS ядра до 1 Гб.
Ключ /3GB ограничивает предел физической памяти, расширяемый ключом PAE, до 16 Гб.
Ключ /3GB использовать не рекомендуется.
AWE механизм, это не память.
AWE предоставляет возможность одному процессу использовать память за пределами VAS.
Ключ /3GB не обязателен для включения AWE механизма.
Ключ /PAE не обязателен для включения AWE механизма.
Некоторые интересные "грабли":
Распределение физической памяти, с использованием AWE механизма, на Windows 2000 работает медленно (по этой причине SQL Server 2000 не может динамически управлять памятью, когда включён режим AWE). Проблема устранена в Windows 2003 Server, с расчётом на то, чтобы SQL Server 2005 смог распределять физическую память динамически.
Физические страницы, распределенные через AWE механизм, не являются частью рабочего множества процесса, как и большие страницы (я расскажу про большие страницы когда-нибудь позже). Именно по этой причине PerfMon (Системный монитор) или Task Manager (Диспетчер задач) их не показывают. Причина, по которой доступные через AWE страницы не являются частью Private Bytes состоит в том, что работа с ними строится по-другому, чем с приватными страницами процесса. Тот же самое можно сказать и о больших страницах. Я не знаю, имеются ли планы добавить в операционную систему новые счётчики производительности для AWE и больших страниц, но в следующей версии SQL Server можно будет увидеть количество страниц, распределённых AWE, для чего можно будет использовать администраторские динамические представления - dmv.
В следующий раз мы будем говорить о вытеснении памяти и, после этого, мы будет готовы погрузиться в тему менеджера памяти SQL Server.
Комментариев нет:
Отправить комментарий