use awe to allocate memory что означает

Does «use AWE to allocate memory» do anything on a SQL Server 2008 R2 64bit Windows 2003 system?

After checking the box I noticed that queries that would timeout after 30 seconds would complete execution.

The TechNet article says «AWE is not required and cannot be configured on 64-bit operating systems.»

So did checking the box do anything?

SQL Server 2008 R2 / Version 10.52.4000.0

1 Answer 1

For 64 bit OS, you dont need AWE and even enabling AWE using sp_configure awe enabled has no meaning.

In 64-bit SQL Server, the SQL Server account still requires the Lock Pages in Memory permission in order to be able to allocate locked pages, via AllocateUserPhysicalPages(), but there are a couple of big differences:

The underlying reliance on AWE-mapped memory is removed. You do not need AWE in 64-bit SQL Server; the awe enabled sp_configure option has no meaning. The continued use of the same AWE API function is purely to ensure that the allocated pages are locked.

Memory allocated via AllocateUserPhysicalPages() can be used for both the data cache and plan cache. In 64-bit SQL Server, the plan cache is no longer allocated separately (it now uses stolen pages from the buffer pool)

The memory allocations for AWE in 32bit use the AllocateUserPhysicalPages() API. The memory allocations for lock pages in 64bit use the same API, but they aren’t using AWE because the VAS in a 64-bit process is 8TB for user mode space and it doesn’t require special mappings through AWE.

Queries timing out has least to do with AWE. There might be missing indexes, outdated stats, poorly configured memory settings and many other stuff that can lead to queries timing out.

Источник

Use awe to allocate memory что означает

Не далее чем вчера один мой коллега попросил помочь с включением режима AWE в MS SQL 2005. Этот режим позволяет SQL Server использовать память выше 4ГБ на 32х разрядных системах. Процедура конфигурации очень проста. Нужно включить привилегию Lock pages in memory для учетной записи пользователя, под которым стартует MS SQL Server. Затем включить режим AWE у сервера и задать параметры потребления памяти. Кроме того система должна быть загружена в PAE режиме. И вот тут возникли вопросы.

На самом деле вопросы возникли не только у моего коллеги. В интернет они тоже частенько возникают, причем с похожими симптомами. Даже на sql.ru очень много вопросов относительно этой конфигурации. Несомненно, этот вопрос уже довольно устарел, но, иногда еще встречается необходимость. Поэтому, давайте вкратце рассмотрим что как и почему.

Прежде всего про PAE. Это специальный режим, в котором механизм трансляции виртуальных адресов в реальные изменяется таким образом, что позволяет 32х разрядной системе использовать больше 4ГБ памяти. Однако, для того, чтобы приложения могли его использовать, они должны использовать специальный API. Те программы, которые не умеют этого – не получат ничего от этого механизма. SQL Server – умеет.

Теперь, собственно, сам вопрос. После применения всех настроек в task manager видно что сервер стал использовать совсем мало памяти. Как проверить, работает ли все это?

Вот собственно и все. Но все же, советую, при больших объемах памяти используйте 64х разрядные версии ПО.

3 комментария:

Вот статья в KB, где описаны странности с памятью http://support.microsoft.com/kb/918483

Конкретнее:
After you assign the Lock pages in memory user right and you restart the SQL Server service, the buffer pool of the SQL Server process still responds to memory resource notification events, and it dynamically increases or decreases in response to these events. However, you cannot see memory allocations for the buffer pool that are locked in memory in the following performance counters:
The Private Bytes counter and the Working Set counter in Performance Monitor
The Mem Usage column on the Processes tab in Task Manager
After these pages are locked, these performance counters represent the memory allocations inside the SQL Server process when those allocations do not use the buffer pool. The Total Server Memory(KB) counter of the SQL Server:Memory Manager performance object accurately represents the memory that is allocated for the buffer pool.

Ну, собственно да. На самом деле это одна из статей. Кроме всего прочего в этой статье описываются проблемы со сбросом рабочего набора в файл подкачки. И в качестве средства борьбы рекомендуют на win2k3 как раз использование AWE и lock pages in memory как раз по причине того что такие страницы не выгружаются в файл подкачки.
В общем, спасибо за полезную ссылку!

Источник

Use awe to allocate memory что означает

Этот форум закрыт. Спасибо за участие!

Лучший отвечающий

Вопрос

Здравствуйте. Знаю что ответов на вопросы много по этой тематике, но мне все равно непонятно кое-что.

Есть сервер с 8ГБ ОЗУ (ранее было 4ГБ, подняли до 8ГБ) и установленной Windows Server 2008 Standard Edition SP2 32bit (не R2).

Было решено попробовать использовать AWE для увелечения ОЗУ под SQL Server.

Действия, которые производил:

1. Настроил запуск служб SQL Server (SQL Server, Agent, FullText Search, Analysis Services) от пользователя с ограниченными правами.

2. В политиках безопасности указал, что этому пользователю можно производить Блокировку страниц в памяти.

3. Включил PAE (BCDEdit /set PAE forceenable).

4. Включил в настройках SQL Server галочку «Использовать AWE для выделения памяти« и установил минимальный размер памяти сервера=2ГБ и максимальный=6ГБ

5. Перезагрузил сервер.

После перезагрузки увидел, что в диспетчере задач процесс sqlservr.exe расходует

60МБ. Решил нагрузить сервер и запустил DBCC CHECKDB.

Запустил утилиту RAMMAP.exe и увидел, что Total показывает 4ГБ (так и должно быть, когда установлено 8ГБ?) и используется AWE всего на

2.3ГБ.

Все ли верно было сделано?

И как мониторить использование AWE? Действительно ли тот процесс его расходует и в том ли объеме, который указали.

Источник

руководство по архитектуре управления памятью

Диспетчер виртуальной памяти Windows

Определенные области адресного пространства сопоставляются с физической памятью диспетчером виртуальной памяти Windows (VMM).

Дополнительные сведения об объеме физической памяти, поддерживаемой различными операционными системами, см. в разделе Предельный объем памяти для выпусков Windows в документации Windows.

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

Архитектура памяти SQL Server

SQL Server по мере необходимости динамически получает и освобождает оперативную память. Обычно администратору не требуется указывать, сколько памяти необходимо выделить для SQL Server, хотя эта возможность по-прежнему существует и в некоторых случаях необходима.

Одна из главных задач проектирования любой программной системы для баз данных — минимизация операций дискового ввода-вывода, так как чтение и запись на диск являются наиболее ресурсоемкими операциями. SQL Server создает в памяти буферный пул для сохранения страниц, считываемых из базы данных. Большой объем кода SQL Server предназначен для минимизации числа физических операций чтения-записи между диском и буферным пулом. SQL Server выполняет балансировку для решения двух задач:

В сильно загруженной системе некоторые масштабные запросы, для выполнения которых требуется большой объем оперативной памяти, не могут получить минимально необходимого им объема и в результате завершаются ошибкой, когда истекает время ожидания ресурса памяти. Для решения этой проблемы следует увеличить значение параметра query wait. При параллельных запросах можно попробовать уменьшить значение параметра max degree of parallelism.

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

Выделение максимального объема памяти для SQL Server

Следующая таблица содержит столбец для 32-разрядных версий, которые более не доступны.

1 32-разрядные версии недоступны, начиная с SQL Server 2014 (12.x).
2 /3gb — это параметр загрузки операционной системы.
3 WOW64 (Windows on Windows 64) — режим, в котором 32-разрядная версия SQL Server запускается в 64-разрядной операционной системе.
4 SQL Server Standard Edition поддерживает до 128 ГБ. SQL Server Enterprise Edition поддерживает максимум, заданный для операционной системы.
5 Обратите внимание, что параметр awe enabled функции sp_configure в 64-разрядной системе SQL Serverприсутствует, но не учитывается.
6 При выдаче разрешения на закрепление страниц в памяти (либо в 32-разрядной системе для поддержки AWE-памяти, либо в 64-разрядной системе) рекомендуем выделить максимальный объем серверной памяти. Дополнительные сведения об LPIM см. в статье Параметры конфигурации памяти сервера.

Более старые версии SQL Server можно запустить в 32-разрядной операционной системе. Чтобы охватить свыше 4 ГБ памяти в 32-разрядной операционной системе, требуется использовать расширения AWE для управления памятью. Это необязательно, если SQL Server выполняется в 64-разрядных операционных системах. Дополнительные сведения о расширениях AWE см. в документации SQL Server 2008: Адресное пространство процесса и Управление памятью для больших баз данных.

Изменения управления памятью, начиная с SQL Server 2012 (11.x)

В более ранних версиях SQL Server (SQL Server 2005 (9.x), SQL Server 2008 и SQL Server 2008 R2) память выделялась с помощью пяти разных механизмов.

Внимательно ознакомьтесь с текущими параметрами конфигурации Макс. памяти сервера (МБ) и Мин. памяти сервера (МБ) после обновления до SQL Server 2012 (11.x) с помощью SQL Server 2019 (15.x). Начиная с SQL Server 2012 (11.x), такие параметры конфигурации теперь включают и учитывают больше видов выделения памяти по сравнению с более ранними версиями. Эти изменения применяются к 32-разрядной и 64-разрядной версиям SQL Server 2012 (11.x) и SQL Server 2014 (12.x), а также 64-разрядным версиям SQL Server 2016 (13.x); через SQL Server 2019 (15.x).

Начиная с SQL Server 2012 (11.x), SQL Server может выделять больше памяти, чем указано в значении «Макс. памяти сервера». Это поведение может возникать, если значение Общая память сервера (КБ) уже достигло параметра Целевая память сервера (КБ) (как указано в параметре «Макс. память сервера»). Если из-за фрагментации памяти недостаточно смежных областей свободной памяти для соответствия требованиям многостраничных запросов памяти (больше 8 КБ), SQL Server может превысить объем вместо отклонения запроса памяти.

Это поведение обычно возникает в следующих операциях.

Изменения memory_to_reserve, начиная с SQL Server 2012 (11.x)

Виртуальное адресное пространство, зарезервированное для этих выделений, определяется параметром конфигурации memory_to_reserve. Значение по умолчанию, которое использует SQL Server, — 256 МБ. Чтобы переопределить значение по умолчанию, используйте параметр запуска SQL Server -g. Сведения о параметре запуска -g см. на странице документации Параметры запуска службы ядра СУБД.

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

В следующей таблице указано, попадает ли конкретный тип выделения памяти в регион memory_to_reserve виртуального адресного пространства для процесса SQL Server.

Динамическое управление памятью

Поведение управления памятью в компоненте Компонент SQL Server Database Engine по умолчанию заключается в использовании памяти по мере необходимости, но в таком объеме, чтобы исключить нехватку памяти в системе. Компонент Компонент SQL Server Database Engine осуществляет это при помощи API уведомления памяти в Microsoft Windows.

Когда SQL Server использует память динамически, он периодически опрашивает систему, чтобы определить объем свободной памяти. Поддержание достаточного объема свободной памяти позволяет избежать подкачки в операционной системе (ОС). Если свободно меньше памяти, SQL Server высвобождает память для ОС. Если свободно больше памяти, SQL Server может выделить дополнительный объем памяти. SQL Server добавляет память, только если она требуется для рабочей нагрузки; во время простоя сервера размер виртуального адресного пространства не увеличивается.

Максимальная память сервера управляет выделением памяти SQL Server, памятью компиляции, всеми кэшами (включая буферный пул), временно предоставляемыми буферами памяти для выполнения запросов, памятью диспетчера блокировки и памятью CLR 1 (фактически любым клерком памяти, находящимся в sys.dm_os_memory_clerks ).

1 Память CLR управляется в рамках выделения по max_server_memory, начиная с SQL Server 2012 (11.x).

Следующий запрос возвращает информацию о текущей выделенной памяти.

1 Сведения о вычисляемых рабочих потоках по умолчанию для указанного числа родственных ЦП на текущем узле см. в разделе Настройка параметра конфигурации сервера «Максимальное число рабочих потоков». Размеры стеков SQL Server имеют следующие значения.

2 Память CLR управляется в рамках выделений max_server_memory, начиная с SQL Server 2012 (11.x).

SQL Server определяет, когда диспетчер памяти SQL Server может выделить и освободить память, с помощью API уведомлений памяти QueryMemoryResourceNotification.

При запуске SQL Server вычисляется размер виртуального адресного пространства для буферного пула на основании числа параметров, таких как объем физической памяти в системе, число потоков сервера и различные параметры запуска. SQL Server резервирует вычисляемый объем виртуального адресного пространства процесса для буферного пула, но занимает (фиксирует) только необходимый объем физической памяти для текущей нагрузки.

После этого экземпляр продолжает занимать память по мере необходимости для поддержания рабочей нагрузки. По мере того как все больше пользователей подключается и выполняет запросы, SQL Server занимает по запросу дополнительную физическую память. Экземпляр SQL Server продолжает занимать физическую память до тех пор, пока заполнение памяти сервера не достигнет максимальных пределов, или до тех пор, пока ОС не сообщит о том, что свободной памяти не осталось. Он освобождает память, если она занята больше, чем указано в параметре min server memory, а ОС сообщает о том, что свободной памяти не хватает.

Параметры настройки min server memory и max server memory

Параметры конфигурации min server memory и max server memory определяют верхний и нижний пределы объема памяти, занятой буферным пулом и другими кэшами Компонент Database Engine. Буферный пул не сразу выделяет объем памяти, определенный минимальным значением. Он начинает расти от объема, необходимого для инициализации. По мере увеличения рабочей нагрузки на компонент Компонент SQL Server Database Engine выделение памяти продолжается. Буферный пул не освободит занятую память, пока не достигнет размера, определенного минимальным значением. Как только это значение будет достигнуто, буферный пул применит стандартный алгоритм выделения и освобождения памяти по мере необходимости. Единственное отличие заключается в том, что буферный пул никогда не освобождает объем памяти ниже предела, определяемого параметром «Минимальная память сервера», — и никогда не занимает объем больше предела, определяемого параметром «Максимальная память сервера».

СамSQL Server как процесс занимает больше памяти, чем указано в параметре max server memory. И внутренние, и внешние компоненты могут занимать память за пределами буферного пула, что также входит в ее общий расход, однако буферный пул все еще составляет наибольшую часть общего объема памяти, потребляемого SQL Server.

Если и для параметра «Мин. памяти сервера», и для параметра «Макс. памяти сервера» указано одно и то же значение, то как только выделенная для Компонент SQL Server Database Engine память достигает этого значения, Компонент SQL Server Database Engine прекращает динамическое выделение и освобождение памяти для буферного пула.

Требования к объему памяти для хранения объектов SQL Server

Следующий список содержит обобщенные сведения об объеме памяти, потребляемой разными объектами SQL Server. Эти значения являются оценочными и могут отличаться в зависимости от среды и способов создания объектов.

Значение network packet size — это размер пакетов потока табличных данных (TDS), которые используются для обмена данными между приложениями и Компонент Database Engine. По умолчанию размер пакета равен 4 КБ, а его настройка осуществляется с помощью параметра конфигурации network packet size.

Если включено использование режима MARS, подключение пользователя занимает примерно (3+3 *число_логических_соединений)* размер_сетевого_пакета + 94 КБ.

Влияние параметра min memory per query

Параметр конфигурации min memory per query определяет минимальный объем памяти (в килобайтах), выделяемый для выполнения запроса. Он также называется минимальным временно предоставляемым буфером памяти. Все запросы должны ожидать выполнения до момента освобождения необходимого объема памяти либо истечения времени ожидания, указанного в параметре конфигурации сервера query wait. Типом ожидания в этом сценарии является RESOURCE_SEMAPHORE.

Не следует задавать слишком большое значение для параметра конфигурации сервера min memory per query, особенно в случае высоконагруженных систем, так как это может иметь следующие последствия:

Рекомендации по использованию этого параметра см. в статье Настройка параметра конфигурации сервера min memory per query.

Рекомендации, касающиеся временно предоставляемого буфера памяти

В построчном режиме выполнения начальный временно предоставляемый буфер памяти не должен превышаться ни при каких условиях. Если для выполнения операций хэширования или сортировки требуется больше памяти, чем имеется в начальном буфере, операции будут переноситься на диск. Переносимая операция хэширования поддерживается рабочим файлом в TempDB, а переносимая операция сортировки поддерживается рабочей таблицей.

Перенос, происходящий во время операции хэширования, называется предупреждением хэширования. Такие предупреждения происходят при возникновении рекурсии во время операции хэширования или при прекращении хеширования (достигнут верхний предел хэширования).

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

Дополнительные сведения о режимах выполнения см. в статье Руководство по архитектуре обработки запросов.

Управление буферами

Главное назначение базы данных SQL Server — хранение и поиск данных, поэтому интенсивное использование операций дискового ввода-вывода — это основное свойство компонента Database Engine. А так как дисковые операции ввода-вывода могут потреблять много ресурсов и требовать относительно длительного времени для выполнения, SQL Server обращает огромное внимание на рациональное использование операций ввода-вывода. Управление буфером — это ключевой компонент в достижении этой рациональности. Компонент управления буферами состоит из двух механизмов: диспетчера буферов для доступа к страницам баз данных и их обновления и буферного кэша (также называемого буферным пулом) для сокращения числа операций ввода-вывода файла базы данных.

Принцип работы управления буфером

Буфер — это страница размером 8 КБ в памяти, того же размера, что и страница данных или индекса. Буферный кэш делится на страницы размером 8 КБ. Диспетчер буферов содержит функции чтения страниц данных или индекса из файлов базы данных на диске в буферный кэш и записывает измененные страницы обратно на диск. Страница остается в буферном кэше, пока диспетчеру буферов требуется область буфера для чтения дополнительных данных. Данные записываются обратно на диск, только если они были изменены. Данные в буферном кэше могут измениться несколько раз, прежде чем будут сохранены обратно на диске. Дополнительные сведения см. в статьях Считывание страниц и Запись страниц.

При запуске SQL Server вычисляется размер виртуального адресного пространства для буферного кэша на основе таких параметров, как объем физической памяти в системе, указанное максимальное число потоков сервера и разных параметров запуска. SQL Server резервирует вычисляемый объем виртуального адресного пространства процесса (называемого целевой памятью) для буферного кэша, но занимает (фиксирует) только необходимый объем физической памяти для текущей нагрузки. Можно запросить столбцы committed_target_kb и committed_kb в представлении каталога sys.dm_os_sys_info, чтобы получить число зарезервированных страниц в качестве указателя памяти и число зафиксированных страниц в буферном кэше соответственно.

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

Поддерживаемые функции

Диспетчер буферов поддерживает следующие возможности:

Диспетчер буферов поддерживает технологию памяти с горячей заменой, которая позволяет пользователям добавлять физическую память, не перезапуская сервер.

Диспетчер буферов поддерживает большие страницы на 64-разрядных платформах. Размер страницы зависит от версии Windows.

До SQL Server 2012 (11.x) включение больших страниц в SQL Server требует флаг трассировки 834.

Диспетчер буферов обеспечивает дополнительную диагностику, выполняемую с помощью динамических административных представлений. Можно использовать эти представления, чтобы контролировать различные ресурсы операционной системы, характерные для SQL Server. Например, можно использовать представление sys.dm_os_buffer_descriptors, чтобы отслеживать страницы в буферном кэше.

Операции дискового ввода-вывода

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

Дисковые операции ввода-вывода, выполняемые диспетчером буферов, имеют следующие характеристики.

Длительные запросы операций ввода-вывода

Диспетчер буферов сообщает о любых запросах операций ввода-вывода, которые не были выполнены в течение 15 секунд. Это помогает системному администратору различать ошибки SQL Server и ошибки подсистемы ввода-вывода. Появляется сообщение об ошибке 833, и в журнал ошибок SQL Server записывается следующее:

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

Длительная операция ввода-вывода может быть чтением или записью; в настоящий момент это не указывается в сообщении. Сообщение о длительной операции ввода-вывода является предупреждением, а не ошибкой. Они указывают не на проблемы с SQL Server, а на проблемы в базовой системе ввода-вывода. Сообщения помогают системному администратору быстрее находить причину длительного времени отклика SQL Server и распознавать ошибки, происходящие вне средств SQL Server. Также они не требуют никакого действия, но системный администратор должен выяснить, почему выполнение запроса ввода-вывода заняло столько времени и оправдано ли это.

Причины длительных запросов операций ввода-вывода

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

Длительные операции ввода-вывода также могут быть вызваны компонентом в пути ввода-вывода (например драйвером, контроллером или встроенным ПО), постоянно откладывающим обслуживание старого запроса ввода-вывода в пользу обслуживания более новых запросов, которые ближе к текущей позиции головки диска. Основная методика обработки запросов, которые наиболее близки к текущей позиции головки для чтения-записи, называется «элеваторный поиск». Это довольно сложно отследить с помощью системного монитора Windows (PERFMON.EXE), так как большинство операций ввода-вывода выполняется быстро. Длительные операции ввода-вывода могут усугубляться рабочими нагрузками, которые выполняют большой объем операций последовательного ввода-вывода, например: создание резервных копий и восстановление, просмотр таблиц, сортировку, создание индексов, массовую загрузку и очистку файлов.

Изолированные длительные операции ввода-вывода, которые не связаны с любой из указанных выше причин, могут быть вызваны ошибками драйвера или оборудования. Журнал системных событий может содержать связанные события, которые помогают выявить ошибку.

Обнаружение нехватки памяти

Нехватка памяти — это состояние, возникающие в результате недостаточного объема памяти. Оно может иметь следующие последствия:

Это состояние может возникать по внешним или внутренним причинам. Возможные внешние причины:

В Компонент SQL Server Database Engine реализован механизм, предназначенный для обнаружения и обработки нехватки памяти в рамках динамического управления памятью. Этот механизм включает в себя фоновую задачу Монитор ресурсов. Задача «Монитор ресурсов» отслеживает состояние внешних и внутренних индикаторов памяти. Как только состояние одного из этих индикаторов меняется, он определяет соответствующее уведомление и рассылает его. Уведомления представляют собой внутренние сообщения от каждого из компонентов ядра и хранятся в кольцевых буферах.

Сведения, относящиеся к динамическому управлению памятью, хранятся в двух кольцевых буферах:

Брокеры памяти отслеживают потребление памяти каждым компонентом и на основе собранной информации вычисляют оптимальный объем памяти для каждого из компонентов. Для каждого пула ресурсов Resource Governor имеется набор брокеров. Затем эти сведения рассылаются каждому компоненту, которые уменьшают или увеличивают потребление памяти по мере необходимости. Дополнительные сведения о брокерах памяти см. в описании представления sys.dm_os_memory_brokers.

Определение ошибки

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

SQL Server повторяет любую операцию считывания, которая закончилась ошибкой контрольной суммы, разрыва страницы или другой ошибкой ввода-вывода, четыре раза. Если считывание закончится успешно в любой из попыток, то в журнал ошибок будет записано сообщение и команда, вызвавшая считывание, продолжится. Если все повторные попытки закончатся ошибкой, команда закончит работу с сообщением об ошибке 824.

Вид используемой защиты страницы является атрибутом базы данных, содержащей страницу. Защита контрольной суммой задана по умолчанию для баз данных, созданных в SQL Server 2005 (9.x) и более поздних версиях. Механизм защиты страницы указывается во время создания базы данных и может быть изменен с помощью инструкции ALTER DATABASE SET. Установку защиты текущей страницы можно определить, создав запрос значения столбца page_verify_option в представлении каталога sys.databases или свойства IsTornPageDetectionEnabled функции DATABASEPROPERTYEX.

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

Защита от разрыва страницы

Защита от разрыва страницы, включенная в SQL Server 2000, является прежде всего способом обнаружения поврежденных страниц из-за сбоев питания. Например, неожиданный сбой питания может оставить только часть страницы, записанной на диск. Если используется защита от разрывов страниц, для каждого 512-байтового сектора из 8-килобайтовой (КБ) страницы базы данных в заголовке страницы устанавливается особый двухбитный шаблон подписи при записи страницы на диск. При чтении страницы с диска биты разрыва, хранимые в заголовке страницы, сравниваются с действительными сведениями о секторах страницы. В шаблоне подписи после каждой записи чередуются двоичные числа от 01 до 10, поэтому всегда можно определить, что на диск была записана лишь часть секторов. Если при последующем считывании выясняется, что состояние бита неправильное, это означает, что страница записана некорректно и обнаружено ее повреждение. Защита от разрыва страницы использует минимальные ресурсы, однако она не обнаруживает все ошибки, вызванные аппаратными сбоями диска. Дополнительные сведения о настройке обнаружения разрывов страниц см. в разделе Параметры ALTER DATABASE SET (Transact-SQL).

Защита контрольной суммой

Защита контрольной суммой, включенная в SQL Server 2005 (9.x), обеспечивает более надежную проверку целостности данных. Контрольная сумма рассчитывается для данных каждой записанной страницы и сохраняется в колонтитуле. Всякий раз, когда страница с сохраненной контрольной суммой читается с диска, компонент Database Engine повторно вычисляет контрольную сумму для данных страницы и вызывает ошибку 824, если новая контрольная сумма отличается от сохраненной. Защита контрольной суммой может перехватить больше ошибок, чем защита от разрыва страницы, потому что она учитывает каждый байт страницы, однако она более ресурсоемкая. Когда защита контрольной суммой активирована, ошибки, вызванные сбоями питания и поврежденным оборудованием или встроенным ПО, могут быть обнаружены во время чтения страницы с диска диспетчером буферов. Дополнительные сведения о задании контрольной суммы см. в разделе Параметры ALTER DATABASE SET (Transact-SQL).

При обновлении пользовательской или системной базы данных до версии SQL Server 2005 (9.x) или более поздней значение PAGE_VERIFY (NONE или TORN_PAGE_DETECTION) сохраняется. Настоятельно рекомендуется использовать CHECKSUM. Значение TORN_PAGE_DETECTION использует меньше ресурсов, но обеспечивает минимальный вариант защиты CHECKSUM.

Основные сведения о неоднородном доступе к памяти

SQL Server совместим с архитектурой неоднородного доступа к памяти (NUMA) и хорошо работает на оборудовании NUMA без дополнительной настройки. С ростом тактовой частоты и количества процессоров становится труднее сократить время задержки памяти, необходимой для использования дополнительной производительности системы. Для устранения этого недостатка поставщики оборудования применяют большие кэши третьего уровня, но это является всего лишь полумерой. Архитектура NUMA обеспечивает масштабируемое решение для этой проблемы. SQL Server позволяет использовать преимущество компьютеров на основе NUMA без необходимости изменять что-либо в приложении. Дополнительные сведения см. в разделе Как настроить SQL Server для использования программной архитектуры NUMA.

Динамическое секционирование объектов памяти

Распределители кучи, называемые объектами памяти в SQL Server, позволяют Компонент Database Engine выделять память из кучи. Их можно отслеживать с помощью динамического административного представления sys.dm_os_memory_objects. CMemThread — это потокобезопасный тип объекта памяти, позволяющий выделять память параллельно из нескольких потоков. Для правильного отслеживания объекты CMemThread пользуются конструкциями синхронизации (мьютекс), чтобы обеспечить обновление критически важных элементов информации одновременно только в одном потоке.

Тип объекта CMemThread используется в базе кода Компонент Database Engine для множества различных распределений и может быть секционирован глобально, по узлам или по ЦП.

Однако использование мьютексов может привести к состязанию, если из одного объекта памяти выделяется много потоков в режиме высокой конкуренции. Таким образом, SQL Server имеет концепцию секционированных объектов памяти (PMO) и каждая секция представлена одним объектом CMemThread. Секционирование объекта памяти статически определено и не может быть изменено после создания. Так как шаблоны выделения памяти могут сильно различаться в зависимости от таких факторов, как использование оборудования и памяти, невозможно заранее подготовить идеальный шаблон секционирования. В подавляющем большинстве случаев достаточно использовать одну секцию, но в некоторых сценариях это может привести к состязанию, которое можно предотвратить только с помощью объекта памяти с высоким уровнем секционирования. Не рекомендуется секционировать каждый объект памяти, так как большее количество секций может негативно сказаться на эффективности и вызвать фрагментацию памяти.

Прежде чем SQL Server 2016 (13.x);, можно использовать флаг трассировки 8048, чтобы превратить PMO на основе узла в PMO на основе ЦП. Начиная с SQL Server 2014 (12.x) с пакетом обновления 2 (SP2) и SQL Server 2016 (13.x);, эта реакция является динамической и управляется подсистемой.

Источник