Механизмы масштабирования Windows 2000

Часть 1

В настоящее время термин «сервер для корпоративного сектора рынка» относится к системам с четырьмя и более процессорами и объемом оперативной памяти в несколько гигабайт. До недавнего времени на этом рынке доминировали операционные системы семейства UNIX благодаря достигнутому на протяжении 90-х гг. высокому уровню производительности, надежности, управляемости и гарантированной готовности. Чтобы стать реальной альтернативой UNIX на рынке корпоративных серверов, Windows 2000 должна превзойти ее по всем этим показателям.

Длинный список новых возможностей и усовершенствований, которые действительно позволяют считать разработку Windows 2000 значительным шагом вперед, включает и устранение недостатков, не позволивших Windows NT 4.0 выйти на рынок высокопроизводительных систем. В предлагаемой статье я хочу остановиться на возможностях Windows 2000, благодаря которым, по мнению разработчиков Microsoft, она превратиться в действительно масштабируемую операционную систему. Статья будет состоять из двух частей. В первой части я расскажу о новых возможностях Windows 2000 и приемах оптимизации, которые позволяют данной операционной системе более полно использовать большие объемы оперативной памяти. В следующем номере речь идет о многопроцессорных средствах Windows 2000.

Масштабируемость и оперативная память

Серверы масштаба предприятия, как правило, интенсивно используют оперативную память. Обычно они работают с объемами данных, исчисляемых десятками гигабайт, что сопряжено с жесткими требованиями к объему, установленной на сервере физической памяти. Типичный пример такой ситуации - сервер баз данных, обслуживающий многогигабайтную БД предприятия или несколько баз данных масштаба подразделения общим объемом в несколько гигабайт. Другие примеры интенсивного использования памяти крупными серверами - системы планирования ресурсов предприятия (Enterprise Resource Planning, ERP), приложения из сферы научных исследований или финансового анализа, где объем данных также исчисляется многими гигабайтами. Задержка при обращении к устройствам массовой памяти в несколько раз больше, чем при обращении к оперативной памяти; то же касается и пропускной способности. Именно поэтому весьма желательно, чтобы сервер мог хранить в оперативной памяти весь рабочий набор данных или хотя бы значительную его часть.

Рассмотрим гипотетический запрос к базе данных, размер которой составляет 6 Гбайт. Если в распоряжении сервера имеется только 1 Гбайт оперативной памяти, то в процессе выполнения запроса системе управления базой данных придется последовательно считать с диска содержимое всей базы в память сервера. При пропускной способности дисковой подсистемы 10 Мбайт/c запрос займет около 10 мин. Но если на том же сервере имеется 8 Гбайт оперативной памяти, вся база данных целиком поместится в кэш, и никаких обращений к диску не будет вовсе. При пропускной способности физической памяти порядка 1 Гбайт/с на тот же самый запрос уйдет всего несколько секунд. Приведенный пример иллюстрирует разницу между сервером, мощность которого адекватна объему обслуживаемых данных, и сервером, вынужденным полагаться на дисковую подсистему.

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

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

Большинство 64-разрядных операционных систем без труда справляются с такими требованиями. Эти ОС в состоянии адресовать всю установленную в системе память, поскольку выполняются на 64-разрядных аппаратных платформах. То же утверждение справедливо и для 64-разрядных приложений. В их распоряжении имеется 264 разряда для адресации, поэтому уже сейчас объем физической памяти, доступный такому приложению, значительно превосходит объемы оперативной памяти вычислительных систем обозримого будущего. Однако 32-разрядные операционные системы явно не соответствуют указанным требованиям. Это вынуждает разработчиков ОС создавать дополнительные механизмы для обслуживания огромных объемов памяти на серверах масштаба предприятия.

Экран 1. Виртуальное адресное пространство приложения.

Первый недостаток 32-разрядных ОС состоит в том, что они ориентированы на 32-разрядные компьютеры, в частности аппаратные платформы на базе процессоров Intel x86. Исторически сложилось так, что эти системы поддерживают не более 4 Гбайт физической памяти (для адресации используется 2³² байт = 4 Гбайт). Второй недостаток связан с общепринятым в таких системах методом хранения указателя в виде 4-байтового целого, что ограничивает объем виртуальной памяти, доступной приложению, 4 Гбайт. Большинство операционных систем, включая Windows 2000, NT и UNIX, делят виртуальное адресное пространство приложения на две области (см. Рисунок 1). Первая предназначена для нужд самого приложения, а вторую занимают ядро операционной системы, драйверы устройств и кэш файловой системы. Такой симбиоз позволяет ОС и драйверам устройств непосредственно обращаться к адресному пространству приложения, что обеспечивает эффективность обмена данными между приложением и службами операционной системы. Если бы ОС и приложение располагались в отдельных адресных пространствах, каждый системный вызов, включая операции ввода/вывода, сопровождался бы пересылкой данных между областью приложения и областью ОС, что сопряжено со значительными накладными расходами.

В NT 4.0 граница проходит посредине 4-гигабайтного адресного пространства, так что 2 Гбайт отводится приложению, а еще 2 Гбайт остается на нужды операционной системы. Администраторы систем Windows NT Server Enterprise Edition (NTS/E) для платформы x86, Windows 2000 Advanced Server (Windows 2000 AS) и Windows 2000 Datacenter Server (Datacenter) могут изменить пропорцию деления адресного пространства с помощью загрузочного переключателя /3GB. В этом случае под область приложений будет отведено 3 Гбайт, а системе останется 1 Гбайт памяти.

Размер адресного пространства, отведенного приложению, ограничивает максимальный объем данных, которыми оно может манипулировать непосредственно. Например, если на 32-разрядном сервере баз данных установлено 4 Гбайт оперативной памяти и используется схема деления 3:1, то этот сервер потенциально может обслуживать до 3 Гбайт оперативных данных без обращения к дисковой подсистеме. Анализ производительности усложняется, если ОС обслуживает обращение приложения к диску из файлового кэша; в этом случае фактического обмена с диском может не быть вовсе. В результате даже при наличии всего 3 Гбайт собственной виртуальной памяти приложение под управлением NT 4.0 может при некоторых условиях прямо или косвенно иметь доступ почти к 4 Гбайт физической памяти (конечно же, если система располагает таким объемом). Впрочем, вопрос о том, какие именно данные хранятся в кэше за пределами 3 Гбайт адресного пространства приложения, находится вне его компетенции - за это отвечает операционная система. И, наконец, если на сервере выполняется несколько активных приложений, операционная система разделяет физическую память сервера между ними.

Преодоление барьера 4 Гбайт на платформе x86

Архитектура x86 обслуживает не более 4 Гбайт внутренней и внешней физической памяти, в то время как операционная система может поддерживать больше. Чтобы процессоры семейства x86 могли обеспечить использование более 4 Гбайт физической памяти, нужно было внести изменения в их архитектуру. Поскольку разработчики Intel быстро осознали, что четырехгигабайтное ограничение будет препятствовать увеличению доли платформ x86 на рынке систем масштаба предприятия, процессоры x86 были дополнены новыми режимами работы. Так, в процессорах семейства Pentium Pro реализован новый режим расширения физического адреса (Physical Address Extension, PAE), а в процессорах Pentium II впервые использована 36-разрядная технология адресации с расширенной страницей (Page Size Extension, PSE36).

В обычном режиме работы процессоры x86 обеспечивают поддержку двухуровневой страничной архитектуры для преобразования виртуальных адресов (которыми оперируют и операционная система, и приложения) в физические адреса (которые используются запоминающим устройством). Блок управления памятью (Memory Management Unit, MMU) процессора x86 делит виртуальный адрес на три поля, как показано на Рисунке 2. Специальный регистр процессора CR3 указывает на структуру данных каталога страниц, а первое поле виртуального адреса служит индексом к этому каталогу. Блок MMU выбирает соответствующий четырехбайтный адрес из элемента каталога страниц (Page Directory Entry, PDE) по указанному индексу, локализуя таким образом таблицу страниц. Второе поле виртуального адреса задает элемент этой таблицы. Записи таблицы страниц (Page Table Entries, PTE) представляют собой четырехбайтное слово (32 бит). Элемент таблицы страниц определяет 20-разрядный адрес физической страницы, а поскольку в архитектуре x86 размер страницы равен 4096 (2¹²) байт, максимальный адрес, который может быть сформирован таким образом, составляет 2²⁰⁺¹² байт, что соответствует 4 Гбайт физической памяти. Последнее поле виртуального адреса задает смещение на странице, на которую указывает запись таблицы страниц.

Технология PSE36 позволяет операционной системе выдать блоку управления памятью команду выполнения одноуровневой трансляции виртуального адреса по указанной точке входа в каталоге страниц (см. Рисунок 3). Операционная система инициирует одноуровневую трансляцию с помощью маркировки записи в каталоге страниц атрибутом «страница расширенного размера» (Page-Size Exten-ded). При этом MMU использует физический адрес, хранящийся в элементе каталога страниц, как окончательный адрес страницы, а не адрес таблицы страниц. Кроме того, в MMU применяются 14-разрядные адреса страницы вместо стандартных 20-разрядных, но в этом режиме система работает с 4-мегабайтными (2²² байт), а не 4-килобайтными страницами. В результате этих ухищрений можно получить 36-разрядные физические адреса (14-разрядный адрес страницы плюс 22-разрядный размер страницы), которых вполне достаточно для адресации 64 Гбайт физической памяти.

Экран 4. Операция записи в память при использовании механизма PSE86.

Недостатком архитектуры PSE36 является увеличение размера страниц (4 Мбайт вместо стандартных 4 Кбайт): это малоэффективно при обычных операциях. В начале 1998 г. в Intel был разработан специальный драйвер устройства Intel PSE36 Driver, позволяющий приложениям, использующим архитектуру PSE36, адресовать память за пределами 4 Гбайт. Этот драйвер работает только под управлением NTS/E и разрешает использовать более 4 Гбайт памяти только одному приложению, причем только в качестве виртуального диска (RAM-диска). Адресное пространство приложения и операционной системы по-прежнему располагается в пределах 4-гигабайтной области, поэтому, когда приложению необходимо записать данные в память PSE36, оно извещает об этом драйвер PSE36, который копирует данные из буфера приложения в указанную область памяти за пределами 4 Гбайт. Этот процесс представлен на Рисунке 4.

Наличие дополнительной физической памяти, доступной приложению благодаря архитектуре PSE36, обычно приводит к повышению производительности работы приложения, которому иначе пришлось бы обращаться к диску. К сожалению, копирование данных за 4-гигабайтную границу и обратно драйвером PSE36 может пагубно отразиться на общей производительности системы. Именно поэтому разработчики Microsoft не стали продвигать PSE36 и предпочли использовать режим расширенной физической адресации PAE, который обеспечивает поддержку больших объемов физической памяти на платформе x86.

Когда процессор x86 работает в режиме расширенной физической адресации, блок MMU делит виртуальные адреса на четыре поля (см. Рисунок 5). MMU по-прежнему пользуется каталогами и таблицами страниц, но здесь имеется дополнительный уровень - таблица указателей на таблицы каталогов (Page Directory Pointer Table). В режиме PAE возможность адресации большего объема памяти, чем в стандартном режиме трансляции адресов, достигается не только за счет дополнительного уровня, но еще и за счет того, что записи каталогов и таблиц страниц имеют длину 8 (двойное слово), а не 4 байт. В результате внутреннее представление физического адреса имеет длину 24 бит, что позволяет системам x86 поддерживать 2²⁴⁺¹² байт (64 Гбайт) памяти. Преимущество технологии расширенной физической адресации PAE перед PSE36 носит принципиальный характер: операционная система может использовать всю имеющуюся оперативную память как память общего назначения, так что операции копирования при обращении за пределы 4 Гбайт больше не нужны.

Поскольку режим PAE является дополнительным (его использовать не обязательно), а метод преобразования виртуальных адресов в физические отличается от принятого в стандартной архитектуре процессоров x86, разработчики операционных систем должны модифицировать код ОС для платформы x86 с учетом особенностей режима PAE. Специалисты Microsoft разработали версию ядра Windows 2000, которая реализует архитектуру PAE для платформы x86 при условии, что система поддерживает режим PAE и имеет более 4 Гбайт физической памяти. В этом случае загрузчик NT (NT Loader, NTLDR) вызывает ядро PAE ntkrnlpa.exe вместо стандартного ядра ntoskrnl.exe (существуют одно- и многопроцессорные версии ядра как для стандартного режима, так и для режима PAE). После загрузки ядра операционные системы Windows 2000 Professional и Windows 2000 Server ограничивают объем памяти, доступной приложениям, 4 Гбайт. В случае Windows 2000 Advanced Server, ядро с поддержкой режима PAE способно адресовать максимум 8 Гбайт памяти; ядро версии Datacenter в состоянии использовать максимум 64 Гбайт физической памяти, если система таким объемом располагает.

Address Windowing Extensions

Когда Windows 2000 находилась в стадии разработки, специалисты Intel создали набор микросхем 450NX, который позволяет процессорам семейства x86 использовать архитектуру расширенной физической адресации PAE для преодоления барьера в 4 Гбайт. Microsoft, в свою очередь, разработала универсальный интерфейс для применения в системах с большим объемом физической памяти. Используя этот интерфейс, который носит название «расширение адресного окна» (Address Windowing Extensions, AWE), приложение может, во-первых, запросить область физической памяти в исключительное пользование и, кроме того, получить доступ к любой части выделенной физической памяти с помощью так называемого адресного окна своего адресного пространства.

Для выделения физической памяти с помощью интерфейса AWE приложение вызывает функцию Allocate-UserPhysicalPages из состава API Win32. Затем приложение обращается к стандартной функции API Win32 VirtualAlloc для создания адресного окна в 4-гигабайтной области адресного пространства приложения. Функция VirtualAlloc устанавливает флаг MEM_PHYSICAL. Для ядра Windows 2000 это означает, что приложение создает адресное окно. После того как физическая память выделена, а окно создано, приложение может отобразить любой фрагмент физической памяти в созданном адресном окне. Например, если приложение создает адресное окно размером 256 Мбайт и выделяет для своих нужд 4 Гбайт физической памяти (при условии, что такой объем памяти в системе реально имеется), с помощью функций Map-UserPhysicalPages и MapUserPhysi-calPagesScatter API Win32 оно может обращаться к любой части физической памяти, отображая ее на 256-мегабайтное адресное окно. Размер окна приложения задает максимальный объем физической памяти, к которому приложение может получить доступ с помощью отображения. Процесс отображения физической памяти в адресное окно AWE показан на Рисунке 6.

Экран 7. Адресное окно AWE.

Интерфейс AWE имеется во всех версиях Windows 2000, он активизирован независимо от объема установленной в системе памяти. Тем не менее технология AWE наиболее эффективна для систем с объемом физической памяти не менее 2 Гбайт. Поскольку приложениям отводится лишь 2 или 3 Гбайт собственной виртуальной памяти (в зависимости от того, использовался переключатель /3GB при загрузке ОС или нет), API AWE позволяет приложениям непосредственно манипулировать значительно большим объемом памяти, чем позволяет их адресное пространство. Например, для системы под управлением Windows 2000 AS и объемом оперативной памяти 8 Гбайт сервер базы данных может с помощью AWE реализовать почти 8-гигабайтный кэш под данные БД, доступные через адресные окна интерфейса AWE.

Помимо предоставления приложениям прямого доступа к огромному объему физической памяти, механизм AWE обладает еще двумя важными преимуществами. Прежде всего, это единообразная поддержка на всех 32- и 64-разрядных платформах; кроме того, с памятью, выделенной с помощью AWE, могут работать практически все стандартные вызовы API Win32.

Работа с памятью в среде SMP

Помимо усовершенствований ядра операционной системы, которые позволили приложениям пользоваться огромными объемами физической памяти, разработчики Windows 2000 внесли дополнительные изменения в алгоритмы работы с оперативной памятью, чтобы повысить производительность многопроцессорных систем на базе Windows 2000. Еще в NT 4.0 было введено понятие резервного списка (Lookaside List) - пула буферов фиксированного размера в области памяти ядра, которые ядро Windows 2000 и драйверы устройств создают и используют в качестве кэша для решения тех или иных задач.

Когда какое-либо приложение выполняет запрос к файловой системе, например чтение из файла, подсистема диспетчера ввода/вывода (I/O Manager) должна выделить буфер для хранения структуры данных запроса (I/O Request Packet, IRP). Диспетчер ввода/вывода передает буфер драйверу файловой системы, обслуживающему чтение файла, к которому обратилось приложение. Когда драйвер файловой системы завершает обслуживание операции чтения, диспетчер ввода/вывода должен освободить буфер данных IRP. Без использования резервных списков диспетчер ввода/вывода вынужден часто выделять и освобождать буферы IRP. Именно для повышения производительности диспетчера ввода/вывода Windows 2000 предназначен резервный список. Вместо того чтобы возвращать буфер IRP в общий пул памяти, диспетчер ввода/вывода хранит его в резервной области IRP. Теперь при необходимости выделить буфер для обслуживания запроса ввода/вывода диспетчер будет проверять состояние резерва. Если в списке есть хотя бы один свободный буфер, диспетчеру ввода/вывода нет нужды обращаться к диспетчеру буферов ядра системы. Ядро отслеживает, как часто драйверы устройств или подсистема ядра обращаются к освободившимся буферам в пуле резерва, и в соответствии с частотой таких обращений оптимизирует размер резерва. Чем чаще происходят обращения, тем больше максимально допустимое число резервных буферов. Когда размер пула резерва достигает текущего максимума, ядро возвращает буферы резерва в общий пул памяти.

Разработчики Windows 2000 внесли изменения в организацию резервного пула для оптимизации производительности системы. В многопроцессорных серверах используется специальный механизм синхронизации кэшируемых данных. Его задача - обеспечить тождественность копий одних и тех же данных в кэше разных процессоров. Необходимость такой синхронизации на многопроцессорных системах ведет к дополнительным «накладным расходам», поскольку алгоритм синхронизации регулярно захватывает многопроцессорную шину данных, тем самым препятствуя работе процессоров. В NT 4.0 все процессоры совместно используют единый резервный пул буферов ввода/вывода; в результате обновление резервных списков ведет к снижению производительности системы из-за необходимости синхронизации. Кроме того, при наличии общего пула процессоры должны блокировать его на время доступа; в NT это делается с помощью механизма блокировок, что также ведет к непроизводительному использованию многопроцессорной шины и замедляет работу процессоров. Во избежание падения производительности Windows 2000 создает для каждого процессора отдельный пул резервных буферов.

В системе существует порядка 10 пулов резервных буферов для каждого процессора. Помимо собственно пула диспетчера ввода/вывода такую же технику организации резервных буферов используют и две другие подсистемы Windows 2000: диспетчер объектов (Object Manager) и диспетчер кэша (Cache Manager). Диспетчер буферов ядра системы также применяет этот метод для оптимизации создания пулов 32-байтных буферов для каждого из процессоров сервера. Когда драйвер устройства или подсистема ядра посылают запрос на выделение буфера размером 32 байт (или меньше), диспетчер буферов ядра старается сначала выполнить запрос с помощью освободившегося буфера из своего резервного списка.

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

Размер пула и размер кэша

В NT 4.0 реализован резидентный пул для неперемещаемой памяти. Здесь драйверы устройств и оперативной системы хранят структуры данных, которые должны постоянно оставаться в физической памяти и не перемещаться на диск. Диспетчер памяти рассчитывает размер резидентного пула на основе нескольких параметров, в том числе в зависимости от того, сколько физической памяти установлено в системе (максимальный размер резидентного пула для NT 4.0 составляет 128 Мбайт). Работа драйвера Microsoft TCP/IP, выделяющего память из резидентного пула для каждого TCP/IP-соединения, напрямую зависит от размера резидентного пула. Таким образом, размер резидентного пула, в частности, ограничивает число одновременных TCP/IP-соединений. В процессе работы Web-сервера предприятия драйверам TCP/IP и другим драйверам может потребоваться объем памяти, превышающий предельный размер резидентного пула. В связи с этим разработчики Microsoft повысили объем максимально выделяемой памяти для резидентного пула в Windows 2000 до 256 Мбайт. При этом используются более компактные структуры данных для обслуживания резидентного пула, что позволяет дополнительно сэкономить память.

И, наконец, в NT 4.0 подсистема диспетчера кэша может использовать максимум 256 Мбайт виртуального адресного пространства, которое выделяет ей диспетчер памяти. В Win-dows 2000 этот предел повышен до 960 Мбайт. Увеличение доступного объема памяти позволяет диспетчеру кэша эффективно обслуживать большее число кэшированных файлов, поскольку ему не придется выполнять дополнительные операции по отображению физической памяти в область виртуальной кэш-памяти. Однако увеличение объема виртуальной памяти, отводимой под кэш, никак не влияет на число операций ввода/вывода, которые выполняет подсистема диспетчера кэша. Довольно широко распространено представление о том, что в операционных системах Windows 2000 и NT 4.0 кэш файловой системы использует физическую память лишь в пределах размера виртуального кэша. Между тем это совершенно неверно. На самом деле диспетчер кэша и в Windows 2000, и в NT 4.0 использует всю имеющуюся физическую память компьютерной системы.

Масштабируемость многопроцессорных систем

Новые средства операционной системы Windows 2000, которые позволяют ядру и приложениям использовать большие объемы физической памяти, чем это было доступно NT 4.0, расширяют сферу применения данной ОС до систем корпоративного класса и задач масштаба предприятия. Более того, оптимизация вопросов совместного использования памяти несколькими процессорами позволяет более эффективно применять Windows 2000 в многопроцессорных системах, что также будет способствовать ее продвижению на рынок операционных систем для серверов корпоративного класса. В следующей статье я продолжу рассказ о масштабируемости Windows 2000 и остановлюсь на тех характеристиках новой операционной системы и методах оптимизации производительности, которые помогут ядру Windows 2000 и приложениям более эффективно работать на многопроцессорных системах.

МАРК РУСИНОВИЧ - доктор философии и редактор Windows 2000 Magazine. С ним можно связаться по электронной почте по адресу: mark@sysinternals.com, или через Web-узел http://www.sysinternals.com