Sql как ограничить память sql

Обновлено: 08.07.2024

Материал посвящен описанию использования подсистемы памяти в MS SQL server. Данный обзор дает только общее представление о структуре управления. Следует помнить, что продукты компании Microsoft поставляются с закрытыми кодами и детальные сведения отсутствуют в общедоступных источниках (насколько удалось выяснить нам, если Вам удалось большее – сообщите, пожалуйста). Общий обзор необходим для понимания описываемых далее возможных проблем SQL server и используемых средств тестирования и измерения производительности.

Memory manager

Memory manager (ММ) является основным элементом, который управляет распределением памяти в SQL сервере. Данный компонент автоматически распределяет доступную SQL серверу память, снижая необходимость ручной настройки. После загрузки SQL ММ определяет первоначальный объем распределенной памяти и далее по мере изменения нагрузки динамически резервирует или освобождает оперативную память. Таким образом, ММ управляет взаимодействием SQL сервера с операционной системы в контексте управления памятью. Memory manager является частью SQLOS. Подробнее можно посмотреть здесь.

Состав Memory Manager

Сведения о составе этого компонента весьма ограничены, однако можно выделить следующие составные части ММ: memory nodes, memory clerks (клерки памяти), memory caches (кэши) и memory objects (объекты). Подробнее можно прочитать здесь и здесь.

Также ММ предоставляет несколько счетчиков, которые позволяют оценить использование оперативной памяти в SQL. Подробнее можно прочитать здесь и здесь.

Обобщенно состав ММ представлен на Рисунке 1.1

Рисунок 1.1 Компоненты Memory Manager

Объекты ММ используются для распределения памяти внутри экземпляра SQL Server. Memory nodes обеспечивают интерфейс к ОС и реализацию выделения памяти на нижнем уровне. Внутри SQL Server только Memory clerks имеют доступ к интерфейсу. Memory nodes для распределения памяти. Каждый компонент SQL Sever, который потребляет существенный объем памяти должен создать собственный клерк и распределять память именно через его интерфейс.

Реализация управлению памятью меняется от версии к версии SQL, однако основные функциональные компоненты сохраняются. На рисунке 2.2 приведены отличия в реализации ММ в SQL2008 и SQL2012 дополнительные сведения можно найти здесь.

Рисунок 1.2 Изменения в структуре Memory Manager для SQL2008 и SQL 2012

Из рисунков видно, что полностью исчезло разделение page allocator. Эти компоненты были заменены одним Any-size page allocator.

Memory Nodes

Memory Nodes является внутренним объектом SQLOS. Представляет собой логический объект памяти, которая соответствует процессору в случае SMP-реализации или группе процессоров в случае NUMA-реализации. Подробнее можно посмотреть здесь.

Рисунок 1.3 Иерархия SQLOS в случае реализации SMP (А — рисунок) и NUMA (Б- рисунок)

Memory node абсолютно прозрачна для потребителей памяти. Главная задача этого компонента состоит в определении области выделения памяти. Memory node состоит из нескольких распределителей памяти (memory allocators). На рисунке 2.4 представлены потребители памяти, использующие memory node. Подробнее можно посмотреть здесь и здесь.

Рисунок 1.4 Memory nodes

Memory allocators являются процедурами, которые определяют тип Windows API используемой для выделения памяти. Аллокаторы содержат программный код используемый для выделения памяти, например, для страниц или использования shared memory.

Memory clerks

Memory nodes обеспечивают интерфейс к ОС и реализацию выделения памяти на уровне Windows. Внутри SQL Server только Memory clerks имеют доступ к интерфейсу Memory nodes для распределения памяти. Каждый компонент SQL Sever, который потребляет существенный объем памяти, должен создать собственный клерк и далее распределять ресурсы именно через его интерфейс.

Таким образом, клерки выполняют следующие функции в рамках Memory manager:
• Отражают использование памяти конкретными компонентами сервера
• Получают уведомления о смене состояний памяти и изменяют её размер согласно обстоятельствам.
• Используют Memory nodes для выделения памяти компонентам сервера.

Выделяют четыре категории клерков. Список категорий приведен в таблице 1. Подробнее можно посмотреть здесь.

Memory Caches

Под понятием «кэш» понимается механизм кэширования различных типов данных с учетом стоимости хранения объектов. Кэш обеспечивает: контроль времени хранения, видимость и анализ статистики обращения к кэшированным данным. Кэшированные данные могут быть использованы одновременно несколькими потребителями. Кроме кэшей SQL Server использует пулы памяти. Пулы в отличии от кэшей используются для хранения однородных данных без дополнительного контроля. Используется несколько механизмов кэширования и них основные:
• Cache Store
• User Store
• Object Store

Только Object Store является пулом, Cache и User Store являются кэшами. Механизмы Cache и User Store весьма похожи, однако если параметры Cache Store контролируются целиком SQLOS, то для User Store разработчики могут использовать собственные алгоритмы управления. В документации также используются понятия Cache Store и User Store со значением “обособленные области памяти”. Каждому Cache Store сопоставлено хранилище hash table. Возможно использование не одной, а нескольких таблиц hash tables. Hash table – это структура в памяти, которая содержит массив указателей на страницы буфера. Хэширование – это методика, которая единообразно отображает значение ключа в соответствующий hash bucket.
Подробнее можно прочитать здесь (про хэш) и здесь и здесь и здесь.

Cache Store используются, например, для хранения кэша планов выполнения, кэша xml, кэша полнотекстового поиска, Procedure Cache, System Rowset Cache. В User Store хранятся в частности кэш метаданных пользовательских и системных баз, токены безопасности, данные схем. Полный список можно найти в динамическом представлении dm_os_memory_cache_counters.

Buffer pool (buffer cache) а также buffer pool extension

Buffer pool (второе название buffer cache) – это область в памяти, которая используется для кэширования страниц, данных таблиц и их индексов, размер страниц 8Кб. Использования Buffer pool уменьшает ввод/вывод в файл базы данных и таким образом увеличивает производительность сервера. При этом Buffer Cach является основным потребителем памяти в SQL Server.

Рисунок 1.5 Компоненты системы управления буфером

В SQL Server 2014 buffer pool может быть расширен в энергонезависимую память, например, на диск SSD. Такое расширение называется Buffer Pool Extension. Подробнее можно прочитать здесь здесь.

Подробнее об управлении буферным кэшем можно прочитать здесь, здесь и здесь.

Буферный кэш имеет собственный клерк памяти и распределят память через page allocator. Для буферного кэша используется клерк памяти типа Generic и называется memoryclerk_sqlbufferpool.

До SQL 2012 Buffer Cache использовал только Single Page Allocator (распределяющий отдельные страницы 8Кб). Если компоненту сервера было необходимо выделить буфер большего, чем 8Кб размера использовался Multi Page Allocator (см. рис. 2.4) и соответственно эта память располагалась за пределами Buffer Pool. C SQL2012 Single и Multi Page allocators были объединены в Any-size page allocator. На рис. 2.2 можно увидеть эти изменения.

Max server memory и min server memory

Хотя управление буферным кэшем происходит автоматически внутри SQL Server, однако администраторы могут регулировать максимальный и минимальный размер распределяемой памяти для этого буфера.

Рисунок 1.6 Изменения в диапазоне памяти резервируемой параметром Max server memory

Как уже упоминалось в SQL 2012 произошли изменения memory manager. В результате таких изменений параметр max server memory регулирует не только память buffer pool, но вообще всё распределение памяти (кроме Direct Memory Allocations производимых с помощью VirtualAlloc).

Параметр min server memory обозначает границу, ниже которой Buffer Pool не будет по требованию освобождать занятую память. При первоначальной загрузке пул не занимает память, указанную в min server memory. Используется минимально необходимый объем, который вычисляется автоматически. Размер пула при необходимости в дальнейшем увеличивается.

Подробнее можно прочитать здесь и здесь.

Stolen pages

Stolen pages — это страницы буферного кэша, которые используются для различных целей в сервере. Например, для процедурного кэша, операций сортировки (т.е. рабочей памяти запроса — workplace memory). Также эти страницы необходимы для хранения таких структур данных, которые требуют распределение памяти менее 8Кб, например, блокировки, контекст транзакций и информации о соединении.

Подробнее можно посмотреть в следующих источниках:

Object Store

Object Store представляет собой пул памяти. Он используется для хранения однородных типов данных без дополнительного контроля стоимости хранения. Эти данные могут быть легко очищены в случае нехватки памяти. По своей структуре пулы являются клерками памяти (т.е. являются одним из его видов). Дополнительно можно посмотреть здесь и здесь.

Memory Objects (MO)

Memory Objects представляют собой кучу памяти, которая использует интерфейс клерков памяти чтобы получить доступ к page allocator для выделения страниц. Memory Objects не используют интерфейсы виртуальной или общей памяти, этот элемент использует только механизм распределения страниц. Многие компоненты SQL Server обращаются напрямую к MO, минуя клерки памяти. МО предоставляют возможность распределить диапазоны памяти произвольного размера.

Memory Broker (МВ)

Memory broker (брокер памяти) является компонентом SQLOS. Брокер памяти отвечает за распределение памяти между различными компонентами SQL Server в соответствии с их запросами. Более подробно можно прочитать на сайте производителя.

Рисунок 1.7 Распределение памяти Memory Broker

Описание механизма: МВ отслеживает запросы памяти от компонентов SQL и сопоставляет с текущими показатели её использования. Основываясь на полученной информации, брокер вычисляет «оптимальный» размер памяти, которая может быть распределена между компонентами. Брокер уведомляет компоненты о своих вычислениях, после этого каждый компонент использует эти сведения для дальнейшего использования памяти.

В данной статье будет рассмотрена закладка «Память» (Memory) окна настройки параметров MS SQL Server 2012 (справедливо и для MS SQL Server 2008 (R2)). На данной закладке можно указать лимиты использования памяти SQL Server 2012, а также задать размер памяти для запроса и для создания индекса.

Запускаем утилиту «SQL Server Management Studio». В Microsoft Windows server 2012 R2 ее можно найти в списке всех программ.

Вводим имя экземпляра сервера, данные для авторизации и нажимаем «Соединить» (Connect).

В окне справа, в обозревателе объектов, кликаем правой кнопкой мыши по верхнему узлу дерева, содержащую строку соединения с сервером, и в контекстном меню выбираем «Свойства» (Properties).

В открывшемся окне «Свойства сервера» (Server Properties) переходим на вкладку «Память» (Memory), на которой доступны для изменения следующие параметры:

Введя необходимые параметры, нажимаем «ОК» для сохранения изменений.

Для того, чтобы просмотреть, вступили ли в силу внесенные изменения, заново откроем окно «Свойства сервера» (Server Properties) на вкладке «Память» (Memory) и установим переключатель, располагающийся внизу формы, в значение «Текущие значения» (Running values).

Если текущие значения остались прежними, значит требуется перезапуск экземпляра SQL server.

Смотрите также:

Может случиться так, что в процессе установки MS SQL Server 2012 были установлены компоненты, необходимость в которых со временем отпала (или были установлены по ошибке). В этом случае, в целях…

В данной статье будут рассмотрены способы лицензирования Microsoft SQL Server 2012. Будет приведен краткий обзор каждого из способов лицензирования, а также указаны возможные варианты лицензирования для различных выпусков MS SQL Server…

Ниже приводится список существующих редакций Microsoft SQL Server 2012, а также приводится краткий обзор каждой из них. Microsoft SQL Server 2012 предлагается в нескольких специально разработанных редакциях:…

Настройка выделения памяти опциями "Maximum server memory" и "Minimum server memory"

Опция Maximum server memory

Принцип расчёта опции Maximum server memory возьмём из статьи Server Memory Server Configuration Options

В общем случае максимальный объём памяти, который можно выдать экземпляру SQL Server рассчитывается так:

Maximum server memory = Всего ОЗУ на сервере - ОЗУ под нужды ОС - ОЗУ под сторонние приложения - ОЗУ SQL Server (накладные расходы экземпляра, выходящие за рамки «Maximum server memory»)

В нашем случае в качестве опорной ОС для SQL Server используется 64-битная Windows Server 2012 R2 Standard с 72GB ОЗУ и 12-core CPU. Проведём расчёт, на базе нашего примера.

Рассчитываем ОЗУ под нужды ОС

У каждой версии ОС есть минимальные требования к ОЗУ, но они более, чем скромные. Есть мнения, что для систем с объёмом ОЗУ более 20GB под ОС нужно резервировать 12.5% общего объёма ОЗУ. На мой субъективный взгляд это избыточный подход, и исходя из имеющейся практики использования Windows Server 2012 R2, полагаю, что для комфортной работы базовой ОС в нашем случае будет более, чем достаточно 4GB ОЗУ.

Рассчитываем ОЗУ под сторонние приложения

Помимо потребностей базовой ОС, на сервере, как правило, имеются приложения инфраструктурной обвязки, такие как всевозможные агенты мониторинга, управления, резервного копирования, антивирусное ПО и т.д. В случае, если сервер 1С:Предприятие планируется установить на одной системе с SQL Server, то нужно учесть величину ОЗУ, необходимую для работы сервера 1С:Предприятия (анализируем суммарное потребление памяти такими процессами, как ragent, rmngr и rphost). В нашем примере 1С на сервере SQL Server нет, а есть только инфраструктурные приложения набора System Center (агенты SCOM/SCCM/SCDPM) и антивирусное ПО. В общей сложности под эти задачи мы зарезервируем 2GB ОЗУ.

Рассчитываем ОЗУ SQL Server

Чтобы рассчитать накладные служебные расходы ОЗУ SQL Server, выходящие за рамки параметра Maximum server memory, воспользуемся формулой из статьи Server Memory Server Configuration Options:

stack size * calculated max worker threads + -g startup parameter (or 256MB by default if -g is not set).

Значение stack size рассчитывается согласно документа Memory Management Architecture Guide. На 64-битной ОС с 64-битной SQL Server stack size равен 2048KB Значение calculated max worker threads рассчитывается согласно документа Configure the max worker threads Server Configuration Option. В этом документе приводится таблица расчётных значений в зависимости от количества процессоров и битности сервера.
В нашем случае используется 64-битный сервер с 12 ядрами, поэтому расчёт будет выполняться по формуле 512 + ((logical CPU’s - 4) * 16) = 640.

Итак, в нашем примере накладные расходы SQL Server составят 2MB * 640 + 256MB = 1536MB = 1,5GB.

Обратите внимание на то, что если на сервере SQL Server планируется использовать более одного экземпляра SQL Server, то расчёт накладных расходов нужно выполнять по аналогии отдельно для каждого экземпляра. Например, в нашем случае планируется использование двух инстансов SQL Server, поэтому значение, которое нужно зарезервировать на накладные расходы SQL Server будет увеличено до 3GB (1,5GB * 2)

Итоговый расчёт Maximum server memory

Согласно нашего примера, итоговый расчёт памяти, который можно указать в качестве Maximum server memory будет выглядеть так:

Всего ОЗУ на сервере (72GB) - ОЗУ под нужды ОС (4GB) - ОЗУ под сторонние приложения (2GB) - ОЗУ накладные расходы SQL Server (3GB) = 63GB.

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

Одному из двух экземпляров SLQ Server, который в нашем случае будет использоваться разными мелкими служебными приложениями, мы разрешим использовать лишь малую часть расчётного максимального значения - 3GB, а экземпляру SQL Server, который будет обслуживать базы 1C:Предприятие мы отдадим оставшиеся 60GB в качестве Maximum server memory.

Опция Minimum server memory

Параметр Minimum server memory определяет нижнюю границу невысвобождаемой экземпляром SQL Server памяти. При запуске экземпляра эта память не занимается сразу, однако добравшись до этой нижней границы, указанный объём памяти закрепляется за работающим экземпляром SQL Server.

Найти каких-то чётких рекомендаций относительно этого показателя для 1С не удалось, поэтому воспользуемся простым примером из документа 1С:ИТС - Настройки Microsoft SQL Server для работы с 1С:Предприятием и установим значение Minimum server memory в виде половины от рассчитанного выше значения Maximum server memory.

Дополнительные источники информации:

Проверено на следующих конфигурациях:

Версия ОС	Версия SQL Server
Microsoft Windows Server 2012 R2 Standard EN (6.3.9600)	Microsoft SQL Server 2016 SP2 CU4 (13.0.5233.0)

Автор первичной редакции:
Алексей Максимов
Время публикации: 13.02.2019 10:57

Есть несколько вариантов ограничения памяти, некоторые настраиваем мы, а не которые устанавливает Microsoft.

Ограничение памяти редакцией SQL Server

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

Имя функции	Enterprise	Business Intelligence	Standard Edition	Express
Максимальный объем используемой памяти	MAX	64 ГБ	64 ГБ	1 ГБ

Как мы видим, для нагруженных решений, редакции Standard будет недостаточно, а Enterprise стоит значительно больше (в среднем в 4 раза больше если сравнивать лицензии на ядра).

Ограничение памяти экземпляру SQL Server

Теперь перейдём к ограничению на которое мы можем повлиять, а именно к параметру экземпляра max server memory. Данный параметр ограничивает память выделяемую для экземпляра, но охватывает не весь её объём. Max server memory ограничивает только баффер пул (далее buffer pool), если не вдаваться в детали, то buffer pool это область памяти SQL Server отвечающая за весь кэш страниц данных и индексов. Остальная часть кэша (процедурный, backup, для поддержки dll и тд) используется вне buffer pool. Память управляется клерками памяти, посмотреть все их виды и используемые ими ресурсы можно тут. Именно по этой причине вы могли видеть что экземпляр часто съедает больше памяти чем мы выставили в max server memory.

Читайте также: