Потребление SQL Server «Total Server Memory» в течение нескольких месяцев оставалось неизменным с 64 ГБ и более доступными

Я столкнулся со странной проблемой, когда 64-разрядная версия SQL Server 2016 Standard Edition, казалось, ограничивалась ровно половиной общей памяти, выделенной для него (64 ГБ из 128 ГБ).

Вывод @@VERSION:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22 декабря 2017 г. 11:25:00 Авторское право (c) Microsoft Corporation Standard Edition (64-разрядная версия) в Windows Server 2012 R2 Datacenter 6.3 ( Сборка 9600:) (Гипервизор)

Вывод sys.dm_os_process_memory:

Когда я запрос sys.dm_os_performance_counters, я вижу , что Target Server Memory (KB)находится 131072000и Total Server Memory (KB)это чуть меньше половины того , что у 65308016. В большинстве сценариев я бы понял, что это нормальное поведение, поскольку SQL Server еще не определил, что ему нужно выделять дополнительную память для себя.

Тем не менее, он "застрял" на ~ 64 ГБ в течение более 2 месяцев. За это время мы выполнили значительное количество операций с интенсивной памятью над некоторыми базами данных и добавили к экземпляру еще около 40 баз данных. Мы работаем с 292 базами данных, каждый из которых имеет предварительно выделенные файлы данных по 4 ГБ со скоростью автоматического увеличения 256 МБ и файлы журнала 2 ГБ со скоростью автоматического роста 128 МБ. Я выполняю полное резервное копирование один раз каждую ночь в 12:00 и начинаю резервное копирование журнала транзакций с понедельника по пятницу, начиная с 6:00 до 20:00 с интервалом в каждые 15 минут. Эти базы данных имеют относительно низкую общую пропускную способность, но я скептически отношусь к тому, что что-то не так, учитывая, что SQL Server не подкрался кTarget Server Memory Естественно, благодаря новым добавлениям в базу данных, нормальному выполнению запросов, а также выполненным конвейерам ETL с интенсивным объемом памяти.

Сам экземпляр SQL Server находится на виртуализированном (VMware) сервере Windows Server 2012R2 с 12 ЦП, 144 ГБ памяти (128 ГБ для SQL Server, 16 ГБ зарезервировано для Windows) и всего 4 виртуальных диска, которые расположены на vSAN с 15K SAS-дисками. , Windows естественно находится на диске C: 64 ГБ с файлом подкачки 32 ГБ. Файлы данных размещаются на диске размером 2 ТБ D: файлы журнала располагаются на диске размером 2 ТБ L, а база данных tempdb - на диске T: 256 ГБ с файлами 8x16 ГБ без автоматического увеличения.

Я проверил, что на сервере не запущены другие экземпляры SQL Server MSSQLSERVER.

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

Я использую RedGate SQL Monitor для анализа, и ниже приводится история последних 18 дней Total Server Memory. Как вы можете видеть, использование памяти оставалось полностью неизменным, за исключением одного увеличения в ~ 300 МБ в начале апреля.

Что может быть причиной этого? Что я могу посмотреть поближе, чтобы определить, почему SQL Server не хочет использовать дополнительные 64 ГБ + памяти, выделенной для него?

Выход работает sp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Приоритет 50: Производительность :

• Планировщики ЦП в автономном режиме - некоторые ядра ЦП недоступны для SQL Server из-за проблем маскирования или лицензирования.

• Узлы памяти в автономном режиме - из-за проблем с маскированием или лицензированием часть памяти может быть недоступна.

Приоритет 50: Надежность :

• Удаленный ЦАП отключен - удаленный доступ к выделенному административному соединению (DAC) не включен. ЦАП может значительно облегчить удаленное устранение неполадок, когда SQL Server не отвечает.

Приоритет 100: Производительность :

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

• Триггеры сервера включены

  • Триггер сервера [RG_SQLLighthouse_DDLTrigger] включен. Убедитесь, что вы понимаете, что делает этот триггер - чем меньше работы, тем лучше.

  • Триггер сервера [SSMSRemoteBlock] включен. Убедитесь, что вы понимаете, что делает этот триггер - чем меньше работы, тем лучше.

Приоритет 150: Производительность :

• Запросы на принуждение к соединению - с момента перезапуска было зарегистрировано 1480 экземпляров подсказок к соединению. Это означает, что запросы управляют оптимизатором SQL Server, и если они не знают, что делают, это может принести больше вреда, чем пользы. Это также может объяснить, почему не работают настройки DBA.

• Запросы Форсирование порядка подсказок - 2153 экземпляров порядка подсказок были записаны с момента перезапуска. Это означает, что запросы управляют оптимизатором SQL Server, и если они не знают, что делают, это может принести больше вреда, чем пользы. Это также может объяснить, почему не работают настройки DBA.

Приоритет 170: Конфигурация файла :

• Системная база данных на диске C

  • master - база данных master содержит файл на диске C. Размещение системных баз данных на диске C сопряжено с риском сбоя сервера, когда ему не хватает места.

  • модель - база данных модели содержит файл на диске C. Размещение системных баз данных на диске C сопряжено с риском сбоя сервера, когда ему не хватает места.

  • msdb - в базе данных msdb есть файл на диске C. Размещение системных баз данных на диске C сопряжено с риском сбоя сервера, когда ему не хватает места.

Приоритет 200: Информационный :

• Одновременные задания агента. Несколько заданий агента SQL Server настроены для одновременного запуска. Для получения подробной информации о расписании см. Запрос в URL.

• Таблицы в главной базе данных мастера - таблица CommandLog в базе данных мастера была создана конечными пользователями 30 июля 2017 года в 17:22. Таблицы в базе данных master не могут быть восстановлены в случае аварии.

• TraceFlag On

  • Флаг трассировки 1118 включен глобально.

  • Флаг трассировки 1222 включен глобально.

  • Флаг трассировки 2371 включен глобально.

Приоритет 200: Конфигурация сервера не по умолчанию :

• Агент XP - эта опция sp_configure была изменена. Его значение по умолчанию 0, и оно было установлено в 1.

• резервная контрольная сумма по умолчанию - эта опция sp_configure была изменена. Его значение по умолчанию 0, и оно было установлено в 1.

• резервное сжатие по умолчанию - эта опция sp_configure была изменена. Его значение по умолчанию 0, и оно было установлено в 1.

• порог стоимости для параллелизма - эта опция sp_configure была изменена. Его значение по умолчанию 5, и оно было установлено на 48.

• максимальная степень параллелизма - эта опция sp_configure была изменена. Его значение по умолчанию равно 0, и оно было установлено на 12.

• максимальная память сервера (МБ) - эта опция sp_configure была изменена. Его значение по умолчанию - 2147483647, и оно было установлено на 128000.

• оптимизировать для специальных рабочих нагрузок - эта опция sp_configure была изменена. Его значение по умолчанию 0, и оно было установлено в 1.

• показать дополнительные параметры - эта опция sp_configure была изменена. Его значение по умолчанию 0, и оно было установлено в 1.

• xp_cmdshell - эта опция sp_configure была изменена. Его значение по умолчанию 0, и оно было установлено в 1.

Приоритет 200: Надежность :

• Расширенные хранимые процедуры в мастере

• master - расширенная хранимая процедура [sqbdata] находится в базе данных master. Возможно, используется CLR, и теперь база данных master должна быть частью вашего планирования резервного копирования / восстановления.

  • master - расширенная хранимая процедура [sqbdir] находится в базе данных master. Возможно, используется CLR, и теперь база данных master должна быть частью вашего планирования резервного копирования / восстановления.

  • master - расширенная хранимая процедура [sqbmemory] находится в базе данных master. Возможно, используется CLR, и теперь база данных master должна быть частью вашего планирования резервного копирования / восстановления.

  • master - расширенная хранимая процедура [sqbstatus] находится в базе данных master. Возможно, используется CLR, и теперь база данных master должна быть частью вашего планирования резервного копирования / восстановления.

  • master - расширенная хранимая процедура [sqbtest] находится в базе данных master. Возможно, используется CLR, и теперь база данных master должна быть частью вашего планирования резервного копирования / восстановления.

  • master - расширенная хранимая процедура [sqbtestcancel] находится в базе данных master. Возможно, используется CLR, и теперь база данных master должна быть частью вашего планирования резервного копирования / восстановления.

  • master - расширенная хранимая процедура [sqbteststatus] находится в базе данных master. Возможно, используется CLR, и теперь база данных master должна быть частью вашего планирования резервного копирования / восстановления.

  • master - расширенная хранимая процедура [sqbutility] находится в базе данных master. Возможно, используется CLR, и теперь база данных master должна быть частью вашего планирования резервного копирования / восстановления.

  • master - расширенная хранимая процедура [sqlbackup] находится в базе данных master. Возможно, используется CLR, и теперь база данных master должна быть частью вашего планирования резервного копирования / восстановления.

Приоритет 210: Конфигурация базы данных не по умолчанию :

• Read Committed Snapshot Isolation Enabled - этот параметр базы данных не используется по умолчанию.

  • RedGate

  • RedGateMonitor

• Включена изоляция моментальных снимков - этот параметр базы данных не используется по умолчанию.

  • RedGate

  • RedGateMonitor

Приоритет 240: Статистика ожидания :

• 1 - SOS_SCHEDULER_YIELD - 1770,8 часов ожидания, 115,9 минут среднего времени ожидания в час, 100,0% ожидания сигнала, 1419212079 задач ожидания, среднее время ожидания 4,5 мс.

Приоритет 250: Информационный :

• SQL Server работает под учетной записью NT Service - я работаю как NT Service \ MSSQLSERVER. Я хотел бы иметь учетную запись службы Active Directory вместо.

Приоритет 250: Информация о сервере :

• Содержание трассировки по умолчанию - трассировка по умолчанию содержит 36 часов данных с 14 апреля 2018 г. по 23:21 и 16 апреля 2018 г. по 11:13. Файлы трассировки по умолчанию находятся в: C: \ Program Files \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Log

• Диск C Space - 196816,00MB бесплатно на диске C

• Диск D Space - 894823.00MB бесплатно на диске E

• Drive L Space - 1361367.00MB бесплатно на диске F

• Drive T Space - 114441.00MB бесплатно на диске G

• Аппаратное обеспечение - логические процессоры: 12. Физическая память: 144 ГБ.

• Аппаратное обеспечение - NUMA Config

  • Узел: 0 Состояние: ONLINE Онлайн-планировщики: 4 Автономные планировщики: 2 Группа процессоров: 0 Узел памяти: 0 Память VAS Зарезервировано ГБ: 186

  • Узел: 1 Состояние: OFFLINE Сетевые планировщики: 0 Автономные планировщики: 6 Группа процессоров: 0 Узел памяти: 0 Память VAS Зарезервировано ГБ: 186

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

• План энергопотребления - Ваш сервер имеет процессоры с частотой 2,60 ГГц и находится в режиме сбалансированного энергопотребления - Э-э ... вы хотите, чтобы ваши процессоры работали на полной скорости, верно?

• Последний перезапуск сервера - 9 марта 2018 г. 7:27

• Имя сервера - [отредактировано]

• Сервисы

  • Служба: SQL Server (MSSQLSERVER) работает под учетной записью службы NT Service \ MSSQLSERVER. Время последнего запуска: 9 марта 2018 7:27. Тип запуска: автоматический, в данный момент работает.

  • Служба: агент SQL Server (MSSQLSERVER) работает под учетной записью службы LocalSystem. Время последнего запуска: не показано. Тип запуска: автоматический, в данный момент работает.

• Последний перезапуск SQL Server - 9 марта 2018 г. 6:27

• Служба SQL Server - версия: 13.0.4466.4. Уровень патча: SP1. Накопительное обновление: CU7. Издание: Standard Edition (64-разрядное). Группы доступности включены: 0. Статус менеджера групп доступности: 2

• Виртуальный сервер - Тип: (HYPERVISOR)

• Версия для Windows - Вы используете довольно современную версию Windows: Server 2012R2 эпохи, версия 6.3

Приоритет 254: Рандат :

• Капитанский бревно: что-то и что-то ...

Могу поспорить, что вы настроили виртуальные процессоры таким образом, что некоторые узлы процессора и / или узлы памяти находятся в автономном режиме.

Скачайте sp_Blitz (заявление об отказе: я один из авторов этого бесплатного скрипта с открытым исходным кодом) и запустите его:

sp_Blitz @CheckServerInfo = 1;

Ищите предупреждения о том, что ЦП и / или узлы памяти находятся в автономном режиме. SQL Server Standard Edition видит только первые 4 сокета ЦП, и вы, возможно, настроили ВМ как что-то вроде 6 двухъядерных ЦП. В итоге возникнет проблема, похожая на то, как 20-ядерные ограничения Enterprise Edition ограничивают объем памяти, который вы можете видеть .

Если вы хотите поделиться выводом sp_Blitz здесь, вы можете запустить его так, чтобы вывести в Markdown, который затем вы можете скопировать / вставить в свой вопрос:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Обновление 2018/04/16 - подтверждено. Вы подключили вывод sp_Blitz (спасибо за это!), И он действительно показывает, что у вас есть узлы процессора и памяти в автономном режиме. Кто бы ни создавал виртуальную машину, он настроил ее как 12 одноядерных процессоров, поэтому в SQL Server Standard Edition видны только первые 4 сокета (ядра) и подключенная к ним память.

Чтобы это исправить, выключите виртуальную машину, настройте ее как двухъядерную 6-ядерную виртуальную машину, а затем SQL Server Standard Edition увидит все ядра и память. Это также уменьшит ваши ожидания SOS_SCHEDULER_YIELD - прямо сейчас, ваш SQL Server забивает первые 4 ядра, но это все. После этого исправления он сможет работать на всех 12 ядрах.

В качестве дополнения к плану действий Брента Озара я хотел поделиться результатами. Как отметил Брент, в VMware мы неправильно сконфигурировали виртуальную машину с 12 одноядерными процессорами. Это привело к тому, что оставшиеся 8 ядер были недоступны для SQL Server, и, как следствие, к проблеме с памятью, описанной в моем первоначальном вопросе. Вчера вечером мы перевели наши службы в режим обслуживания, чтобы соответствующим образом перенастроить ВМ. Мало того, что мы наблюдаем нормальное увеличение объема памяти, но, как намекал Брент, количество ожиданий уменьшилось в геометрической прогрессии, и наша общая производительность SQL Server резко возросла. Конфигурации vNUMA теперь представляют собой счастливые маленькие компоненты, которые разделяют наши рабочие нагрузки.

Для тех, кто может использовать VMware vSphere 6.5, краткие шаги для выполнения элемента действия, описанного Брентом, следующие.

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

2. В основной панели перейдите Configure > VM hardware, нажмите Editкнопку в правом верхнем углу. Вы откроете контекстное меню, которое имеет Edit Settings. Для справки, изображение ниже является неправильной конфигурацией. Обратите внимание, что я Cores per Socketустановил 1. Учитывая ограничения SQL Server Standard Edition, это плохая конфигурация.

   

3. Исправить так же просто, как настроить Cores per Socketзначение. В нашем случае мы установили его 6так, чтобы у нас было 2 Sockets. Это позволяет SQL Server использовать все 12 процессоров.

   

Важное примечание: не устанавливайте значение, где либо, Number of Coresлибо Socketsявляется нечетным числом. NUMA любит баланс, и по правилу должно делиться на 2. Например, конфигурация от 4 ядер до 3 сокетов будет несбалансированной. Фактически, если бы вы работали sp_Blitzс этим типом конфигурации, он бы выдал предупреждение об этом.

Раздел 3.3 « Архитектура Microsoft SQL Server в VMware vSphere» (предупреждение в формате PDF) подробно описывает это. Практики, изложенные в техническом документе, применимы к большинству локальных средств виртуализации SQL Server.

Вот еще несколько ресурсов, которые я собрал в своих исследованиях после публикации Брента:

• Виртуализация больших баз данных - планирование мощности процессора VMware

• Виртуальная машина vCPU и vNUMA.

• Разделение ядер на сокет из топологии Virtual NUMA в vSphere 6.5

Я закончу захват из RedGate SQL Monitor за последние 24 часа. Основной момент, на который следует обратить внимание, - это загрузка ЦП и количество ожиданий - во время наших пиковых часов вчера мы испытывали интенсивное использование ЦП и споры о ожидании. После этого простого исправления мы улучшили нашу производительность в десять раз. Даже наш дисковый ввод / вывод значительно сократился. Это, по-видимому, легко игнорируемый параметр, который может повысить виртуальную производительность на порядок. По крайней мере, это было упущено нашими инженерами и полный d'ой момент.

Также, согласно MSDN , стандарт SQL Server ограничен 64 ГБ ОЗУ. Мы «решили» это, разбив базу данных на несколько экземпляров, но ваша ситуация может этого не допустить.

Хм 2016, кажется, имеет ограничение в 128 ГБ, но разделение экземпляров может быть еще одним вариантом.