Менеджер памяти SQLOS: диагностика вытеснения памяти

По материалам статьи Slava Oks: SQLOS's memory manager: responding to memory pressure

При настройке SQL Server очень важно понимать, как он реагирует на вытеснение памяти. Я уже посветил довольно много времени описанию разных типов вытеснения памяти. В этой статье Вы узнаете, почему это так важно. Вытеснение памяти можно классифицировать двумя основными группами: вытеснение VAS и вытеснение физической памяти. Вытеснение физической памяти может быть спровоцировано операционной системой, мы назвали его внешним, или оно может быть спровоцировано процессом, такое вытеснение мы называем внутренним.
SQLOS использует специализированную структуру, которая занимается обслуживанием любого из типов вытеснения памяти процесса. В основе этой структуры находится Resource Monitor (RM). RM контролирует состояние внешних и внутренних индикаторов памяти. Когда один из них изменяется, RM отслеживает состояние всех индикаторов. При этом соответствующее оповещение отображает состояние индикатора. Такое оповещение рассчитано на то, что оно будет разослано всем клеркам памяти (Memory Clerks).

------------------ | Resource Monitor | / -----------------\ / | \ ------------------------------ --------- --------------------------------- |Low Physical Internal/External| | Low VAS | | High Physical Internal/External | ------------------------------ --------- ---------------------------------

Resource Monitor и Memory Clerks

Вспомним, что в SQLOS имеются два типа узлов: узлы памяти и процессора. Узлы памяти обеспечивают место для распределения, а узлы процессора предоставляют возможности для планирования. В текущей реализации каждый узел процессора имеет собственный монитор ресурса (Resource Monitor). Это нужно для того, чтобы быть обеспечить реакцию на вытеснение памяти для узла. Я расскажу более подробно об узлах процессора, когда перейду к рассмотрению подсистемы планирования SQLOS. Пока же нужно уяснить, что в зависимости от аппаратной конфигурации одновременно может исполняться несколько задач RM.
Потребление больших областей памяти нагружает клерков памяти, которые эту память распределяют. Другой важной задачей клерков памяти является реакция на оповещения RM. Каждый потребитель памяти является подписчиком клерка, получая оповещения о вытеснении памяти, что обеспечивает соответствующую реакцию.
Каждый узел процессора имеет свой список клерков памяти. Первый RM определяет, какие оповещения он должен рассылать. Для этого он проходит по списку и рассылает оповещения каждому клерку памяти по очереди. В течение рассылки, кэши принимают оповещения также, как и клерки памяти.

----------------- ------------------------| Resource Monitor|------------------------- / ----------------- \ / / \ \ / / \ \ -------------------- ------------------ ------------------------ ---------------- |Generic Memory Clerk| |Cache Memory Clerk| |Buffer Pool Memory Clerk| |CLR Memory Clerk| -------------------- ------------------ ------------------------ -----------------

С точки зрения планирования у RM есть несколько важных вещей, о которых стоит знать:

• Resource Monitor в своей работе использует собственный планировщик, разработчики назвали его скрытым планировщиком.

• Resource Monitor работает в неприоритетном режиме.

• Узел для Dedicated Admin Connection не имеет собственного Resource Monitor.

Некоторые клерки памяти могут реагировать на вытеснение памяти. Мы уже упоминали кэши, но кроме них, ещё и каждый узел процессоров понуждает своего клерка ограничивать работу исполнителя (worker) и урезать системные пулы потока, который подвержен вытеснению. К примеру, полнотекстовый поиск, в таких случаях, даёт команду своему клерку памяти на сокращение разделяемых буферов памяти, которые он совместно использует с MSSearch. CLR использует своего клерка для вызова сборщика "мусора", а буферный пул (Buffer Pool) понуждает своего клерка реагировать только на внешнее вытеснение памяти в VAS (Кстати, почему?).

Внешнее вытеснение памяти: RM и Buffer Pool

В перспективе SQLOS, Buffer Pool - это программа распределения одиночных страниц и используемый экстенсивно менеджер памяти. О внешнем вытеснении памяти сообщает операционная система Windows. На это реагирует RM, рассылая соответствующие оповещения клеркам. После получения оповещения, BP ещё раз вычисляет целевое значение доступной памяти, и разрешенный для использования BP объём физической памяти. Имейте в виду, что целевое значение не может быть меньше, чем установленное через sp_configure в параметре конфигурации значение min server memory, и не может превышать max server memory. Если новое целевое значение меньше текущего, доступного буфера, BP будет сжиматься до тех пор, пока не исчезает внешнее вытеснение физической памяти. В течение этого процесса BP пробует проводить высвобождение, а в случае с AWE, возвращать свободную физическую память обратно операционной системе. Вспомним, что в случае с SQL Server 2000, работающем в AWE режиме, BP не реагирует на вытеснение физической памяти.

Внутреннее вытеснение памяти: BP и Resource Monitor

Уменьшение объёма BP приводит к внутреннему вытеснению памяти. Это один из путей для BP, чтобы процесс претерпел внутреннее вытеснение физической памяти. Какие же компоненты BP оповещают о внутреннем вытеснении памяти? Да, Вы правильно решили, что именно SQLOS предоставляет BP механизм, который включает соответствующий внутреннему вытеснению памяти индикатор RM. Как Вы знаете, RM распознаёт сигнал индикатора и инициирует оповещение, которое рассылается клеркам. У BP есть свой клерк, которому RM вернёт это оповещение. А разве тут не будет зацикливания!? На самом деле, всё обстоит так потому, что BP занимается только контролем внешнего вытеснения физической памяти и игнорирует любое внутреннее вытеснение физической.
Существует ещё две причины проявления внутреннего вытеснения физической памяти. Оно может быть вызвано динамическим изменением max server memory. Кроме того, это может произойти, когда захвачены 75 % страниц BP, с использованием интерфейса SQLOS для распределения одиночных страниц. Инициируя внутреннее вытеснение физической памяти, BP востребует свои страницы из кэшей и других компонент, которые в это время их используют.

Вытеснение памяти VAS

До сих пор я рассматривал то, как SQLOS, а следовательно и SQL Server, организует вытеснение внешней и внутренней физической памяти. Обслуживание вытеснения VAS даётся труднее, потому что Windows сложнее его распознать. О вытеснении VAS оповещение RM может осуществляться по двум путям. Первый путь проходит через узел памяти, когда виртуальные или разделяемые интерфейсы узла памяти не смогут распределять куски по 4 МБ и менее (RM не получит оповещение, если размер куска больше 4 МБ), после чего узел памяти включает в RM индикатор недостаточности VAS. Тут же существует более активный путь, когда при своей работе RM проверяет наличие в VAS блока в 4 МБ, и если такого куска не находиться, он сам индицирует недостаточность VAS, и начинает рассылать соответствующее оповещение.
Возможность распознания того, что имеет место вытеснение VAS - это то, чем отличаются SQL Server 2000 и SQL Server 2005. SQL Server 2000 очень тяжело преодолевает вытеснение VAS. В SQL Server 2005 о вытеснении VAS рассылается оповещение всем клеркам памяти, после чего они могут сократить используемые ресурсы. Например, узел процессора может уменьшить число своих потоков, CLR может высвободить не используемые уже домены приложений, сетевые библиотеки сократят количество своих буферов.
Когда мы говорили о менеджере памяти SQLOS, я упоминал о реакции BP на вытеснение VAS, когда сервер работает в AWE режиме. Настало время внести необходимые разъяснения. Когда BP принимает оповещение о недостаточности VAS, он сообщает о ранее им зарезервированных, кратных 4 МБ кусках VAS. Если он обнаруживает неиспользуемые куски по 4 МБ, или неиспользуемые страницы базы данных, он легко может освободить их.

Контроль вытеснения памяти

Эта статья не будет полной без обзора возможностей контроля и диагностики разных типов вытеснения памяти при работе SQL Server. Разработчики существенно облегчили для Вас эти возможности. Существует dm-представление, которое показывает хронологию вытеснения памяти.
Представленный ниже запрос показывает последние разосланные RM оповещения:

SELECT * FROM sys.dm_os_ring_buffers WHERE ring_buffer_type='RING_BUFFER_RESOURCE_MONITOR'

(имеется несколько разных закольцованных буферов, которые можно указать в условии выборки, включая: планировщики, исключения и "out of memory", но это уже темы для другой статьи)

Вот пример возможного результата исполнения этого запроса:

<Record id = "0" type ="RING_BUFFER_RESOURCE_MONITOR" time ="788327260"> <ResourceMonitor> <Notification>RESOURCE_MEMPHYSICAL_HIGH</Notification> <Indicators>1</Indicators> <NodeId>0</NodeId> </ResourceMonitor> <MemoryNode id="0"> <AvailableMemoryOnNode>0</AvailableMemoryOnNode> <ReservedMemory>2111472</ReservedMemory> <CommittedMemory>20944</CommittedMemory> <SharedMemory>0</SharedMemory> <AWEMemory>0</AWEMemory> <SinglePagesMemory>1792</SinglePagesMemory> <MultiplePagesMemory>6680</MultiplePagesMemory> <CachedMemory>592</CachedMemory> </MemoryNode> <MemoryRecord> <TotalPhysicalMemory>1047556</TotalPhysicalMemory> <AvailablePhysicalMemory>542532</AvailablePhysicalMemory> <TotalPageFile>3254476</TotalPageFile> <AvailablePageFile>2242756</AvailablePageFile> <TotalVirtualAddressSpace>2097024</TotalVirtualAddressSpace> <AvailableVirtualAddressSpace>972352</AvailableVirtualAddressSpace> <AvailableExtendedVirtualAddressSpace>0</AvailableExtendedVirtualAddressSpace> </MemoryRecord> </Record>

Второй запрос показывает, когда BP, программа распределения одиночных страниц, инициирует/завершает внутреннее вытеснение памяти:

SELECT * FROM sys.dm_os_ring_buffers WHERE ring_buffer_type='RING_BUFFER_SINGLE_PAGE_ALLOCATOR'

<Record id = "9" type ="RING_BUFFER_SINGLE_PAGE_ALLOCATOR" time ="789165566"> <Pressure status="0"><AllocatedPages>477</AllocatedPages> <AllAllocatedPages>477</AllAllocatedPages> <TargetPages>31553</TargetPages> <AjustedTargetPages>31553</AjustedTargetPages> <CurrentTime>788967250</CurrentTime> <DeltaTime>110</DeltaTime> <CurrentAllocationRequests>79709</CurrentAllocationRequests> <DeltaAllocationRequests>156</DeltaAllocationRequests> <CurrentFreeRequests>79232</CurrentFreeRequests> <DeltaFreeRequests>23640</DeltaFreeRequests> </Pressure> </Record>

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

Заключение

Вытеснение памяти может оказывать сильное воздействие на производительность сервера и стабильность его работы. Особенно это критично, когда SQL Server совместно использует сервер с другими приложениями или конкурирует за VAS с расширенными хранимыми процедурами или CLR. Вытеснение памяти может задействовать дополнительные ресурсы I/O, рекомпиляции и другие паразитные действия. Поэтому, понимание и диагностика разных типов вытеснения памяти, которым подвержен SQL Server, является очень важной частью управления сервером и разработки приложений баз данных. Я надеюсь, что эта статья поможет Вам делать это более эффективно.