SQL Server работает медленнее, пока мы не перезапустим его

У нас есть база данных со смешанной рабочей нагрузкой OLAP / OLTP. Запросы являются специальными и динамически создаются на сервере приложений среднего уровня. Когда мы запускаем сервер, производительность вполне приемлема, но потребление памяти увеличивается, пока не будет исчерпана вся доступная память (30 ГБ). После этого система становится все медленнее и медленнее.

Команды вроде Dbcc freeproccacheне действуют.

В нем не так много транзакций select * from sys.dm_tran_session_transactions(не больше, чем когда система в порядке), иногда этот список пуст.

Первый результат dbcc memorystatusIS

VM Reserved               42136628
VM Committed               1487176
Locked Pages Allocated    24994048
Reserved Memory               1024
Reserved Memory In Use           0

Перезапуск SQL Server на некоторое время решает проблему.

1. Что вызывает это поведение? Как этого можно избежать?
2. Если реальное решение проблемы слишком сложно, существует ли команда, которая заставляет SQL Server фактически освободить всю память без полного перезапуска СУБД?

Сервер работает на выделенном оборудовании (не виртуальной машине). У нас было несколько запланированных рабочих мест, но мы отключили их на некоторое время без изменений. На том же сервере выполняются другие приложения среднего уровня, но они используют не более 2 ГБ памяти, незначительное использование ЦП и почти не требуют ввода-вывода. Мы перезапустили все такие приложения без изменений.

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

В частности, я бы проверил счетчики производительности Memory\Available MBytesи Paging File(_Total)\% Usageпотому что вы сказали, что проблемы начинают возникать только тогда, когда буферный пул заполнен. Числа, которые вы получаете с этих счетчиков, могут указывать на то, что параметр максимальной памяти сервера необходимо отрегулировать (увеличить или уменьшить) для объема физической памяти, выделенной серверу. Как я уже заметил здесь , я не рекомендую базирование максимальной настройки памяти на объеме физической памяти , за исключением случаев , догадки для отправной точки . Всегда измеряйте результат и корректируйте оттуда.

Если объем свободной памяти слишком мал (<500), или использование файла подкачки превышает ноль , это может означать, что экземпляр SQL Server перегружен: в SQL Server 2008 R2 параметр max server memory определяет только размер пула буферов , а не другое использование памяти, такое как кэш плана. SQL Server также не заботится о других приложениях, которые могут работать в системе. Такое дополнительное использование памяти может оказать давление на память Windows или других приложений, что может привести к замене диска. Этого вы хотите избежать любой ценой, особенно если файл подкачки существует на томе, поддерживаемом простым зеркалом RAID 1. Мне кажется, что это проблема, и устранение этой проблемы должно быть устранено.

Если объем свободной памяти велик (> 1000) и использование файла подкачки равно нулю, вы, вероятно, можете немного увеличить максимальную память сервера (с шагом 256 МБ), чтобы максимально увеличить использование памяти сервером. Однако, скорее всего, это не решит проблему, и вам нужно будет посмотреть в другом месте, возможно, на счетчики физических дисков и ожидаемый срок службы страницы пула буферов. Если запросы превышают пул буферов, вы ничего не можете сделать, кроме как повысить производительность диска, увеличить объем физической памяти, доступной для сервера, чтобы все страницы данных могли поместиться в памяти одновременно, или изменить базу данных так, чтобы она не занимала слишком много места. физическое пространство (возможно, с использованием сжатия строк или страниц или путем перестроения индексов с более высоким FILLFACTOR).

Я опубликовал статью на эту тему здесь , которая идет в более подробно об этой проблеме и как ее решить.

Как правило, тенденция к замедлению во времени должна быть обратной, поскольку по мере того, как страницы баз данных перемещаются в кэш, производительность должна улучшаться (ожидаемое время жизни страниц и коэффициент попадания в буфер увеличиваются со временем), вы установили максимальную память (total_physical_mem - 2 ГБ)?

Похоже, что несколько ваших запросов приводят к тому, что SQL Server выполняет многоэтапную работу. Вы можете попробовать Resource Governor, чтобы ограничить потребление памяти большими и средними запросами, чтобы запросы приложений всегда имели достаточно доступного буфера.