У меня есть один узел SQL2012 SP4 с несколькими базами данных.

На сервере доступно 20 ГБ памяти, 14 ГБ выделено для SQL (больше ничего не работает на коробке).

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

Я посмотрел на уведомления монитора ресурсов, и уведомления отскакивают от высокого / устойчивого / низкого значения каждые несколько миллисекунд:

RESOURCE_MEMPHYSICAL_HIGH RESOURCE_MEM_STEADY RESOURCE_MEMPHYSICAL_LOW

С отметками времени, которые находятся на расстоянии нескольких миллисекунд. PLE, по сути, является пилообразным рисунком.

Я видел это раньше с SQL2012 SP1 и этот вопрос:

Бесплатные страницы SQL Server 2012 в буферном кеше не используются

Кажется, похожая проблема, хотя я уже обновился до SP4.

Я попытался включить LPIM для служебной учетной записи, и я попытался возиться с настройкой максимальной памяти. Снижение максимального объема памяти, по-видимому, привело к более частому опустошению буферного кэша.

Есть идеи, что проверить дальше?

Нагрузка на сервер буквально ничто (я прокручиваю списки элементов в системе ERP, и она достигает около 40-50 МБ, прежде чем кэш просто снова падает).

Это интересно, потому что я обновил SP1, чтобы попытаться это исправить - кэш там занимал около 500 МБ. С тех пор я уменьшил максимальную настройку памяти до 14 ГБ, что, похоже, ухудшило ее.

Мне интересно, если Windows паникует и выдает неправильные уведомления о нехватке памяти в SQL - из этого следует, что сервер с максимальной памятью, установленной на неограниченную, казался работающим нормально, но никогда не заполнял кеш больше, чем несколько сотен МБ - но теперь это едва доходит до 50 ...

Больше информации: для тех, кто спросил

Количество ядер: 4

Размер базы данных: 80 ГБ

Журнал ошибок показывает: A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 247928, committed (KB): 495656, memory utilization: 50%.

Результаты запуска скриптов по этой ссылке: https://www.sqlskills.com/blogs/jonathan/identifying-external-memory-pressure-with-dm_os_ring_buffers-and-ring_buffer_resource_monitor/

Не уверен, как их интерпретировать - похоже, что в разное время наблюдается как внутреннее, так и внешнее давление памяти.

Еще больше информации:

Это гость Hyper-V, сидящий на хосте с общим объемом оперативной памяти 96 ГБ, из которых примерно половина выделяется для гостей.

Симптомы кажутся похожими на это:

SQL Server 2012 x64 - невозможно безопасно выделить более 50% оперативной памяти

Однако, когда я выделил 14 ГБ для SQL, симптомы сразу же проявились (только 3 ГБ памяти сервера было выделено)

Прошлой ночью я увеличил гостевую память до 32 ГБ, и проблема исчезла, но я вижу только 14 ГБ фиксации общей серверной памяти (а бизнес, который управляет БД, сегодня утром занят, и именно тогда у них обычно возникают проблемы с производительностью).

Около 8-9 Гбайт данных в кеше на данный момент кажется стабильным.

Похоже, что для этой нагрузки достаточно 20 ГБ. Я рад, что пока у меня осталось 32 ГБ, но я бы очень хотел разобраться с этим, чтобы лучше настроить виртуальные машины / SQL.

Я буду копать и обновлять, если найду ответ!

Еще больше информации:

Я не перезапускал SQL после включения LPIM (не понимая, что это было требованием), но я оставил этот параметр включенным и перезапустил его, чтобы обновить память, так что теперь я не уверен, что увеличение памяти или LPIM уменьшило проблемы.

Сегодня вечером, когда сервер простаивает, он запустится и снова проверит, как он выглядит на 20 ГБ.

Еще дальше Подробнее Подробнее:

В настоящее время сервер работает нормально с выделенным 32 ГБ, и с тех пор мы не видели проблемы. Если это всплывет снова, я вернусь к этому вопросу и продолжу копать.

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

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

Серверная память Параметры конфигурации сервера

Microsoft пишет в своей статье Параметры конфигурации сервера памяти сервера (Microsoft | SQL Docs) для раздела Установка параметров памяти вручную

_{( акцент мой)}

Кроме того, установка значения min_server_memory необходима в виртуализированной среде, чтобы гарантировать, что нагрузка на память со стороны основного хоста не пытается освободить память из пула буферов на виртуальной машине (VM) гостевого сервера SQL за пределами того, что необходимо для приемлемой производительности.

Раздел о блокировке страниц в памяти (тот же документ) имеет равный неотразимый абзац, который гласит:

_{( акцент мой)}

Эта политика Windows определяет, какие учетные записи могут использовать процесс для хранения данных в физической памяти, предотвращая подкачку данных системой в виртуальную память на диске . Блокировка страниц в памяти может привести к тому, что сервер откликнется при подкачке памяти на диск. Параметр «Блокировка страниц в памяти» устанавливается в значение «ВКЛ» в экземплярах SQL Server Standard Edition и выше, если учетной записи с правами на запуск sqlservr.exe предоставлено право пользователя «Блокировка страниц в памяти» (LPIM) Windows.

Далее раздел LPIM объясняет, что:

_{( акцент мой)}

Установка этого параметра не влияет на динамическое управление памятью SQL Server, позволяя расширять или уменьшать его по требованию других клерков памяти. При использовании прав пользователя «Блокировка страниц в памяти» рекомендуется установить верхний предел максимальной памяти сервера, как описано выше.

... и в важном комментарии, что:

_{( акцент мой)}

Установка этой опции должна использоваться только при необходимости, а именно, если есть признаки того, что процесс sqlservr выгружается . В этом случае в журнале ошибок появится сообщение об ошибке 17890, напоминающее приведенный ниже пример:

A significant part of sql server process memory has been paged out. 
This may result in a performance degradation. Duration: #### seconds. 
Working set (KB): ####, committed (KB): ####, memory utilization: ##%.  

Начиная с SQL Server 2012 (11.x), флаг трассировки 845 не требуется для Standard Edition для использования заблокированных страниц.

Решение

Исходя из вышеизложенных выводов и ваших наблюдений, решением вашей проблемы будет настройка следующих параметров:

1. min_server_memory (5-10 ГБ?) На основе вашего комментария:

   Около 8-9 Гбайт данных в кеше на данный момент кажется стабильным.

   ... и рекомендация Microsoft о настройке min_server_memory.

2. max_server_memory (20-32 ГБ) на основе ваших наблюдений:

   Похоже, что для этой нагрузки достаточно 20 ГБ. Я рад, что пока у меня осталось 32 ГБ, но я бы очень хотел разобраться с этим, чтобы лучше настроить виртуальные машины / SQL.

   ... и рекомендация Microsoft о настройке max_server_memory.

3. Блокировка страниц в памяти: включена для учетной записи службы SQL Server.
   На основании записи ERRORLOG вашего экземпляра SQL Server, которую вы упомянули, и ссылки Microsoft в статье.

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

Прежде чем продолжить ...

Одно из преимуществ использования виртуализированной среды состоит в том, что ресурсы могут / должны совместно использоваться и, возможно, даже чрезмерно выделяться. Однако включение блокировки страниц в памяти (LPIM) может оказать негативное влияние на вашу среду Hyper-V, если на вашем оборудовании размещено несколько экземпляров. Чрезмерное использование оперативной памяти может исчерпать другие случаи.

Прежде чем рассмотреть возможность переключения всех рычагов, начните с настроек 1. и 2. и если точная настройка этих настроек памяти не работает, то подумайте о включении LPIM, если у вас достаточно оборудования .