Сервер: SQL Server 2005 SP2 64 бит, 32 гигабайта памяти. 2 экземпляра SQL-сервера запущены. У основного экземпляра, который я использую, видно 20 гигов.
У нас есть ситуация, когда кажется, что время от времени очищается весь кеш процедур, что, в свою очередь, вызывает перекомпиляцию хранимой процедуры (sp). Как только sp находится в кеше, все некоторое время работает быстро. Через пару часов он очищается из кеша, и его нужно перекомпилировать, что на короткое время замедляет работу.
Я смотрю кеш, используя:
SELECT cp.objtype AS PlanType,
OBJECT_NAME(st.objectid,st.dbid) AS ObjectName,
cp.refcounts AS ReferenceCounts,
cp.usecounts AS UseCounts,
st.TEXT AS SQLBatch,
qp.query_plan AS QueryPlan
FROM sys.dm_exec_cached_plans AS cp
CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) AS qp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) AS st
GO
DBCC FREEPROCCACHE никогда не вызывается.
Если я запускаю DBCC MEMORYSTATUS, я вижу, что TotalPages кеш-памяти процедур составляет около 500 тыс. Страниц. Оказывается, для кеша выделено 3,9 гигабайта. Ссылка: Планирование кэширования в SQL Server 2008 (Раздел о кешировании включает 2005 SP 2). Он указывает, что предел давления должен быть 4,6 гига. (75% видимой целевой памяти из 0-4 ГБ + 10% видимой целевой памяти из 4 ГБ-64 ГБ + 5% видимой целевой памяти> 64 ГБ ... 3 ГБ + 1,6 ГБ = 4,6 ГБ)
Похоже, это указывает на то, что мы не должны испытывать давление кеш-памяти еще на 700 мегабайт. Если статистика менялась, то хранимая процедура должна все еще находиться в кеше и перекомпилироваться при следующем запуске и проверке статистики. Если бы это было так, я бы ожидал, что размер кеша останется почти постоянным.
Есть идеи, что может вызывать опустошение кеша процедур или что еще я должен следить, чтобы попытаться найти причину?
Настроен ли max_server_memory на втором экземпляре? Или, что более важно, сумма максимальных настроек памяти для двух экземпляров меньше общей памяти на сервере? В противном случае один экземпляр мог красть память у другого.