Управление оперативной памятью - Адресное пространство SQL Server

Адресное пространство SQL Server

В любой операционной системе производства корпорации Microsoft общий объем виртуальной памяти, доступный некоторому приложению, называется адресным пространством этого приложения. Для SQL Server максимальный размер виртуальной памяти составляет 2 Гбайт, если только не используется специальный режим. В файле boot.ini операционной системы Windows NT Enterprise Edition или Windows 2000 Advanced Server можно воспользоваться переключателем /3GB для увеличения размера адресного пространства до 3 Гбайт.

У каждого экземпляра SQL Server имеется адресное пространство, состоящее из двух основных компонентов. Один основной компонент представляет собой буферный пул, который выделяет оперативную память порциями (или буферами) по 8 Кбайт. Как SQL Server 2000, так и SQL Server 7.0 используют это пространство для хранения страниц данных и индексов, которые SQL Server считывает с жесткого диска; кэша журнала транзакций; планов исполнения запросов и хранимых процедур; системных конструкций, таких как таблица блокировок; а также для информации пользовательских процессов. Кое-что из перечисленного можно увидеть при помощи системных хранимых процедур sp_who и sp_who2. Обычно адресное пространство этой области занимает почти весь объем оперативной памяти машины. Однако можно ограничить количество памяти, которое SQL Server будет в состоянии использовать для буферов кэширования, если при создании конфигурации SQL Server указать параметр max server memory , то есть максимальный размер оперативной памяти, доступный для SQL Server.

Второй компонент адресного пространства SQL Server представляет собой область памяти, которую я обычно называю небуферным пулом. Эта область оперативной памяти зарезервирована, прежде всего, для компонентов исполняемого кода или для компонентов, требующих выделения больших объемов оперативной памяти порциями, превосходящими 8 Кбайт. К числу таких компонентов относятся: исполняемые файлы и динамические библиотеки DLL, которые используют в работе Open Data Services и серверные сетевые библиотеки Network-Libraries; библиотеки DLL поставщика OLE DB для сервера, на котором функционирует SQL Server; а также расширенные хранимые процедуры, используемые в динамических библиотеках DLL и системных хранимых процедурах OLE Automation для создания экземпляров объектов OLE Automation. Эта область памяти может также содержать планы исполнения запросов и хранимых процедур, которым требуются большие объемы памяти.

Когда служба SQL Server стартует, операционная система загружает в оперативную память исполняемые модули SQL Server и те статические библиотеки DLL, которые требуются операционной системе. После этого резервируется секция адресного пространства для использования в качестве небуферного пула. По умолчанию SQL Server резервирует 128 Mбайт общего адресного пространства плюс необходимый размер памяти для стеков всех потоков. Этот размер вычисляется на основании указываемого в конфигурации параметра max worker threads (максимальное количество рабочих потоков). Для одного потока резервируется примерно 0,5 Mбайт памяти.

Буферный пул забирает все оставшееся адресное пространство. В течение всего времени работы SQL Server это пространство будет доступно исключительно буферному пулу (и связанным с ним объектам памяти, которые также используют страницы размером по 8 Кбайт и поэтому могут брать память из буферного пула).

В файле readme_txt, который сопровождает пакет SP2, обсуждается применение для SQL Server 7.0 стартового переключателя /g memory_to_reserve, который можно использовать для изменения размера области оперативной памяти, выделяемого в качестве резерва для небуферного компонента адресного пространства. Вот что там говорится:

[Этот переключатель] задает целое число мегабайтов оперативной памяти, которые SQL Server оставит доступными для распределения памяти внутри процесса SQL Server, однако за пределами пула оперативной памяти SQL Server. Пул оперативной памяти представляет собой область памяти, которую SQL Server использует для загрузки в нее специфических элементов. К ним относятся файлы библиотек .dll для расширенных хранимых процедур; поставщики OLE DB, к которым обращаются распределенные запросы, а также объекты OLE Automation, на которые имеются ссылки в предложениях Transact-SQL.

Мне показалось, что это описание, содержащееся в файле readme_txt, может внести некоторую путаницу из-за неоднозначной трактовки терминов. Наибольшие сомнения вызывает использование термина пул оперативной памяти, memory pool. Специалисты, работающие в команде разработчиков SQL Server в корпорации Microsoft, сказали мне, что при общении между собой они никогда не употребляют термин пул оперативной памяти. Поэтому я буду продолжать использовать термины буферный пул и небуферный пул.