Главная | Контакты



Главная > Программы > Microsoft MSSQL

Средства управления памятью в SQL 2000

Средства управления памятью в SQL Server 2000

По материалам статьи Ken Henderson: Inside SQL Server 2000's Memory Management Facilities. Январь 2004. Библиотека MSDN.
В этой статье исследуется внутренняя организация и управление памятью SQL Server. Статья ориентирована на разработчиков и является выдержкой из книги: The Guru's Guide to SQL Server Architecture and Internals (Addison-Wesley, 2003).

Введение

В этой статье, мы исследуем внутреннюю организацию и управление памятью SQL Server, ориентируясь на потребности в таких знаниях разработчиков программного обеспечения. То есть мы рассмотрим способы, с помощью которых сервер управляет памятью, и будем делать это в терминах интерфейсов и иных средств операционной системы, которые для этого используются, а также, мы узнаем, как всё это работает. Исследование программного обеспечения - это верный способ понять заложенные разработчиками принципы его работы, его предназначение и методы использования. Понимание внутренней организации программы и правила её использования - ключ успешной её эксплуатации.
Начнем мы наше исследование беглым обзором некоторых основных принципов управления памятью в Windows. Подобно всем 32-разрядным приложениям Windows, SQL Server использует для распределения свободных ресурсов памяти и управления ими средства управления памятью операционной системы. Для этого используются функции управлением памятью специализированного программного интерфейса (Win32 API), которые позволяют организовать взаимодействие с ресурсами памяти, и предоставляются операционной системой в распоряжение SQL Server точно так же, как и любому другому приложению под управлением Windows.
Поскольку практически все распределения памяти у SQL Server используют виртуальную память (а не динамическую память - хип), большинство внутреннего кода, использующего распределения, используют запросы к функциям Win32 API: VirtualFree или VirtualAlloc. Сервер вызывает VirtualAlloc для резервирования и передачи виртуальной памяти, а VirtualFree для её освобождения.

Отличия виртуальной и физической памяти

В семействе процессоров x86, Windows предоставляет процессам до 4GB виртуальной памяти. Под словом "Виртуальная", я подразумеваю, что память - не является памятью в традиционном смысле. Это просто диапазон адресов, без физического места хранения, и эти адреса неявно привязаны к месту хранения. Когда процесс выполняет распределение памяти, он эти адреса использует, а физическое хранилище привязывается уже к этим адресам. Однако, физическое хранилище не обязательно является физической памятью. Чаще всего этим хранилищем является диск. Определенно, для этого используется системный файл(ы) подкачки. С помощью такого механизма несколько приложений могут работать на системе с 128 МБ памяти, и каждое будет владеть виртуальным адресным пространством в 4 ГБ, хотя это будет и не реальная память, но она будет доступна приложению. Очевидно, Windows использует копирование данных в файл подкачки для того, чтобы приложение могло распределить больше памяти, чем физически имеет компьютер, и так, чтобы несколько приложений могли иметь равный доступ к физической памяти компьютера.
4 ГБ адресного пространства разделены на два раздела: раздел непривилегированного режима и раздел привилегированного режима. По умолчанию, каждый из эти разделов имеет размер в 2 ГБ, хотя Вы можете изменить это, используя установки в файле BOOT.INI, который присутствует в семействе операционных систем Windows NT (Windows NT, Windows 2000, Windows XP и Windows Server 2003 - члены семейства Windows NT; Windows 9x и Windows ME в это семейство не входят).

Хотя каждый процесс получает его собственное виртуальное адресное пространство памяти, код операционной системы и код драйверов устройств совместно используют одну область частного адресного пространства. Каждая страница виртуальной памяти связана со специальным режимом процессора. Для страниц, которые в данный момент используются, процессор должен находиться в необходимом режиме. Это означает, что пользовательские приложения не могут непосредственно обращаться к виртуальной памяти привилегированного режима; система должна выполнить переключение в привилегированный режим для того, что бы память привилегированного режима стала доступной.

Тюнинг памяти

Опция начальной загрузки операционной системы /3GB (которая доступна для Windows 2000 в редакциях Advanced Server и Data Center) изменяет заданное по умолчанию разделение адресного пространства. С помощью этой опции адресное пространство непривилегированного режима для процесса расширяется от 2 ГБ до 3 ГБ, и делается это за счет адресного пространства привилегированного режима (которое уменьшается с 2 ГБ до 1 ГБ). В терминах Windows, этот способ известен как "Application Memory Tuning" или "4GB tuning" (4GT). Вы можете выполнить прикладной тюнинг памяти, добавив ключ /3GB к соответствующей строке в секции [operating systems] файла BOOT.INI Вашего сервера. Часто администраторы настраивают загрузку операционных систем так, чтобы система загружалась автоматически, и без ключа /3GB, но создают дополнительные варианты загрузки, имеющие тюнинговые ключи в секции [operating systems] файла BOOT.INI. Таким образом, администратор может выбрать любую опцию на этапе загрузки, но в случае внеплановой перезагрузки сервера, опции будут установлены такими, какими они были по умолчанию, или это набор тех опций, которые хорошо апробированы администратором в используемой конфигурации.

Предупреждение. Вы можете использовать ключ /3GB для загрузки Windows 2000 Professional и Windows 2000 Server. Однако, это приведёт только к отрицательным последствиям, т.е. будет сокращен объём памяти привилегированного режима до 1 ГБ, но не увеличится объём памяти непривилегированного режима! Другими словами, Вы не получите никакого выигрыша, а для привилегированного режима будет только проигрыш.

Примечание. В операционных системах Windows XP и Windows Server 2003 введена новая опция начальной загрузки: /USERVA, которая использоваться вместе с ключом /3GB, и позволяет более тонко управлять размером разделов, чем один ключ /3GB. Вы можете добавить /USERVA в Ваш файл BOOT.INI также, как это делалось с /3GB. Преимущество ключа /USERVA по сравнению с использованием только /3GB в том, что он позволяет задавать точный размер адресного пространства для непривилегированного режима. Например, /USERVA=2560 задаёт 2.5 ГБ для раздела непривилегированного режима и оставляет 1.5GB для ядра операционной системы. Ограничения, которые были перечислены для ключа /3GB, также справедливы и для этого ключа.

Исполнение программ, использующих не стандартную адресацию

До того, как в Windows была добавлена поддержка /3GB, приложения не могли обращаться к указателям с увеличенным числом бит. Приложениями непривилегированного режима могли обращаться только к адресам, которые быть представлены первыми 31 битами 32-разрядного указателя. 1 бит оставался неиспользованным, поэтому некоторые разработчики, будучи продвинутыми кодерами, иногда задействовали этот поначалу бесхозный бит в адресном пространстве процесса, используя его для своих целей (например, помечать с его помощью указатель как ссылку на специальный тип особого для их приложения распределения). Такие приложения принято называть: "Large-Address-Aware". Это породило проблемы, когда был введен ключ /3GB, потому что такие приложения зачастую не способны отличить вполне правильный указатель, который ссылается на память свыше 2 ГБ, от модифицированного указателя, который ссылался на память ниже 2 ГБ. Очень часто, когда система загружается с ключом /3GB, такие приложения перестают нормально работать. Чтобы исправить такую ситуацию, Microsoft добавило поддержку нового флага в поле Characteristics формата файлов Win32 Portable Executable (PE) (формат, который в Windows определяет размещение исполняемых файлов: EXE и DLL), и который указывает, использует ли приложение 32-й бит адресации. Когда этот флаг (IMAGE_FILE_LARGE_ADDRESS_AWARE) включён, 32-й бит в поле Characteristics заголовка исполняемого файла будет установлен. В соответствии с установкой этого флага в заголовке исполняемого файла, приложение указывает Windows, что оно умеет правильно использовать указатели с расширенным числом разрядов и не делает с битами ничего экзотического. Когда этот флаг установлен, и соответствующая версия Windows загружена с ключом /3GB, система в состоянии обеспечить процесс расширенным частным адресным пространством непривилегированного режима. Имеется возможность проверки того, включён ли для программы этот флаг, используя утилиты DumpBin и ImageCfg, которые могут представлять заголовки исполняемых файлов. Visual C++ устанавливает IMAGE_FILE_LARGE_ADDRESS_AWARE с помощью своего переключателя в компоновщике: /LARGEADDRESSAWARE. SQL Server устанавливает этот флаг, если загрузка происходила с ключом /3GB, и на соответствующей версии Windows, что позволяет системе предоставить ему дополнительное адресное пространство для непривилегированного режима.

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

Physical Address Extension

Процессоры Intel, начиная с линейки процессоров Pentium Pro, обеспечивают поддержку расширенной модели управления памятью, называемой Physical Address Extension (PAE). Режим PAE обеспечивает доступ к физической памяти размером до 64 ГБ. В этом режиме, модуль управления памятью (MMU) по-прежнему позволяет работать с записями каталога страниц (page directory entries - PDE) и записями таблицы страниц (page table entries - PTE), но вводит новую, дополнительную сущность: таблицу указателей каталогов страниц (page directory pointer table). Кроме этого, в режиме PAE, PDE и PTE расширяются до 64 бит (в отличие от стандартных 32 бит). Система получает возможность обращаться к большему объёму памяти, чем в стандартной компоновке, потому что PDE и PTE становятся вдвое шире, а не из-за добавления таблицы указателей каталогов страниц. Эта таблица необходима для управления PDE и PTE увеличенного размера и их индексации. Для реализации режима PAE имеется специальная версия ядра Windows. Это ядро есть для всех версий Windows 2000 и последующих версий, и размещается в Ntkrnlpa.exe - для однопроцессорных машин, или в Ntkrnlpamp - для многопроцессорных машин. Включить использование режима PAE можно добавив ключ /PAE в файл BOOT.INI, точно также, как это делалось при добавлении ключа /3GB или /USERVA.

Address Windowing Extensions

Расширение адресного пространства Windows, именуемое: "Address Windowing Extensions" (AWE), используется для того, чтобы предоставить возможность приложениям распределять память за пределами 4 ГБ физической памяти. 32-разрядный указатель, это целое число, которое имеет предельное значение 0xFFFFFFFF, в реальных условиях может использоваться и того меньше, то есть ссылки ограничены линейным пространством до 4 ГБ адресации памяти. AWE позволяет обойти это ограничение и обращаться ко всей памяти, поддерживаемой операционной системой.

Концептуально, AWE не представляет ничто нового в операционной системе, и приложения использовали подобные механизмы обхода ограничений длины указателей ещё на заре компьютерного века. Например, вспомните былые времена 16-битной DOS, когда были распространены 32-разрядные расширители адресного пространства, такие как Phar Lap, Plink, и другие), которые часто использовались для обращения к памяти, находящееся за пределами нормального адресного пространства 16-разрядных приложений. Менеджеры специального назначения и программные интерфейсы расширенной и дополнительной памяти были обычным явлением; Вы можете даже вспомнить такие программы, как Quarterdeck QEMM-386, которая раньше использовалась для подобных целей. Как правило, механизмы, которые позволяют указателю обращаться к памяти, которая находится вне прямой досягаемости (то есть, по адресам, которые слишком большие, и не могут храниться непосредственно в указателе), в большинстве своём создавали окно или область в пределах доступного адресного пространства, которые использовались для трансформации памяти, недоступной в прямой адресации. Точно также работает и AWE, с помощью которого создаётся регион в адресном пространстве процесса, который служит своего рода окном для организации трансляции адресов к памяти, которая была бы недоступна в непривилегированном режиме иным способом.

Чтобы использовать AWE режим, приложение должно:
  1. Распределять физическую память, которая будет задействована, используя функцию Win32 API: AllocateUserPhysicalPages. Эта функция требует, чтобы вызывающая её программа имела разрешение Lock Pages in Memory.

  2. Создать регион в адресном пространстве процесса, который будет служить окном для отображения недоступной физической памяти, используя функцию программного интерфейса VirtualAlloc.

  3. Отображать представление недоступной физической памяти в окне виртуальной памяти, используя функции Win32 API: MapUserPhysicalPagesScatter или MapUserPhysicalPages.

Расширение AWE реализовано для всех изданий Windows 2000 и последующих версий, и может использоваться даже на системах, у которых физической памяти меньше 2 ГБ. Но наиболее распространённым случаем использования этого механизма являются системы, у которых размер физической памяти превышает 2 ГБ, и для которых это является единственным способом предоставления доступа к физической памяти 32-разрядному процессу за пределами 3 ГБ. При включённой в SQL Server поддержке AWE, на системе, у которой физической памяти меньше 3 ГБ, система игнорирует эту опцию и использует вместо этого обычное управление виртуальной памятью. Одной из интересных особенностей доступной через AWE памяти является то, что эта память никогда не сбрасывается на диск. Вы наверное обратили внимание на то, что поддерживающие интерфейсы AWE подпрограммы обращаясь к памяти, работают с ней как с физической памятью. Это и является причиной того, что доступная через AWE память является физической памятью, которая никогда не сбрасывается и никогда не считывается из системного файла подкачки.
Окно виртуальной памяти, как правило, буферизует физическую память, доступную через AWE, для чего необходим доступ на чтение-запись. Следовательно, единственным атрибутом её защиты, который можно передать в VirtualAlloc, является установка для окна PAGE_READWRITE. Не удивительно, что это также означает невозможность использования VirtualProtect для защиты страниц в этом регионе от модификации или от доступа.
Обратите внимание, что ни одни из инструментов, которые обычно используются для мониторинга использования памяти (Диспетчер Задач, Perfmon/Sysmon и т.д.) Не показывают количество памяти, доступной через механизмы AWE, и используемой каким-либо процессом. Кроме того, что нет индикаторов доступной через AWE памяти, используемой каждым процессом, такая память не включается в размер рабочего множества, который подсчитывается для такого процесса.

Сравнение /3GB и AWE

Возможность расширения частного адресного пространства процесса на 50 процентов с помощью настройки памяти конечно же удобна, и вполне применима для расширения возможностей средств управления памятью Windows; однако, возможности режима AWE в Windows являются более гибкими и масштабируемыми. Как я говорил уже ранее, когда Вы увеличиваете частное адресное пространство процесса на один гигабайт, этот гигабайт отнимается у адресного пространства привилегированного режима, которое урезается от 2 ГБ до 1 ГБ. И поскольку выделяемой для привилегированного режима памяти и так уже впритык, даже когда доступны все её 2 ГБ, сокращение её доступного размера означает, что некоторые внутренние структуры ядра вынуждены будут ужиматься. В первую очередь, это специальная таблица в Windows, которая используется для управления физической памятью компьютера. Когда Вы сокращаете раздел привилегированного режима до 1 ГБ, Вы ограничиваете размер этой таблицы так, что с её помощью можно будет управлять только максимум 16 ГБ физической памяти. Например, если Вы имеете дело с Windows 2000 Data Center на компьютере с 64 ГБ физической памяти, и выполняете загрузку операционной системы с ключом /3GB, у Вас будет возможность обращения только к 25 процентам памяти компьютера, а 48 ГБ будут недоступны операционной системе и приложениям. Зато режим AWE позволяет обращаться к гораздо большему объёму памяти, чем ключ /3GB. Очевидно, можно получить только один дополнительный гигабайт частного адресного пространства для процесса, если использовать /3GB. Это дополнительное пространство станет доступно только совместимым и адоптированным Large-Address-Aware приложениям, но оно все-таки ограничено только 1 ГБ. И наоборот, AWE может предоставить доступ ко всей физической памяти, которая доступна операционной системе, она будет доступна приложениям, если приложение было написано с использование функций поддержки AWE в Win32 API. В итоге, режим AWE более трудоёмок в использовании, но намного гибче и более открыт.
Нельзя сказать, что не существует ситуаций, когда /3GB предпочтительнее AWE. Например, если необходимо увеличить пространство для таких распределений памяти, которые не могут постоянно находиться в памяти как это типично для AWE (стеки потоков, память для блокировок, планы процедур), может оказаться, что /3GB лучший выбор.

Участки памяти

SQL Server организует память, которую он распределяет, в виде двух разных участков: BPool (буферный пул) и MemToLeave (оставленная память). Если Вы используете AWE, фактически появляется третий участок, это физическая память свыше 3 ГБ, которая становится доступной у Windows после включения поддержки AWE. BPool самый важный участок из этих трех. Он является первичным пулом распределения для SQL Server, и служит, прежде всего, как кэш страниц данных и индексов, а также используется для распределений памяти меньше 8 КБ. MemToLeave состоит из виртуального пространства, в рамках адресного пространства памяти непривилегированного режима, которое не используется BPool. Доступная посредством AWE функций память, превышающая 3GB, используется в качестве расширения BPool и обеспечивает дополнительное пространство для кэширования страниц данных и индексов.
Когда происходит запуск SQL Server, верхняя граница BPool вычисляется на основании имеющейся у компьютера физической памяти и в зависимости от размера адресного пространства непривилегированного режима. Как только эта граница определена, резервируется участок MemToLeave, из расчёта, чтобы он не был фрагментирован при резервировании BPool, которое после этого следует. При резервировании участка BPool используются 32 цельных раздела, которые задействуются для библиотек DLL и других распределений, именно которые уже могут задействовать виртуальное адресное пространство процесса SQL Server, после того, как BPool будет зарезервирован. Как только BPool зарезервирован, участок MemToLeave тоже становится доступен. Он используется для внутренних распределений SQL Server, которые превышают 8 КБ непрерывного пространства, и для распределений, сделанных внешними потребителями (то есть, потребители памяти не относящимися к движку сервера, но хостящимися в процессе SQL Server), такими, как OLE DB провайдеры, незавершенные COM объекты и т.п..
После запуска SQL Server, BPool будет зарезервирован, но он не будет занят, и участок MemToLeave будет занимать всё свободное пространство в рамках виртуального адресного пространства памяти процесса. Если Вы в это время посмотрите для процесса SQL Server показания счетчика Virtual Bytes в системной утилите Perfmon, Вы увидите, что он отражает резервирование BPool. Я сталкивался с тем, что это вызывало тревогу у специалистов, потому что наблюдаемые значения часто настолько высоки, что они бывают близки к размеру физической памяти компьютера или равны максимальному размеру адресного пространства непривилегированного режима, минус размер участка MemToLeave. Это не повод для волнения, и происходит потому, что отражается только зарезервированное значение, а не уже занятое пространство. Как я уже сказал ранее, зарезервированное место - это только объём адресации, и ещё не имеет физической памяти, пока она не будет занята. Через какое-то время, объем занятой BPool памяти увеличится, пока он не достигает верхней, вычисленной в момент запуска сервера границы.

Контроль использования виртуальной памяти

Вы можете увидеть вычисленный при запуске максимальный размер BPool в Perfmon с помощью счетчика SQL Server:Buffer Manager\Target Pages. Как и другие участки используемой сервером памяти, BPool использует страницы размером 8 КБ, которые он резервировал при запуске, и пока размер занятых страниц не достиг вычисленного при старте значения. Вы можете отследить использование BPool занятой виртуальной памяти с помощью счетчика SQL Server:Buffer Manager\Total Pages, а отследить это же, но для всего сервера, можно с помощью счетчика Private Bytes, для процесса SQL Server.
Поскольку большинство виртуальной памяти SQL Server использует именно для BPool, эти два счетчика, вообще говоря, должны увеличиваться или стабилизироваться синхронно (имейте в виду, что когда включена поддержка AWE, счетчик Private Bytes не будет отражать всю полноту использования памяти для нужд SQL Server). Если счетчик Total Pages стабилизировался, а счетчик Private Bytes продолжает расти, это обычно указывает на длительные распределения в участке MemToLeave. Такие распределения могут быть совершенно нормальным явлением, например, они могут быть распределениями, связанными со стеками потока, когда сервером были созданы дополнительные рабочие потоки, или они могут указать на утечку, связанную с внешним потребителем, например, незавершенным COM объектом или xproc (extended procedure). Если процесс выполняется из виртуального адресного пространства, потому что участок MemToLeave истощен из-за утечки памяти или чрезмерного её потребления (или если максимальный размер свободного блок в участке MemToLeave опускается ниже заданного по умолчанию размера стека потока 0,5 МБ), сервер перестаёт создавать новые рабочие потоки, даже если значение max worker threads, заданное через sp_configure, ещё не было достигнуто. В этой ситуации, если сервер, для исполнения запроса (например, что бы обслужить новое подключение и запрос на регистрацию к серверу), должен создать новый рабочий поток, этот запрос будет отсрочен, пока сервер не сможет создать поток, или пока не станет доступным для этих целей другой исполнитель. Это может препятствовать подключению пользователей к серверу, потому что отведённое на подключение время может закончиться раньше, чем высвободится достаточно места в MemToLeave, или станет доступен другой исполнитель, который сможет обработать запрос на подключение.

Распределение памяти

Потребитель памяти внутри сервера начинает распределение памяти с создания объекта памяти, который необходим для управления запросом. Когда запрашивается распределение объекта, происходит обращение к соответствующему менеджеру памяти сервера, позволяющему выполнить запрос или в BPool или в участке MemToLeave. Если запрашивается меньше 8 КБ, для него обычно задействуется BPool. Для запросов размером от 8 КБ непрерывного пространства задействуется MemToLeave. Поскольку один объект памяти может использоваться для нескольких распределений, может оказаться, что на участке MemToLeave будут распределения, которое размером значительно меньше 8 КБ. Потребители памяти в пространстве процесса SQL Server обычно являются внутренними потребителями или объектами, запрограммированными непосредственно в коде SQL Server, которым нужна память для своих задач, но влияние их не должно быть заметно. Также, это могут быть внешние потребители, о которых я говорил ранее. Обычно, внешние потребители используют память нормальным образом, через функции Win32 API, позволяющие её распределять и управлять ею. Поэтому, они распределяют пространство в участке MemToLeave, поскольку это единственное пространство у процесса SQL Server, которое им кажется доступным. Однако, расширенные процедуры (extended procedure или xprocs) являются в этом случае исключением. Когда xproc вызывает из программного интерфейса Open Data Services функцию srv_alloc, всё будет происходить точно так же, как и для любого другого внутреннего потребителя сервера. Вообще говоря, запросы srv_alloc размером меньше чем 8 КБ будут распределяться из BPool, большие же распределения будут из участка MemToLeave.

Менеджер памяти

Во время работы сервера, менеджер памяти выполняет проверки того, что бы оставался доступным минимально возможный размер физической памяти, при наличии которого Windows и другие приложения сервера работали бы без особых проблем. Этот минимальный размер может варьироваться между 4 МБ и 10 МБ (с тенденцией быть ближе к 10 МБ на Windows Server 2003) и основывается на загрузке системы и сроке годности страниц в BPool. Если доступная физическая память сервера снижается ниже этого порога, сервер отпускает страницы из BPool, чтобы сократить размер его физического хранилища (предполагается, что выбрана динамическая подстройка памяти). Менеджер памяти также отвечает за то, что бы в любой момент времени оставалось свободным заданное число страниц, что бы новые запросы на распределение не ожидали появления свободной памяти. Под "Свободными" я подразумеваю те страницы, которые уже были переданы, но ещё не используются. Неиспользуемые, но переданные в BPool страницы, прослеживаются с помощью списка свободных страниц. Поскольку используемые страницы определяются из этого списка, менеджер памяти передает больше таких страниц, которые резервируются из BPool, пока все резервирования не будут переданы. Из-за этого, в Perfmon Вы можете наблюдать постепенный (и, как правило, линейный) рост значений счетчика Process:Private Bytes.
Есть ещё другие списки свободных страниц, которые наличествуют у каждого присутствующего в системе процессора. Когда по запросу на распределение становится необходима свободная страница, в первую очередь запрашивается список свободных страниц, связанный с потоком текущего процессора, а после этого могут быть задействованы аналогичные списки других процессоров. Такая реализация направлена на повышение масштабируемости, и позволяет лучше использовать локальный кэш каждого процессора в многопроцессорной системе. Контролировать имеющиеся в BPool разделы можно в Perfmon, с помощью объекта SQL Server:Buffer Partition. Также, Вы можете контролировать список свободных страниц для всех разделов, через доступный в Perfmon счетчик SQL Server:Buffer Manager\Free Pages.
На протяжении всей работы сервера, процесс менеджера памяти контролирует состояние памяти системы, на предмет наличия разумного количества свободной физической памяти для других компонент системы, и что бы достаточное число свободных страниц оставалось доступным для использования новыми запросами на распределение памяти. Некоторые аспекты этого при необходимости могут изменятся, например, когда сервером используется доступная через AWE память. Тогда BPool после приобретения физической памяти компьютера начинает её блокировать. Объем памяти, который он блокирует, изменяется на основании того, была ли и как установлена максимальная память для сервера. Если это было сделано, BPool пытается заблокировать столько памяти, сколько указано в параметре максимального значения памяти сервера. Если он не указан, BPool блокирует всю физическую память компьютера, кроме приблизительно 128 МБ, которые он оставляет доступными для других процессов. В этом случае BPool может использовать физическую память свыше 3GB (через AWE), что очень похоже на работу файла подкачки со страницами данных и индексов. По мере необходимости, происходит отображение физических страниц участка на виртуальное адресное пространство, что бы на них можно было ссылаться с помощью 32-разрядных указателей.

Резюме

Понимание того, как приложение распределяет и управляет памятью, является необходимым для того, что бы понимать, как работает само приложение. Память, это очень важный ресурс, и её эффективное использование настолько сильно и многосторонне зависит от дизайна приложения и сервера, что только понимание того, как приложения управляют памятью, даст полное понимание общего дизайна приложения.
Так как же всё это относится к разработчикам? Знание того, как сервер управляет памятью, позволяет учитывать это при разработке приложений, что бы они работали эффективно, а также это знание помогает разрешать связанные с памятью проблемы сервера. Рассмотрим, например, случай, когда в попытке повысить эффективность подключения клиентов, разработчик в параметрах SQL Server увеличивает до 8 КБ заданный по умолчанию размер сетевого пакета. Через какое то время после этого, сервер начинает посылать сообщения в журнал ошибок, указывающие на проблемы резервирования виртуальной памяти на участке MemToLeave. Вам это сразу скажет о том, что сделанное в параметрах изменение с большой степенью вероятности повинно в появившейся проблеме с памятью, поскольку распределения свыше 8 КБ выполняются из участка MemToLeave. Отвечающие за обслуживание подключений к SQL Server буферы будут как раз из этого участка, потому что таким установлен размер сетевого пакета. А учитывая, что значением по умолчанию размера сетевого пакета провайдера SQLClient в .NET Framework's является как раз 8 КБ, описанная ситуация видится не такой уж и гипотетической, как это могло вначале показаться. На практике, не так уж и редко встречаются проблемы, связанные с нехваткой места в MemToLeave, и не редко они спровоцированы именно очень большим размером сетевого пакета.
Точно так же, понимание того, руководствуясь какими правилами SQL Server делит память на регионы и участки, помогает понять будет ли конкурировать ваша выполняющаяся в процессе SQL Server программа или код за критические системные ресурсы, например, за кэш данных. Допустим, Вы создаете расширенную хранимую процедуру, которая для распределения памяти вызывает srv_alloc(). Будем считать, что в тот момент, когда ваш код распределяет буферы, их размер меньше 8 КБ. Из изложенного выше материала статьи, мы уже знаем, что эта расширенная процедура распределит память из BPool, т.е. это так память, которая могла бы гораздо эффективнее быть использованной для нужд кэша.
Кроме всего прочего, понимание того, как SQL Server управляет памятью, также может помочь определиться со стартовым размером системы, вычислить необходимый размер физической памяти, и решить, как распределять и разделять её для SQL Server. Например, имея хорошее понимание сильных и слабых сторон использования AWE или 3GB, Вы можете определить, нуждается ли Ваше приложение в превышающей 3GB физической памяти сервера и выбрать наиболее предпочтительный в данном случае режим подключения расширенной памяти.


Главная > Программы > Microsoft MSSQL