Преодолевая пределы Windows: физическая память

Это перевод Pushing the Limits of Windows: Physical Memory. Автор: Марк Руссинович.

Это первый пост в блоге из серии "Pushing the Limits of Windows", которую я буду писать ближайшие месяцы и в которой буду описывать как Windows и приложения используют конкретный ресурс, лицензионные и реализационные ограничения ресурса, как измерить использование ресурса и как диагностировать его утечки. Чтобы эффективно управлять своими Windows системами вам нужно понимать как Windows управляет физическими ресурсами, такими как процессоры (CPUs) и память (memory), а также логическими ресурсами, такими как виртуальная память (virtual memory), дескрипторы (handles) и объекты оконного менеджера (window manager objects). Знание пределов и ограничений этих ресурсов и методы слежения за ними позволит вам соотносить использование ресурсов с приложениями, которые их используют, эффективно изменять систему для определённой нагрузки и идентифицировать приложения с утечкой ресурсов.

Физическая память

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

Кроме влияния на производительность, количество установленной физической памяти привносит и другие ограничения. Например, размер не подкачиваемого пула (non-paged pool) - буфера операционной системы - очевидно, ограничен физической памятью. Физическая память также влияет на ограничения системной виртуальной памяти, размер которой является грубой суммой физической памяти плюс максимальным размером всех файлов подкачки. Ещё Физическая память может неявно влиять на максимальное число одновременно работающих процессов, о чём я буду говорить в будущем посте, посвящённому ограничениям на процессы и потоки.

Ограничения памяти на серверных Windows

Поддержка физической памяти Windows диктуется ограничениями аппаратной части, лицензированием, структурами операционной системы и совместимостью драйверов. Страница Memory Limits for Windows Releases в MSDN описывает ограничения в различных версиях Windows, а также в пределах версий по редакциям (SKU).

Вы можете увидеть различия в поддержки памяти у разных редакций Windows, диктуемые лицензионными ограничениями. Например, 32-х битная Windows Server 2008 Standard поддерживает только 4 Гб, в то время как 32-х битная же Windows Server 2008 Datacenter поддерживает уже 64 Гб. Аналогично, 64-х битная Windows Server 2008 Standard поддерживает 32 Гб, а 64-х битная Windows Server 2008 Datacenter может оперировать целыми 2 Тб. Вокруг нас не так много систем с 2 Тб физической памяти на борту, но команда производительности Windows Server (Windows Server Performance Team) знает парочку, включая одну, которая была у них в лаборатории для тестов. Вот скриншот Менеджера Задач (Task Manager), работающего на такой системе:


Максимальное ограничение в 128 Гб на 32-х битных Windows, поддерживаемое редакцией Windows Server 2003 Datacenter, следует из того, что структуры, используемые менеджером памяти для отслеживания физической памяти, занимали бы слишком много виртуального адресного пространства на системах с большим количеством памяти. Менеджер памяти следит за каждой страницей (page) памяти, храня данные о ней в массиве, называемом базой данных PFN (PFN database), и (по соображениям производительности) проецируя всю базу данных PFN в виртуальную память. Поскольку в ней каждая страница физической памяти представлена структурой данных размером 28 байт, то вся БД PFN для системы с 128 Гб занимает около 930 Мб. 32-х битные Windows имеют 4 Гб виртуального адресного пространства, которое аппаратно делится на две части: пользовательскую, в котором выполняется процесс пользователя (например, Блокнот), и системную. Поэтому 980 Мб занимают практически половину их доступных 2 Гб из системной части виртуального адресного пространства, оставляя только 1 Гб для ядра, драйверов устройств, системного кэша и других системных структур данных, что делает совершенно неразумным дальнейшее увеличение размера БД:


По этой же причине в таблице с ограничениями также указываются пределы для той же редакции, но при загрузке с модификацией этих 4 Гб (опция называется 4GT и включается указанием в Boot.ini /3GB или /USERVA, а также опцией /Set IncreaseUserVa в Bcdedit), потому что опция 4GT передвигает границу между пользовательской и системной частью виртуального адресного пространства, что даёт до 3 Гб пользовательской части, но оставляет только 1 Гб для системы. Для улучшения производительности, 32-х битный Windows Server 2008 увеличивает зарезервированную часть для системного адресного пространства понижением максимального размера поддерживаемой памяти до 64 Гб.

Менеджер памяти мог бы поддерживать и больше памяти, проецируя БД PFN по кускам в адресное пространство по мере необходимости, но это добавило бы сложности и уменьшило производительность за счёт добавленных накладных расходов на операции проецирования и снятия проекции (map and unmap operations). Только недавно системы стали настолько большими, что нужно задумываться об этом, но поскольку размер адресного пространства не является ограничением для БД PFN на 64-х битных Windows, то поддержка большего количества памяти перекладывается на 64-х битные Windows.

Максимальный предел в 2 Тб на 64-х битном Windows Server 2008 Datacenter не следует из каких-либо ограничений реализации или аппаратной части, но Microsoft поддерживает только те конфигурации, который она может протестировать. Ко времени релиза Windows Server 2008, самая большая система в мире имела 2 Тб, поэтому Windows ограничивает свою поддержку памяти именно 2-мя Тб.

Ограничения памяти на клиентских Windows

64-ти битные клиентские редакции Windows поддерживают различное количество физической памяти как средство усиления различий между редакциями (SKU-differentiating feature) - от нижнего предела в 512 Мб для Windows XP Starter до 128 Гб для Vista Ultimate. Все 32-х битные клиентские редакции Windows, однако, (включая Windows Vista, Windows XP и Windows 2000 Professional) поддерживают максимум 4 Гб физической памяти. 4 Гб - это максимальный размер физической памяти, доступный из стандартного режима управления памятью на x86. В те времена не было необходимости даже рассматривать большее число памяти на клиентских системах, потому что даже сервера с таким количеством памяти были редкостью.

Однако, ко времени, когда Windows XP SP2 был в разработке, клиентские системы с более чем 4 Гб памяти появились в обозримом будущем, поэтому команда Windows начала широкомасштабное тестирование Windows XP на системах с памятью более 4 Гб. Windows XP SP2 также включал по-умолчанию поддержку Physical Address Extensions (PAE) на железе, которое реализовывало память no-execute, потому что оно требовалось для Data Execution Prevention (DEP), но оно же включало поддержку для памяти выше 4 Гб.

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

Реальные ограничения памяти на клиентских 32-х битных Windows

Хотя 4 Гб памяти заявлено как предел для 32-х битных редакций Windows, но реальный предел будет ниже и зависит от чипсета системы и подключенных устройств. Причина в том, что физическое адресное пространство включает в себя не только оперативную память (RAM), но также и память устройств, а системы x86 и x64 проецируют память устройств ниже границы в 4 Гб для обеспечения совместимости с 32-х битными операционными системами, которые не знают, как обращаться с адресами выше 4 Гб. Если система имеет 4 Гб оперативной памяти и устройства, типа видео, аудио или сетевых адаптеров, будут реализовывать окна в свою память (которая в сумме пусть будет равна 500 Мб), то 500 Мб памяти из 4-х Гб будут расположены выше границы в 4 Гб, как показано ниже:


В результате этого, если у вас есть система с 3 Гб или более памяти под управлением клиентской версии 32-х битной Windows, вы не сможете получить в своё распоряжение всю оперативную память. На Windows 2000, Windows XP и Windows Vista RTM вы можете узнать, сколько оперативной памяти доступно системе в диалоговом окне Свойства системы, странице Производительность Менеджера Задач и, в Windows XP и Windows Vista (включая SP1), в утилитах Msinfo32 и Winver. На Window Vista SP1 некоторые из этих мест теперь показывают установленную память, а не доступную для системы память, как указано в этой статье Knowledge Base.

На моём ноутбуке с 4 Гб памяти, когда я загружаю 32-х битную Vista, количество доступной физической памяти будет 3.5 Гб, как показано в утилите Msinfo32:


Вы можете посмотреть раскладку физической памяти с помощью утилиты Meminfo от Alex Ionescu (он также внёс вклад в 5-ю редакцию Windows Internals, которую я написал в соавторстве с Дэвидом Соломоном). Вот вывод Meminfo, которую я запустил на этой же системе с ключом -r для создания дампа диапазонов физической памяти:


Обратите внимание на пробел в адресном пространстве со страницы 9F000 до страницы 100000, и ещё один от DFE6D000 до FFFFFFFF (4 Гб). Однако, когда я загружаюсь на этой же системе в 64-х битной Vista, все 4 Гб показываются как доступные и вы можете видеть, как Windows использует ещё 500 Мб оперативной памяти, находящиеся выше границы в 4 Гб:


Откуда берутся эти пробелы ниже 4 Гб? На этот вопрос нам поможет ответить Диспетчер Устройств. Для проверки, запустите "devmgmt.msc", выберите "Ресурсы по подключению" в меню "Вид", и разверните узел "Память". На моём ноутбуке главным похитителем памяти стала, что и неудивительно, видеокарта, которая потребляет 256 Мб в диапазоне E0000000-EFFFFFFF:


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

Потребление адресов памяти ниже 4 Гб может быть весьма значительным на топовых игровых конфигурациях, имеющими видеокарты с большими объёмами памяти. Например, я купил одну такую систему в бутике игрового стенда компании - она шла с 4 Гб памяти и двумя видеокартами по 1 Гб каждая. Я не уточнил версию ОС, полагая, что они сообразят поставить 64-х битную Виста, но система пришла с 32-х битной версией. В результате только 2.2 Гб памяти было доступно для Windows. Вы можете увидеть гигантскую дыру в памяти с адреса 8FEF0000 по FFFFFFFF в следующем выводе Meminfo с этой системы после того, как я поставил на неё 64-х битную версию Windows:


Диспетчер Устройств показывает, что 512 Мб из этой дыры в зарезервированно для видеокарт (256 Мб каждая), и похоже, что firmware просто зарезервировало больше памяти, либо для динамического проецирования, либо же в результате использования консервативных оценок:


С такими проблемами могут встретиться даже системы имеющие на борту только 2 Гб. Проблемы возникают из-за чипсетов, агрессивно резервирующих регионы памяти для устройств. Наш общий семейный компьютер, который мы купили всего несколько месяцев назад от известного OEM поставщика, сообщает о доступности только 1.97 Гб из 2-х установленных:


Диапазон физических адресов от 7E700000 до FFFFFFFF зарезервирован шиной PCI и устройствами, что оставляет теоретический максимум физического адресного пространства в 7E700000 байт (1.976 Гб), но даже часть из этого резервируется для памяти устройств, что оставляет Windows только 1.97 Гб.


Поскольку теперь производители устройств обязаны отправлять как 32-х битный, так и 64-х битный драйвера в лаборатории Windows Hardware Quality Laboratories (WHQL) для получения сертификата подписи, то большинство производителей устройств сегодня могли бы поддерживать физические адреса выше 4 Гб. Однако, 32-х битные Windows будут продолжать игнорировать память выше этой границы, потому что всё ещё существуют определённые сложности с измерением риска такого изменения, а производители OEM двигаются (или, по крайней мере, должны) в сторону перехода на 64-х битные Windows, где эта проблема просто не стоит.

Суть заключается в том, что вы можете использовать всю установленную у вас память (до предела, установленного редакцией системы) с 64-х битной Windows, вне зависимости от её количества, и если вы покупаете высокопроизводительную геймерскую систему, то вам определённо стоит попросить продавца установить на неё 64-х битную Windows.

Достаточно ли у вас памяти?

Вне зависимости от того, сколько памяти у вас есть, настоящий вопрос заключается в том, достаточно ли этой памяти? К сожалению, не существует какого-либо простого правила, с помощью которого вы точно узнаете ответ на этот вопрос. Хотя есть общее руководство, которое вы можете использовать, оно основано на мониторинге доступной системе памяти за промежуток времени, особенно в моменты работы приложений, требовательных к памяти. Windows определяет доступную память как физическую память, которая не была привязана к процессу, ядру или драйверу устройства. Как следует из этого названия, доступная память доступна для присвоения её по требованию процесса или системы. Системный менеджер памяти, конечно же, пытается использовать максимум памяти, используя свободную память как файловый кэш (список standby), как обнулённую память (список страниц, заполненных нулями), а функция Superfetch в Vista также использует её для предзагрузки (prefetch) данных и кода в списке standby и упорядочивает их по наибольшей вероятности использования в ближайшее время.

Когда доступная память становится дефицитом, это означает, что либо процессы, либо система активно используют физическую память, и если доступная память находится в районе нуля продолжительное время, то вы вероятно выиграете от установки большего количества памяти. Есть несколько способов отслеживать доступную память. В Windows Vista вы можете неявно следить за доступной памятью, наблюдая за историей использования физической памяти (Physical Memory Usage History) в Диспетчере Задач, Task Manager. Вот снимок экрана Диспетчера Задач на моём настольнике с 8 Гб памяти (хмм, я думаю, что у меня, пожалуй, даже слишком много памяти!):


На всех версиях Windows вы можете увидеть график доступной памяти, используя оснастку Производительность (Performance Monitor) и добавляя в ней счётчик Available Bytes из раздела Memory:


Вы также можете видеть мнгновенные значения в диалоге System Information утилиты Process Explorer, или, на версиях Windows до Vista, на вкладке Производительность Диспетчера Задач (Task Manager's Performance page).

Преодолевая пределы

Из процессора (CPU), памяти и дисков - память обычно наиболее важна для общей производительности системы. Чем больше памяти - тем лучше. И 64-х битные Windows являются способом убедиться, что вы используете все возможности вашей системы. Кроме того, 64-х битные Windows могут иметь и другие бонусы в плане производительности, о которых я поговорю в следующем посте серии Pushing the Limits, когда я буду говорить о виртуальной памяти.