SQL Server и Dynamic Memory в Windows Server 2008 R2 SP1

С появлением новых возможностей в SP1 для Windows Server 2008 R2, возникает закономерный вопрос – будет ли задействован ли новый функционал, в частности, Dynamic Memory, в работе того или иного сервиса.

Хотелось бы обратить внимание на работу баз данных на платформе Hyper-V. Принимая во внимание то, что команда разработчиков SQL Server заявила о поддержке своего продукта в виртуальной среде, логично предположить, что и динамическое распределение памяти будет функционировать в виртуальных машинах с SQL Server. Однако есть несколько «но», на которых бы хотелось заострить внимание.

Опуская системные требования к хостовым и гостевым операционным системам, остановимся на редакциях SQL Server. Теоретически, все заявленные версии SQL могут работать в виртуальной машине, использующей Dynamic Memory, однако на практике корректно ее использовать могут лишь следующие версии:

• SQL Server 2005 Enterprise
• SQL Server 2008 Enterprise/Datacenter
• SQL Server 2008 R2 Enterprise/Datacenter

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

Рассмотрим настройку динамической памяти в простейшей конфигурации. Следует отметить, что рекомендуется использовать модель «Locked Page Memory». Связано это в первую очередь с тем, что SQL Server не позволит гипервизору выгрузить память, используемую базами данных. По той же причине не следует применять модель «Large Page Memory», так как подобная технология уже используется Hyper-V и ощутимого прироста в производительности не принесет.

Startup RAM – очевидно, что заложенное для старта виртуальной машины значение памяти должно быть больше, чем объем ОЗУ, предполагающий старт сервисов SQL

Maximum RAM – исходя из обратной логики, максимальное значение памяти, выделяемое виртуальной машине, должно превышать тот объем ОЗУ, который предполагается выделить для использования службами баз данных

Memory Buffer – в связи с тем, что SQL Server обладает собственным Buffer Pool, рекомендуется выставлять свободной буфер минимальным, 5%. Увеличение данного значения может привести к проблемам утилизации памяти виртуальными машинами

Memory Weight – фактически определяет, какая виртуальная машина получит память при ее недостатке. Определяется, исходя из требований к производительности той или иной виртуальной машины.

Стоит отметить работу в виртуальной среде нескольких экземпляров SQL – подобный сценарий не попадает в разряд рекомендуемых по ожидаемой производительности и управляемости. В принципе, что бы достичь последних, необходимо рассчитывать максимальную и минимальную память для виртуальной машины с несколькими экземплярами SQL Server по тому же принципу, что описан выше: максимальный объем ОЗУ должен превышать объем, требуемый для корректной работы всех экземпляров SQL, минимальное значение должно позволить виртуальной машине начать работу.

В завершение статьи нужно упомянуть счетчики, позволяющие отследить производительность памяти в виртуализованном SQL Server

• Process – Working Set. Счетчик виртуальных машин, позволяющий мониторить физическую память, фактически потребляемую SQL Server
• SQL Server – Buffer Cache Hit Ratio, счетчик виртуальных машин, предоставляемый SQL Server. Определяет, каковы возможности SQL по размещению данных в буфере кэша. Чем выше это значение, тем лучше это скажется на производительности. Желательно удерживать это значение около 90% и выше.

Дополнение от 02.08.2011 - появился документ Running SQL Server with Hyper-V Dynamic Memory - Best Practices and Considerations