Из того, что я могу сказать, Process Cache Hit Ratio ниже 95% является проблемой. На моем боксе значения колеблются от 85 до 95%.
Как мне исправить эту проблему? Сервер, кажется, имеет много оперативной памяти, так что это не должно быть проблемой. Что еще это может быть?
Ответы:
Позвольте мне обобщить (и округлить!) Важные данные в вашей электронной таблице:
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527
Итак, первая строка показывает плохие вещи, занимающие около 2/3 кэша вашего плана (вещи, которые в большинстве случаев используются только один раз, за небольшим исключением). Вы должны попытаться избавиться от как можно большего количества из них. Второй ряд показывает хорошие вещи. Это те вещи, которые вы хотите в своем кэше планов (планы с большим количеством повторного использования). Остальные данные в значительной степени не имеют отношения к ИМХО. Еще один момент: вы говорите, что доступ осуществляется исключительно через хранимые процедуры, но если эти процедуры используют динамический SQL, эти операторы кэшируются как AdHocпланы, а не Procпланы.
В 2008 году или более я бы сказал, включите optimize for ad hoc workloadsи перейдите к следующей проблеме - это займет количество МБ, которое ваши планы одноразового использования в настоящее время занимают почти до нуля. К сожалению, в 2005 году ваши возможности весьма ограничены, за исключением рефакторинга этих хранимых процедур для использования уровня операторов OPTION (RECOMPILE)и / или уменьшения / отсутствия динамического SQL, или включения принудительной параметризации на уровне базы данных - что пытается улучшить планирование повторного использования из аналогичные запросы, рассматривая литералы как параметры для целей сопоставления планов. Я стесняюсь даже упоминать руководства по планам, потому что они не для робких и - как я расскажу позже в этом ответе - я не уверен, что стоит идти по этому пути, если вы не знаете, что кэш вашего плана определенно является источником вашей производительности вопрос.
Я спросил об этом, @@VERSIONпотому что до SP2 алгоритм для объема памяти, который мог быть выделен для кэша плана, был относительно слабым. Начиная с SP2 они немного ужесточились (изменение задокументировано и объяснено в этом и этом посте ). В вашем случае кэш плана относительно полон, поэтому неудивительно, что вы получаете ошибки в кеше. 26 ГБ = верхний предел 5,8 ГБ; Я вижу ~ 4,5 ГБ в электронной таблице, но здесь могут быть некоторые расчеты или различия в конфигурации, о которых я не знаю.
В этой статье MSDN рассказывается о optimize for ad hoc workloadsнастройке сервера, добавленной в 2008 году, и упоминается флаг трассировки 8032, который позволит вам выделить больше памяти для ваших кэшей (предположительно, при отсутствии установки этого параметра на уровне сервера, который я сейчас рекомендую всем наших клиентов, или, по крайней мере, 99%, которых больше нет в 2005 году). Я никогда не проверял этот флаг трассировки на 2005 SP3 или SP4, и, честно говоря, даже не уверен, когда он был введен. Я также не знаю, решит ли это вашу проблему или просто сместит ее, поскольку я думаю, что даже если бы у вас было на несколько% больше оперативной памяти, выделенной для кэшей, вы все равно бы заполнили ее и имели бы много пропусков кэша из-за природы ваши хранимые процедуры.
Или, конечно, если есть проблема, которая напрямую связана с кэшем плана. Тот факт, что ваш коэффициент попадания в кэш не так высок, как вы могли бы ожидать, не означает, что он вызывает вашу проблему, и, конечно, наоборот, даже при 100% коэффициенте попадания в кэш - что не кажется реалистичным, учитывая, что так много Ваши планы одноразовые и специальные - ваши пользователи все еще могут страдать от проблем с производительностью, вызванных чем-то совершенно другим.
Мое предложение состоит в том, чтобы искать лучшее оружие для курения, чем планировать коэффициент попадания в кэш. Получите более подробную информацию о жалобах пользователей на производительность. Все запросы всегда медленные? Определенные запросы? Определенное время дня / недели / делового цикла? Являются ли медленными только отчеты о запросах? Внимательно ознакомьтесь с этим, по общему мнению, сухим и длинным документом о лучших практиках SQL Server, в частности, разделе об ожиданиях и очередях, который может помочь вам сформулировать логический подход к выявлению, диагностике и решению проблем производительности. Улучшение внешнего вида некоторого числа на панели инструментов - число, о котором вы даже не подозреваете, напрямую способствует возникновению проблемы - может быть очень полезным, но если оно не решает проблемы производительности ваших пользователей, то оно на самом деле не помогло вам в любом месте.
Они также могут быть полезны при чтении при компиляции / перекомпиляции и планировании повторного использования кэша. Некоторые из них ориентированы на 2008 год (особенно те, которые касаются настройки специальных рабочих нагрузок), но большая часть информации все еще полезна для 2005 года и / или для лучшего понимания преимуществ обновления (подсказка, подсказка).