Использовать awe для выделения памяти sql 2008 что это
Обновлено: 07.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 и сопоставляет с текущими показатели её использования. Основываясь на полученной информации, брокер вычисляет «оптимальный» размер памяти, которая может быть распределена между компонентами. Брокер уведомляет компоненты о своих вычислениях, после этого каждый компонент использует эти сведения для дальнейшего использования памяти.
Можно и нужно ли в SQL Server 2008 R2 использовать расширение AWE?
Т.е. делать:
[1c]
sp_configure 'show advanced options', 1
RECONFIGURE
GO
sp_configure 'awe enabled', 1
RECONFIGURE
GO
sp_configure 'min server memory', 4000
RECONFIGURE
GO
sp_configure 'max server memory', 12000
RECONFIGURE
GO
единственое ограничение это то что память выделеная не возвращается до перезапуска службы (1)Отлично, т.к. до этого работал с 2000, а по 2008 четкого ответа так и не нашел. В 2000 память, вообще, не возвращается, т.к. есть только верхний параметр ограничения. Прочитал, что "Для 64-разрядных приложений расширения AWE не нужны, так как в них доступ к памяти не ограничивается объемом 4 ГБ." У меня винсервер 2008 64битный, но сервер 1С8 32х битный. Так надо или не надо мне включать этот параметр? AWE не использует файл подкачки, по этому если памяти на сервере хватает - лучше использовать
(5) а при том, что без AWE SQL берет просто общую память и винда может ее кидать в файл подкачки.
Именно по этой причине AWE и является невозвращаемой
я понял. просто был поменян субъект с объектом. Нужно видимо понимать так, что память отведенная под АВЕ не будет выгружаться в файл подкачки. А без использования AWE, при стандартных настройках, SQL 2008 64bit будет использовать до 10 Гб памяти? 2(8) вот тебе шпаргалка:http://gilev.blogspot.com/2010/06/limits-of-virtual-memory-in-windows.html
"x64: 8 ТБ, если приложение компилируется с параметром IMAGE_FILE_LARGE_ADDRESS_AWARE" (8) при стандартных настройках SQL работает нормально только при правильной оптимизации OS,
например если поставишь терминал или файл сервер - то хорошего не выйдет (11)Читал. Но все же, не смотря на 64битный скуль, советуют ограничивать. (8) при настройках по умолчанию, сожрет все что есть, если база конечно не меньше объема озу (14) Тогда прийдется ограничивать, т.к. там еще сервер 1С будет болтаться (3) для 32битного сервера 1с /3GB юзай. AWE не поможеть - ибо 1с не умеет. а 64битный скуль и так все может без костылей. (16) Т.е. для конфигурации Windoes Server 2008 64bit, SQL Server 2008 R2 64bit и 1С сервер 32 bit нужно включать /3GB ? кстати на 32битной с этой опцией - больше 3-х, так что смысл в 64битной оси с 32битным сервером 1с все таки есть 2(17) быть бы уверенным, что 32-битный сервер 1С компилируется с этим ключем. в каждой сборке. Насчет ненужности AWE для 64-битных приложений - вы расскажите авторам сильнейших шахматных программ, которые заявляют 15% прибавки скорости при использовании LP. (0) Нет. Поставь ограничение использования памяти как общий объем оперативы минус 1 гиг. (28)Скажу по-другому -
если я в выделении памяти укажу параметры MEM_PHYSICAL и MEM_RESERVE, то 64 битное приложение станет работать быстрее. Или ты и с этим будешь спорить? (29) это кусок AWE, да. быстрее - потому что не свопится никогда. а вот MEM_LARGE_PAGES - это LP - оно и не свопится, да еще и в памяти непрерывно - будет еще больший прирост.
ммм. Давайте окончательно.
Для конфигурации Windoes Server 2008 64bit, SQL Server 2008 R2 64bit и 1С сервер 32 bit, 16Гб оперативы нужно, по пунктам (необходимость AWE, /3Gb, какие параметры использовать для ограничения)
(31) врубить 3GB,ограничить SQL память так, что бы серверу 1С хватало для жизни
примерно 2 гига система, 5-6 сервер 1с, минимум 12 SQL и того 20 а еще при файловых операциях (бекап и т.д.) память жрется как минимум еще + 2..3 гига.
из личного опыта нужно > 32, из которых примерно 15-20 выделяешь SQL. и мониторишь, что-бы пара гигов при обычной работе была свободна
(32) Ограничить память не включая AWE (как я понял, в 2008 это можно)? (35) а с чего вдруг нельзя? это всегда было отдельной настройкой Система около гига, сервер 1С до 1.5 гига, бэкап онлайн не делаю 2(34)Если больше 32 Гиг, то это нужно не Стандарт например, а Энтерпрайз, Датацентр или Итаниум-Бэйсед.. а это уже другие деньги. и мы не знаем о каких объемах, скольких базах и скольких пользователях идет речь.(37)>>>сервер 1С до 1.5 гига
не смеши, наверно только сервер и посчитал, каждый р-хост до 2х гигов может вырасти, а сколько их у тебя?
в данном вопросе нужно иметь запас памяти, если память кончится и уйбет в подкачку, словишь такой висяк что мама не горюй.
(42) на 50 пользователей рхостов как минимум 5 надо, а это уже сервер 1с до 10гигов может поиметь Для 64 ИТС рекомендует использовать один процесс. Максимум еще один резервный.Поставлю 3 процесса, ограничу до 10Гб скуль.
(33) Ему это кому?
Если нет свободной памяти при выделении - память просто не будет выделена. Нормальные приложения при этом используют стандартные механизмы выделения памяти.
LP и AWE - практически одно и тоже, с той разницей что LP проблемней, ну и соотвественно быстрее (не в работе, а в выделении памяти)
То есть AWE - это не только выделение верхней памяти 32-битным процессам.
"Устранение неполадок SQL Server" чтение заметок - управление памятью
Самонастраивающееся ядро СУБД (самонастраивающееся ядро СУБД)
В течение долгого времени Microsoft была привержена самонастраивающейся (самонастраивающейся) базе данных SQL Server для снижения общей стоимости владения продуктом. Начиная с SQL Server 2005, SQL Server управляет использованием памяти динамически, и при настройке использования памяти нет необходимости перезапускать ядро базы данных.
Таким образом, он не предоставляет элементов точной настройки для распределения памяти. Выделение памяти для каждого компонента полностью автоматически управляется ядром базы данных и не может быть выделено вручную. Но этот продукт по-прежнему предоставляет некоторые элементы конфигурации, которые могут повлиять на то, как ядро базы данных использует память.
Использование этих элементов конфигурации для замены значений по умолчанию зависит от версии операционной системы, версии SQL Server, доступной физической памяти и архитектуры процессора.
Как SQL Server выделяет память
Сам SQL Server предназначен для использования максимально возможного объема памяти. В нормальных условиях он не освобождает выделенную память, если ОС не запускает и не устанавливает флаг уведомления о нехватке памяти (флаг уведомления о ресурсах).
SQL Server 2005 SQLOS добавила специальный поток для мониторинга уведомлений о памяти (Memory Notification), выдаваемых ОС (это также одна из функций самонастройки).
В ОС есть два типа уведомлений о памяти:
Объем памяти: SQL Server может увеличить использование рабочего набора и использовать больше памяти
Мало памяти: ОС испытывает нехватку памяти, SQL Server высвобождает часть памяти ОС
Если оба типа ОС уведомлений о памяти не установлены, это означает, что использование памяти стабильно и SQL Server продолжит работу в существующем пространстве процесса. Но эта функция не была доступна до Windows 2003 и SQL Server 2005.
Классификация давления памяти в соответствии с Memory Pressure - Classified :
Сколько памяти может использовать SQL Server, зависит от:
- Количество установленной на сервере памяти
- Ограничение памяти системы Windows
- Архитектура SQL Server (32 бит / 64 бит)
- Элементы конфигурации управления использованием памяти SQL Server
- Версия SQL Server
Ограничения 32-битного VAS
Windows запускает все процессы в VAS. 32-разрядный процесс может адресовать только до 4 ГБ памяти, и эти 4 ГБ памяти разделены на пространство режима ядра (режим ядра) и пространство пользовательского режима (режим пользователя). По умолчанию для каждого окна выделяется 2 ГБ.
Режим ядра в основном используется для ОС, а пользовательский режим используется для текущего выполняемого процесса приложения (например, SQL Server).
1. Выделение VAS в пользовательском режиме и VirtualAlloc
VAS пользовательского режима объемом 2 ГБ, зарезервированный SQL Server, будет отправлен только при выделении физической памяти. Это через Windows API VirtualAlloc.
Для 32-разрядного SQL Server или Windows вызов VirtualAlloc возвращает 32-разрядный указатель, поэтому SQL Server может использовать только 2 ГБ VAS пользовательского режима.
Память, выделенная через VirtualAlloc, не обязательно является реальной физической памятью. Когда выделенная память фиксируется, это будет память RAM. При отправке памяти окна должны подтвердить, что общий объем памяти, предоставленный SQL Server и другими прикладными процессами, <= (RAM + файл подкачки).
Следует отметить, что память, выделенная VirtualAlloc, является выгружаемой памятью, а это означает, что когда ОС испытывает нехватку памяти, они будут выгружены на диск.
2. Распределение небуферного пула (MemToLeave)
Большая часть памяти, занимаемой SQL Server, выделяется пулу буферов для кэширования данных и планов запросов. Когда требуются непрерывные страницы размером более 8 КБ, небуферные пулы выделяются через многостраничные распределители, такие как LinkedServer, стек потоков, CLR, резервный кеш и т. Д.
Чтобы обеспечить достаточный объем памяти, не являющейся буферным пулом, 32-разрядный SQL Server при запуске резервирует часть VAS. Зарезервированная часть также называется MemToLeave, size = MaxWorkerThread * 0,5 МБ + 256, где MaxWorkerThread = (ProcessorCount-4) +256.
По умолчанию MemToLeave = 256 * 0,5 + 256 = 384 МБ, поэтому размер области кеша составляет примерно (2–384 МБ) = 1664 МБ.
3. Настройка VAS (Настройка VAS)
На сервере с 4 ГБ памяти можно использовать настройку VAS, чтобы VAS пользовательского режима занимал 3 ГБ, а VAS режима ядра можно уменьшить до 1 ГБ.
Следует отметить, что уменьшение объема памяти в режиме ядра уменьшает системные PTE (Page Table Entires), вызывая нестабильность системы, и в то же время уменьшается объем памяти, к которой может обращаться SQL Server.
Чтобы реализовать настройку VAS в Windows 2008, используйте BCDEdit / set IncreaseUserVa [значение] (значение между 2048 и 3072).
4. AWE(Address windowing extension)
На серверах с оперативной памятью более 4 ГБ вы можете использовать AWE, чтобы позволить SQL Server использовать память. Чтобы использовать AWE, вам необходимо сначала включить PAE и использовать BCDEdit / set PAE ForceEnable, чтобы включить его в Windows 2008.
Затем SQL Server включает «AWE Enabled», и учетная запись службы должна иметь разрешение на блокировку страниц памяти («Блокировать страницы в памяти», назначьте этому пользователю разрешение в групповой политике).
AWE расширяет указатель управления памятью с 32 до 36 бит, поэтому он может адресовать 64 ГБ памяти. А при выделении памяти используйте функцию AllocateUserPhysicalPages вместо VirtualAlloc. Этот API напрямую выделяет физическую память через PTE.
Память AWE может использоваться только пулом буферов, и она заблокирована и не выгружается на страницы, поэтому лучше всего установить «max server memory», чтобы ограничить объем.
5. -g параметры запуска
На 32-битных платформах вы можете использовать параметр запуска SQL Server -g, чтобы указать объем памяти MemToLeave, тем самым увеличивая объем памяти, выделяемой MemToLeave. Но в то же время это также уменьшит выделение буферного пула.
Используйте 64-битный SQL Server
Теоретический верхний предел VAS на 64-битной платформе может достигать 16EB = 16000000 ТБ. Фактически, X64 ограничен 8 ТБ, а IA64 - 7 ТБ. При использовании более 4 ГБ ОЗУ SQL Server не требует дополнительной настройки.
Память, используемая SQL Server, может быть отправлена только через VAS, поэтому вся память не блокируется и выгружается на страницы. Таким образом, когда ОС испытывает нехватку памяти, память может быть выгружена на диск (жесткая страница).
При таком достаточном количестве VAS теория распределения MemToLeave больше не применима, и параметр запуска -g также не имеет смысла.
Кэш процедур (кэш процедур) также будет хранить больше, что может вызвать проблему чрезмерного кеширования процедур.
Параметры конфигурации 64-разрядной памяти SQL Server
1. Минимальная / большая память сервера
SQL Server предоставляет два фактических уровня элементов конфигурации, которые ограничивают размер пула буферов: минимальная память сервера / максимальная память сервера. Следует отметить, что с SQL Server 2000 до 2008 R2 эти две конфигурации предназначены только для пула буферов. .
Когда включена функция «блокировать страницы памяти», разница между ними означает: диапазон, который SQL Server может регулировать при нехватке внешней памяти.
При установке максимального значения универсального значения нет. Основной принцип начальной конфигурации: когда память сервера <= 16 ГБ, ОС резервирует 1 ГБ, а каждые 4 ГБ ОЗУ резервируют 1 ГБ; когда> = 16 ГБ, ОС резервирует 1 ГБ, а каждые 8 ГБ ОЗУ резервируют 1 ГБ.
Например: сервер 32 ГБ, максимальное значение = 32-1-4 = 27 ГБ. Затем убедитесь, что значение счетчика производительности Memory \ Available Mbytes находится в диапазоне от 150 до 300, и постепенно настройте максимальный объем памяти сервера.
2. Заблокируйте страницы в памяти.
64-разрядная SQLOS использует VirtualAlloc для выделения всей памяти по умолчанию.Память, выделяемая этим API, не блокируется и может быть выгружена на страницы. Отметьте MemoryLow, когда ОС испытывает нехватку памяти, SQL Server освобождает память до «минимального объема памяти сервера».
Если его скорость выпуска недостаточно высока или выпущенный объем не удовлетворяет ОС, память будет выгружена в файл подкачки. Для SQL Server, который использует большую память, разбиение по страницам WorkingSet очень серьезно влияет на производительность.
Включите блокировку страниц памяти, чтобы SQL Server использовал AWE API AllocateUserPhysicalPages при выделении памяти буферного пула. Память, выделяемая этой функцией, заблокирована и не выгружается на страницы.
Пул буферов занимает большую часть памяти SQL Server, поэтому включение заблокированных страниц памяти в значительной степени позволит избежать разбиения по страницам WorkingSet. Элемент конфигурации AWE Enabled является недопустимой нулевой операцией в 64-разрядном SQL Server.
После включения страницы блокировки памяти SQLServr.exe диспетчера задач отображает использование памяти небуферного пула. Вам необходимо использовать SQL Server: Memory Manager \ Total Server Memory, чтобы просмотреть общее использование памяти.
Включение заблокированных страниц памяти - это функция SQL Server 2005/2008/2008 R2 Enterprise Edition и 2008 R2 Standard Edition. После обновления 2008 SP1_CU2 и 2005 SP3_CU4 другие версии также могут включать заблокированные страницы памяти, установив флаг трассировки 845.
3. LPA(Large Page Alloction)
В системе X64 выделение больших страниц означает выделение страниц памяти размером 2 МБ, а страница памяти по умолчанию составляет 4 КБ. Включение LPA должно соответствовать условиям: a). SQL Server Enterprise Edition b). ОЗУ сервера> = 8 ГБ c). Включить заблокированные страницы памяти.
В системе X64 с включенным LPS (поддержка больших страниц) и флагом трассировки 834 SQL Server будет использовать большие страницы для выделения памяти буферного пула, и время запуска SQL Server значительно увеличилось.
Строго проверьте преимущества производительности и попробуйте включить ее на выделенном сервере SQL Server.
Диагностировать давление памяти
Используйте счетчики производительности и DMV, чтобы определить, испытывает ли система нехватку памяти. Следует помнить об одном: невозможно определить какое-либо давление в системе с помощью одного или двух счетчиков производительности, поэтому требуется всесторонний анализ.
SQL Server: счетчики производительности в диспетчере буферов:
1. Buffer Cache Hit Ratio
Рекомендуемое значение: OLTP> = 95%, OLAP> = 90. Этот счетчик сам по себе не указывает на то, что SQL Server испытывает нехватку памяти, а> = 95% указывает только на то, что SQL Server выполнил предварительное чтение и предварительную выборку страниц данных, как было задумано. .
2. Page Life Expectancy
В секундах он представляет время, когда срок действия кэшированной страницы истекает и занимаемое ею пространство используется повторно.
Количество свободных страниц в буферном пуле SQL Server. Когда счетчик ожидаемой продолжительности жизни страницы продолжает уменьшаться, количество свободных страниц близко к 0, а количество свободных страниц в списке остается равным 0, это указывает на значительную нехватку памяти.
4. Free List Stalls/Sec
Количество запросов в секунду для ожидания свободной страницы в буферном пуле.
5. Lazy Writes/sec
Число страниц данных пула буферов, обновляемых процессом LazyWriter за секунду. Когда происходит отложенная запись в секунду, уровень PLE и свободных страниц остается низким, и снова возникает задержка свободного списка, что указывает на нехватку ОЗУ.
SQL Server: счетчики производительности в диспетчере памяти:
1. Общая память сервера (КБ) и память целевого сервера (КБ)
Первый указывает объем памяти, который SQL Server уже занимает, а второй указывает объем памяти, который SQL Server хочет занять. Когда последнее больше, чем первое, это доказывает, что SQL Server требуется больше доступной памяти, что также является одним из признаков нехватки памяти.
2. Memory Grants Outstanding
Общее количество процессов, которые успешно получили память рабочей области. Слишком низкое значение указывает на большую активность пользователя или большую нагрузку.Если значение параметра Memory Grants Pending одновременно слишком велико, это также является одним из признаков нехватки памяти.
3. Memory Grants Pending
Общее количество процессов, ожидающих предоставления памяти рабочей области.
DMV, связанные с памятью
Общие проблемы, связанные с памятью
1. Непонимание утечки памяти SQL Server
Похоже, что SQL Server съест столько памяти, сколько возможно. Это не утечка памяти. Утечка памяти расширенной хранимой процедуры или драйвера сервера ссылок может привести к тому, что SQL Server получит память без ограничений.
2. Проблема с пейджингом
После SQL Server 2005 SP2, когда WiringSet процесса SQL Server сокращается и выгружается на диск, в журнале ошибок будет записано, что «значительная часть памяти процесса SQL Server выгружена».
1. Неправильно установлен максимальный объем памяти сервера, заблокированные страницы памяти не включены.
2. Операция ввода-вывода без буферизации, выполняемая Windows, занимает много кэша настройки системы, например копирование файлов.
3. Чрезмерное использование памяти или утечка памяти из-за проблем с драйверами оборудования.
СсылкаKB918483И найдите первопричину процесса усадки рабочего набора и устраните ее. Для SQL Server включение заблокированных страниц памяти - единственный способ решить эту проблему после выборки.
3. Блокировка страниц памяти включена, но максимальный объем памяти сервера не ограничен, что вызывает нестабильность ОС.
Если блокировка страниц памяти включена, но максимальный объем памяти сервера не ограничен или максимальный объем памяти сервера установлен слишком большим, SQL Server израсходует доступную память, в результате чего ОС будет не хватать памяти и работать нестабильно или даже аварийно.
Когда заблокированные страницы памяти включены, максимальный объем памяти сервера должен быть ограничен, оставляя подходящий объем памяти для использования ОС.
4. Домен приложения отмечен как выгруженный, что вызывает нехватку памяти.(App Domain is marked for unload due to memory pressure)
Это ошибка, связанная с SQLCLR, которая обычно возникает на 32-битном SQL Server или может возникать на 64-битном SQL Server, где установлен максимальный объем памяти сервера, который ограничивает доступный VAS SQLCLR.
Как правило, это вызвано неэффективным использованием памяти сборкой SQLCLR и ограниченным VAS, доступным для SQLCLR.
Эта ошибка возникает в 32-битной версии, рекомендуется обновить ее до 64-битной версии, чтобы использовать больше VAS в пользовательском режиме. Однако, если сборка SQLCLR использует большие объекты памяти (например, DataSet), обновление может не решить проблему.
Превратите код SQLCLR в независимую консоль или программу WinForm и правильно настройте использование памяти.
Если SQLCLR сохраняет состояние всего выполнения, но безопасность доступа кода определяется как UNSAFE, при удалении информация о состоянии будет потеряна и возникнут более серьезные проблемы.
Лучшее решение этой проблемы - перейти на 64-разрядную версию.Временное решение - использовать параметр запуска -g для увеличения памяти MemToLeave для SQLCLR.
5. Ошибка 701 и FAILED_VIRTUAL_RESERVE
Когда SQL Server не может выделить непрерывную область VAS, он сообщит об этой ошибке и выведет запрошенный размер выделения.
Обычно эта ошибка возникает только в 32-битных системах с ограниченным MemToLeave, потому что различные типы операций, которым необходимо выделить более 8 КБ, такие как установка избыточного кэша резервных копий, XML, SQLCLR, типов пространственных данных и связанных серверов и т. Д.
Лучшее решение этой проблемы - перейти на 64-разрядную версию. Временное решение - использовать параметр запуска -g для увеличения объема памяти MemToLeave.
6. Виртуальная машина с превышением доступности
В настоящее время виртуализация SQL Server очень распространена. Расширенная функция «Memory Overcommit», предоставляемая виртуальным менеджером, позволяет общему объему памяти виртуальной машины превышать фактический общий объем ОЗУ хост-сервера.
Когда память перегружена, диспетчер виртуализации справляется с нехваткой памяти двумя способами: выделением памяти и подкачкой памяти.
Освобождение памяти - это процесс, выполняемый на гостевой виртуальной машине. Это один из инструментов виртуальной машины, который устанавливается в каждую гостевую виртуальную машину путем выпуска драйвера (Ballooning Driver). Он может получить память от Гостя и вернуть ее хосту.
Когда хост испытывает нехватку памяти (когда память перегружена), память будет уведомлена об освобождении и возврате памяти. Если объем возвращенной памяти или скорость возврата недостаточны для хоста для решения проблемы нехватки памяти, хост будет напрямую выгружать память гостевой виртуальной машины на диск.
Производительность выгружаемого гостя снизится, и SQL Server, работающий на нем, также будет затронут, и даже память буферного пула упадет до 0.
Менеджеры виртуализации, поддерживаемые Microsoft, теперь предоставляют методы для установки минимального объема зарезервированной памяти гостевой виртуальной машины, чтобы обеспечить нормальную работу SQL Server, описанного выше, поэтому его следует устанавливать разумно во время виртуализации.
В то же время установка минимального объема памяти сервера для каждого SQL Server также может избежать этой проблемы с помощью определенных процедур.
7. Настройки многоэкземплярной памяти
Для нескольких экземпляров на машине каждый должен быть настроен с соответствующими минимальным и максимальным объемом памяти сервера, а сумма максимальной памяти сервера должна быть меньше, чем физическая оперативная память, чтобы зарезервировать достаточно памяти для ОС.
Если минимальный объем памяти сервера не установлен, когда ОС или другие экземпляры испытывают нехватку памяти, этот экземпляр будет активно сжимать память и вызывать проблемы с производительностью.
подводить итоги
Самое главное: по какой причине вы сегодня не пользуетесь 64-битной системой! ?
Материал посвящен описанию использования подсистемы памяти в 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 и сопоставляет с текущими показатели её использования. Основываясь на полученной информации, брокер вычисляет «оптимальный» размер памяти, которая может быть распределена между компонентами. Брокер уведомляет компоненты о своих вычислениях, после этого каждый компонент использует эти сведения для дальнейшего использования памяти.
Использование физической памяти размером более 2 ГБ в Microsoft SQL Server
Microsoft SQL Server 2000 Standard Edition и Microsoft SQL Server 2005 Workgroup Edition могут использовать до 2 ГБ физической памяти, которая динамически распределяется и освобождается в зависимости от рабочей нагрузки. При увеличении объемов базы данных этого объема оперативной памяти становится недостаточно для эффективного кэширования данных и поддержания производительности на приемлемом уровне.
В Microsoft SQL Server 2000 Enterprise Edition, Microsoft SQL Server 2005 Standard Edition и Microsoft SQL Server 2005 Enterprise Edition введена поддержка использования Address Windowing Extensions (AWE) для адресации всего объема оперативной памяти, доступного операционной системе при использовании Microsoft Windows 2000 Advanced Server или Microsoft Windows Sever 2003 Enterprise Edition . С помощью AWE Microsoft SQL Server резервирует память, которая не используется операционной системой и другими приложениями. При использовании Microsoft Windows 2000 Advanced Server эта память распределяется статически, при старте, причем зарезервированная память может использовать только для кэширования данных. Microsoft Windows Sever 2003 Enterprise Edition позволяет динамически управлять объемом используемой оперативной памяти. Использование этой возможности Microsoft SQL Server позволяет существенно увеличить производительность при работе с базами данных большого объема.
Чтобы использовать память Address Windowing Extensions (AWE), Microsoft SQL Server необходимо запустить с помощью учетной записи Windows, которой присвоены административные полномочия для закрепления страниц в памяти.
Параметры настройки.
- Использование параметра /3GB в файле Boot.ini позволяет Microsoft SQL Server адресовать до 3 ГБ физической памяти без использования механизма AWE .
Фрагмент файла BOOT.INI с включенным режимом / 3 GB:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect / 3GB
Применение параметра /PAE в файле Boot.ini и включение функции AWE в Microsoft SQL Server позволяет использовать больше 4 ГБ физической памяти. Следует учитывать, что при использовании Microsoft Windows 2000 Advanced Server и включении функции AWE, Microsoft SQL Server перестает динамически управлять размером используемой оперативной памяти. При старте он будет резервировать для своих целей практически всю доступную память, и для работы других приложений останется менее 128МБ. Рекомендуется ограничивать объем оперативной памяти, доступный SQL Server с помощью параметра max server memory.
Фрагмент файла BOOT.INI с включенным режимом /PAE:
Копировать в буфер обменаmulti(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect / PAE
Пример включения функции AWE и установки предела 6 ГБ для параметра " max server memory " .
Копировать в буфер обменаsp_configure 'show advanced options', 1
RECONFIGURE
GO
sp_configure 'awe enabled', 1
RECONFIGURE
GO
sp_configure 'max server memory', 6144
RECONFIGURE
GO
Читайте также: