Устранить прерывистую проблему производительности из-за перехвата параметров - PullRequest
0 голосов
/ 11 февраля 2019

У меня есть процедура с проблемами производительности из-за перехвата параметров.Процедура является дорогостоящей, но обычно выполняется в приемлемое количество времени при обычной нагрузке.Тем не менее, он будет периодически работать плохо.Когда это происходит, мы видим, что сеансы, выполняющие процедуру, идут параллельно.Мы увидим количество сессий, выполняющих рутинное начало, чтобы накапливаться.Мы решаем эту проблему, извлекая план процедуры из кэша, убивая активные сеансы и отслеживая немедленное повторное возникновение (например, когда плохой план возвращается в кэш).

Процедура находится втипичная база данных OLTP (множество небольших запросов DML). Когда предметный запрос работает плохо, это вызывает скачок ЦП и снижает производительность соответствующей службы.В рабочее время процедура выполняется более 5 раз в минуту (точного подсчета нет).План этой процедуры приведен здесь:

https://www.brentozar.com/pastetheplan/?id=S1aEVQJBN

Все столбцы в запросе (объединяемые и прогнозируемые столбцы) покрыты индексами.

Вот параметрыЯ взвешиваю:

  1. Мы можем применить Option Recompile к проблемному оператору выбора внутри подпрограммы.
  2. Мы могли бы провести небольшое исследование и найти значение параметра, которое генерирует план, которыйкак правило, хорошо для "всего".Затем мы добавили бы следующую ОПТИМИЗАЦИЮ ДЛЯ функции.Это приведет к небольшому техническому долгу, так как нам может потребоваться скорректировать это значение со временем.
  3. Мы могли бы ввести логику ветвления в процедуру.Если бы значение параметра было X или в диапазоне-X, мы бы запустили sproc, а если нет, то запустили бы sproc.Опять же, возникает небольшая техническая задолженность.
  4. Мы можем изменить проблемный оператор на динамический SQL.Это приведет к созданию плана для каждого уникального оператора SQL.Если мы получим тонны уникальных вызовов этой процедуры, это может привести к переполнению кэша плана.
  5. Удар MAXDOP, равный "1", для проблемного оператора select.

Опции, которые я имеюс учетом:

  1. Мы можем оптимизировать для неизвестных.Это изменит оценки записи вектора плотности и оптимизирует операции для этого.

Я пропустил какие-либо разумные варианты?Какие варианты имеют больше смысла?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...