З того, що я можу сказати, процедура кеш-коефіцієнта хітів нижче 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 року та / або для кращого розуміння переваг оновлення (підказки, підказки).