/3GB переключатель на сервере win2k3 с 6 ГБ ОЗУ и PAE
В настоящее время мы оцениваем добавление параметра /3gb на некоторые из наших серверов, чтобы увеличить доступную память для одного из запущенных процессов (который скомпилирован с установленным флагом IMAGEFILELARGEADDRESSAWARE), который ограничивает ограничение в 2 ГБ.
Однако я пытаюсь понять, как распределяется память между ядром и пользовательскими процессами на сервере с> 4 ГБ ОЗУ. Согласно документу, Windows разделит память 2 ГБ / 2 ГБ между ядром и пользовательскими процессами в системе 4 ГБ. Когда вы включаете / 3 ГБ на сервере, память разделяется на 1 ГБ / 3 ГБ.
То, что я хочу знать, как разделение памяти на сервере с 6 ГБ ОЗУ и включенным PAE?? Ядро все еще ограничено до 1 ГБ??
Ура Сэм
7 ответов
Я думал, что я опубликую продолжение для других, чтобы попытаться объединить информацию в один пост (на основе того, что я узнал, и другой информации, уже опубликованной).
PAE:
PAE позволит использовать 32-битный сервер Windows или более 4 ГБ ОЗУ, причем максимальный размер зависит от версии Windows, которую вы используете (Википедия имеет хорошую ссылку здесь)
Стоит отметить, что если у вас включены функции предотвращения выполнения данных (DEP) или NoExecution (NX), то это эффективно активирует PAE без необходимости явно включать его в boot.ini.
В итоге, PAE не влияет на объем памяти, к которому может обращаться один 32-битный процесс. Он влияет только на общий объем памяти, который окна могут "видеть" и использовать (таким образом, вы можете иметь 2 процесса, каждый из которых использует 2 ГБ, а Windows - 2 ГБ в системе 6 ГБ)
3GB:
Во-первых, когда я говорю о памяти, доступной одному 32-битному процессу, я ссылаюсь на виртуальное адресное пространство процессов. Для 32-битного процесса в 32-битной ОС Windows это ограничено 4 ГБ.
В системе без ключа /3GB 4 ГБ виртуального адресного пространства разделено на 2 ГБ / 2 ГБ между запущенным процессом и ядром Windows.
При включении переключателя 3 ГБ раздел виртуального адресного пространства изменяется на 3 ГБ / 1 ГБ. Это позволяет процессу использовать больше памяти за счет памяти ядра. Обратите внимание: Windows разрешит процессу использовать больше 2 ГБ или памяти, только если исполняемый файл скомпилирован с установленным флагом IMAGEFILELARGEADDRESSAWARE.
Теперь, как было упомянуто в других постах, штраф за использование переключателя 3 ГБ состоит в том, что у ядра меньше памяти для работы. И одной из основных жертв сокращения объема памяти является количество доступных записей таблицы страниц (PTE). Таблица страниц - это структура данных, используемая диспетчером виртуальной памяти Windows для хранения соответствия между виртуальными адресами и физическими адресами в памяти. Если у вас недостаточно свободных PTE, окна могут не выделить память для процесса по запросу, даже если процесс еще не исчерпал свое адресное пространство.
Количество свободных PTE может быть измерено с помощью perfmon (\Memory\Free System Page Table Entries). Все, что ниже 5000, считается критически важным для Microsoft. Например, на серверах, упомянутых в исходном посте, без переключателя 3 ГБ и при запущенном процессе число свободных PTE составляло около 160 КБ. После включения 3 ГБ, но до начала процесса, Windows сообщала о 3,5 тыс. Свободных PTE (значительное сокращение). Это число быстро упало бы, если бы мы начали процесс.
Способ компенсировать это существенное изменение состоит в том, чтобы включить переключатель USERVA в файле boot.ini. Установив USERVA=2800, это перемещает разделенную память в 3 ГБ / 1 ГБ и "возвращает" обратно около 250 МБ ядру для его использования. Например, после установки значения USERVA = 2800 в файле boot.ini в нашей системе количество свободных PTE теперь составляет около 60 тыс. При запущенном процессе (намного лучше, чем у 3,5 тыс., Которые мы видели).
Дополнительную информацию о переключателе USERVA можно найти в статье Microsoft KB.
Стоит также отметить, что включение PAE также влияет на количество свободных PTE. Переключатель PAE заставляет каждую запись PTE использовать в два раза больше обычного выделенного виртуального адресного пространства.
Надеемся, что это обеспечивает хорошее краткое резюме информации для тех, кто смотрит на более позднюю дату.
Ура Сэм
Послушайте этот эпизод RunAs Radio.
Основное внимание в этом эпизоде уделяется очевидному "почему 64-битная версия лучше", однако гость задается вопросом "почему /3 ГБ следует избегать". По сути, это значительно сокращает количество записей таблицы страниц, доступных для ОС, - настолько, что ОС может стать нестабильной.
В ореховой оболочке - это может быть уместно для сервера, который обслуживает одну функцию (например, контроллер AD или SQL Server), однако этого следует избегать в системе, которая предоставляет несколько функций. В конце дня "ваш пробег может отличаться" - помните, что /3GB может легко сделать ОС нестабильной.
Возможно, вы захотите рассмотреть 64-битную ОС, даже если приложение только 32-битное. В Windows x64 32-разрядные процессы получают 4 ГБ ОЗУ, а не 2 ГБ.
Подробнее см. Раздел "Виртуальная память" в KB294418.
В моей предыдущей системе я использовал ключ /3GB, потому что одному из моих приложений требовалось много памяти. Недавно я перешел на 64-битную систему Vista и обновил приложение до 64-битной версии, что дает ему все 12 ГБ, которые есть у меня сейчас. Однако другие 32-разрядные приложения по-прежнему ограничены теми же 3 ГБ памяти (или 2 ГБ без коммутатора) просто потому, что они не могут видеть за пределами размера указателя адреса. (А в 32-битных системах адресные указатели 32-битные...)
Тем не менее, ключ /3GB в сочетании с более чем 3 ГБ ОЗУ по-прежнему полезен, если сама Windows способна обрабатывать большие адресные указатели. Это позволяет Windows хранить больше приложений в памяти, и, следовательно, намного меньше загружать их на диск, что повышает производительность.
PAE - аппаратный трюк, в котором у процессора есть еще несколько контактов для отправки адреса. Они увеличились с 32 контактов (бит) до 36 контактов. Это позволяет использовать до 64 ГБ оперативной памяти для любого приложения, которое знает об этих дополнительных выводах. Microsoft хорошо использует это в своем серверном программном обеспечении, поэтому Windows может обрабатывать до 64 ГБ. Если процесс, который потребляет столько памяти, также знает об этих дополнительных выводах, он также может выделить до 64 ГБ ОЗУ. Этот метод для приложений называется расширением адресного окна. Конечно, это также требует специального кода в приложении для обработки этой памяти и напоминает мне о старой эпохе MS-DOS, когда указатели приложений были ограничены сначала только 16 битами (64 КБ), но поскольку процессор имел 20 контактов (позже 24), вы можете использовать специальные 32-битные указатели, чтобы указывать на адрес, или просто придерживаться старых 16-битных указателей и ограничиваться только 64 КБ. (20 бит - это 1024 КБ, а DOS использовала все, что выше 640 КБ или 1 ГБ. 24 бит - это 4 ГБ, что было популярно для первых процессоров 80386 в качестве верхнего предела.)
Рэймонд Чен (Raymond Chen), один из программистов оболочки Windows для Microsoft, опубликовал в своем блоге большую серию статей о ключе /3GB, PAE, AWE и NX. Их нужно обязательно прочитать всем, кто пытается понять, как все это работает, как оно взаимодействует и почему во многих случаях это, вероятно, не то, что вам нужно:
http://blogs.msdn.com/oldnewthing/archive/2004/08/22/218527.aspx
Из того, что я знаю, коммутатор PAE обеспечивает доступ к памяти свыше 4 ГБ для приложений на сервере. Согласно этому техническому замечанию приложения на самом деле не знают об этой перестановке памяти, все это обрабатывается в Windows. Я думаю, что использование параметра /3GB на сервере 6GB ограничит ядро до 1GB. Еще одно ограничение, вызванное одновременным использованием /3GB и /PAE, заключается в том, что сервер не будет обрабатывать более 16 ГБ.
Если вы не пытаетесь использовать каждый МБ памяти для приложения, вы можете просто использовать /PAE без /3GB. Таким образом, если когда-нибудь вы получите в общей сложности 24 или 32 ГБ ОЗУ, вам не придется пытаться понять, почему Windows использует только 16 ГБ.
Когда я читаю превосходный пост Марка Руссиновича " Расширяя границы Windows: физическая память", да... что 1 ГБ памяти, доступной ядру при 32-разрядной установке Windows с параметром / 3 ГБ, сохраняется даже в системах с объемом до 128 ГБ. ОЗУ (поддерживается на 32-битных установках W2K3 Datacenter).
Максимальный 32-разрядный предел в 128 ГБ, поддерживаемый Windows Server 2003 Datacenter Edition, обусловлен тем фактом, что структуры, которые диспетчер памяти использует для отслеживания физической памяти, будут занимать слишком много виртуального адресного пространства системы в более крупных системах. Диспетчер памяти отслеживает каждую страницу памяти в массиве, называемом базой данных PFN, и для производительности отображает всю базу данных PFN в виртуальную память. Поскольку каждая страница памяти представлена 28-байтовой структурой данных, базе данных PFN в системе объемом 128 ГБ требуется около 930 МБ. 32-битная Windows имеет виртуальное адресное пространство 4 ГБ, определяемое аппаратным обеспечением, которое по умолчанию разделяется между выполняющимся в данный момент процессом пользовательского режима (например, Блокнотом) и системой. Таким образом, 980 МБ потребляет почти половину доступного 2 ГБ виртуального адресного пространства системы, оставляя только 1 ГБ для отображения ядра, драйверов устройств, системного кэша и других структур данных системы, что делает разумное сокращение:*