Reporting services service жрет память
Для наблюдения за производительностью сервера отчетов используются средства наблюдения за производительностью, позволяющие оценить активность сервера, наблюдать тренды, диагностировать узкие места системы и собирать данные, помогающие определить адекватность текущей конфигурации системы. Для настройки производительности сервера можно задать частоту очистки домена приложений сервера отчетов. Дополнительные сведения см. в разделе Настройка доступной памяти для приложений сервера отчетов.
События SharePoint
Кроме объектов производительности служб Службы Reporting Services , можно также настроить события SharePoint, если сервер отчетов запущен в режиме интеграции с SharePoint, а среда создания отчетов настроена для использования продукта SharePoint. В данном разделе используйте события для сервера отчетов в режиме интеграции с SharePoint для просмотра диагностических событий компонента, которые могут предоставить полезные сведения, в случае если среда подготовки отчетов интегрирована с SharePoint.
Другие счетчики производительности
Расчет памяти для некластеризованного, либо кластеризованного SQL Server работающего в режиме Актив/Пассив
- Остаток для ОС – 5%. В нашем случае это около 25 GB (500*5%).
- Память под ядро SQL Server (различные *.exe, *.dll, *ocx и пр. модули), SQL heap, CLR. Обычно это до 500 MB, хотя за счет CLR это может быть и больше.
- Память под кэши “Worker thread”, рассчитываемая по формуле (512+(NumCpu-4)*16)*2 MB. В нашем случае это (512+(64-4)*16)* 2MB = 2944 MB (около 2.7 GB).
- Итого под “max server memory” остается: 500 – 25 – 0.5 – 2.7 = 471.2 GB. Т.е. размер Буферного пула (при таком значении “max server memory”) может вырасти до 471 GB.
- Для версии SQL 2012 и далее “max server memory” включает в себя SQL heap и частично CLR.
Особенно актуален это расчет, если вы используете “Lock Pages In Memory” В этом случае завысив это число или оставив его по умолчанию (что обозначает – любой объем) вы можете поставить ОС в довольно неприятное положения, которое приведет к агрессивному триммированию рабочих наборов и, как следствие, резкому замедлению работы системы.
При расчете необходимо учитывать, что пункты 2, 3 и 4 должны быть удвоены, и при использовании права учетной записи SQL Server “Lock Pages In Memory”, вам необходимо подобрать не только “max server memory”, но и “min server memory”, что бы в случае переката обоих SQL Server на один узел вы не забрали всю память у ОС.
В данном случае на сервере установлено 500 GB оперативной памяти и 5% должно быть около 25 GB. Каким бы большим не казалось это число, но чем больше на сервере процессоров и памяти, тем (как правило) более ресурсоемкие задачи он выполняет и для их решения ему требуются большие ресурсы.
Как видно из рисунка (в данном случае), остаток памяти на сервере составляет около 7 GB, что не соответствует нашим рекомендациям.
Далее нам необходимо понять, имеет ли SQL Server достаточный запас памяти, часть которого можно освободить в пользу ОС. Для ответа на этот вопрос необходимо проанализировать счетчики производительности SQL Server.
Давайте сначала выясним сколько памяти потребил SQL Server. Для этого надо знать, использует или нет SQL Server право учетной записи SQL Server “Lock Page In Memory”, Выяснить это можно из свойств учетной записи, а можно косвенно, через счетчики Performance Monitor. Дело в том, что если право учетной записи SQL Server “Lock Page In Memory” не установлено, то вся (или почти вся) используемая память будет частью рабочего набора процесса sqlservr.exe. Если же это право установлено, то при этом (скрыто) используется механизм AWE (Address Windows Extension) и основная память под Буферный пул будет размещена за пределами процесса sqlservr.exe.
Как видно из рисунка ниже, размер рабочего набора процесса составляет всего около 4 GB, что значительно меньше общего объема потребленной памяти.
Посмотрим, сколько всего памяти использует SQL Server. Он использует 500 857 024 (около 480 GB) для распределения на Буферный пул, Процедурный кэш, кэш Worker Thread и для некоторых не значительных потребителей. А отсюда можно сделать вывод, что в данном случае SQL Server использует “Lock Pages in Memory”.
Далее приступим к поиску ответа на вопрос:”Можно ли отобрать часть памяти у SQL Server, не нанося ему вреда?”
Во первых, давайте проверим какое количество запросов обслуживается из Буферного пула (без выполнения физических чтений). Как мы видим из рисунка ниже по тексту около 100% (точнее 99,972%) запросов выполняются из буферного пула (при пороговом значении данного счетчика не менее 92%), что дает нам надежду на наличие избытка памяти у SQL Server.
Следующим счетчиком, который рекомендуется посмотреть является SQL Server: Page Life Expectancy. Он контролирует время жизни страниц в Буферном пуле. Пороговое значение 300 секунд. В данном случае мы видим среднее значение около 221000, что почти в 700 раз больше порогового. Это укрепляет нас в мысли, что ресурсы есть.
Окончательный ответ нам поможет дать счетчик SQL Server: Lazy Writes/sec, отображающий как часто срабатывает процесс Lazy Writer. Мы знаем, что это процесс активируется тогда, когда у SQL Server заняты около 75% выделенных буферов. Его задача выполнить фиксацию данных и очистить буферы. Для систем имеющих значительный запас памяти этот счетчик должен быть близок к нулю. Как мы видим это так.
Из всего вышесказанного можно сделать вывод: SQL Server имеет достаточный объем памяти и может “поделиться” ей с ОС. Отбирая память у SQL Server (уменьшая “max server memory”) необходимо контролировать выше описанные счетчики и определить тот порог, ниже которого уменьшать объем памяти нельзя.
Шаг 1. Убедитесь, что SQL Server загрузка ЦП приводит к высокой загрузке ЦП
Используйте одно из следующих средств, чтобы проверить, действительно ли SQL Server процесс влияет на высокую загрузку ЦП:
Диспетчер задач. На вкладке " Процесс" проверьте, близко ли значение столбца ЦП для SQL Server Windows NT-64 бита к 100 процентам.
Монитор производительности и ресурсов (perfmon)
- Счетчик: Process/%User Time , % Privileged Time
- Экземпляр: sqlservr
Для сбора данных счетчиков в течение 60 секунд можно использовать следующий сценарий PowerShell:
Если % User Time производительность постоянно превышает 90 процентов, SQL Server процесс приводит к высокой загрузке ЦП. Однако, если % Privileged time значение постоянно превышает 90 процентов, антивирусная программа, другие драйверы или другой компонент ОС на компьютере способствуют высокой загрузке ЦП. Чтобы проанализировать первопричину этого поведения, обратитесь к системному администратору.
Шаг 6. Изучение и устранение проблем с SARGability
Предикат в запросе считается SARGable (поиск с поддержкой ARGument), если SQL Server может использовать поиск индекса для ускорения выполнения запроса. Многие макеты запросов препятствуют sarGability и приводят к сканированию таблиц или индексов и высокой загрузке ЦП. Рассмотрим следующий запрос к базе данных AdventureWorks ProductNumber SUBSTRING() , где необходимо извлечь каждый из них и применить к ней функцию перед сравнением со строковым литеральным значением. Как видите, сначала необходимо получить все строки таблицы, а затем применить функцию, прежде чем можно будет выполнить сравнение. Выборка всех строк из таблицы означает сканирование таблицы или индекса, что приводит к более высокому использованию ЦП.
Применение любой функции или вычислений к столбцам в предикате поиска обычно делает запрос неуязвимым и приводит к более высокому потреблению ЦП. Решения обычно включают в себя перезапись запросов творческим способом, чтобы сделать SARGable. Возможным решением для этого примера является перезапись, при которой функция удаляется из предиката запроса, выполняется поиск в другом столбце и выполняются те же результаты:
Вот еще один пример, когда менеджеру по продажам может потребоваться предоставить 10 % комиссионных продаж по крупным заказам и узнать, какие заказы будут иметь комиссию больше 300 долларов США. Ниже приведен логический, но неуязвимый способ.
Ниже приведено возможное менее интуитивно понятное, но доступное для SARGable перезапись запроса, при котором вычисление перемещается на другую сторону предиката.
SARGability применяется не только к WHERE предложениям, но и к JOINs предложениям и HAVING предложениям GROUP BY ORDER BY . Частые случаи предотвращения SARGability CONVERT()``CAST() в запросах включают в себя функции, WHERE ISNULL()``COALESCE() JOIN используемые в предложениях или в предложениях, которые приводят к сканированию столбцов. В вариантах преобразования типов данных ( CONVERT или CAST ) решением может быть сравнение тех же типов данных. Ниже приведен пример, в котором T1.ProdID столбец INT явно преобразуется в тип данных в . JOIN Преобразование не позволяет использовать индекс в столбце соединения. Та же проблема возникает при неявном преобразовании, когда типы данных отличаются и SQL Server один из них для выполнения соединения.
Чтобы избежать сканирования T1 таблицы, ProdID можно изменить базовый тип данных столбца после надлежащего планирования и проектирования, а затем присоединить два столбца без использования функции преобразования ON T1.ProdID = T2.ProductID .
Другим решением является создание вычисляемого столбца T1 CONVERT() , в котором используется та же функция, а затем создание индекса на нем. Это позволит оптимизатору запросов использовать этот индекс без необходимости изменять запрос.
В некоторых случаях запросы нельзя легко переписать, чтобы обеспечить возможность SARGability. В таких случаях вы можете проверить, может ли вычисляемый столбец с индексом помочь или сохранить запрос так, как это было, с учетом того, что он может привести к более высоким сценариям ЦП.
Шаг 7. Отключение интенсивной трассировки
Проверьте наличие SQL трассировки или трассировки XEvent, которая влияет на производительность SQL Server и приводит к высокой загрузке ЦП. Например, использование следующих событий может привести к высокой загрузке ЦП при трассировке SQL Server активности:
- XML-события плана запроса ( query_plan_profile , query_post_compilation_showplan , query_post_execution_plan_profile , query_post_execution_showplan , query_pre_execution_showplan )
- События уровня инструкции ( sql_statement_completed , sql_statement_starting , sp_statement_starting , sp_statement_completed )
- События входа и входа ( login , process_login_finish , login_event , logout )
- События блокировки ( lock_acquired , lock_cancel , lock_released )
- События ожидания ( wait_info , wait_info_external )
- SQL аудита (в зависимости от группы, для SQL Server и действий в этой группе)
Выполните следующие запросы, чтобы определить активные трассировки XEvent или Server:
Шаг 10. Увеличение масштаба SQL Server
Если отдельные экземпляры запросов используют небольшую емкость ЦП, но общая рабочая нагрузка всех запросов вместе приводит к высокой загрузке ЦП, рассмотрите возможность масштабирования компьютера путем добавления дополнительных ЦП. Используйте следующий запрос, чтобы найти количество запросов, превышающих определенное пороговое значение среднего и максимального потребления ЦП на выполнение и которые выполняются много раз в системе (убедитесь, что значения двух переменных соответствуют вашей среде):
Первая – это установка соответствующего значения опции Recycle Time в конфигурационном файле для Reporting Services.
Этот конфигурационный файл находится в каталоге, в который был установлен SSRS, обычно это C:\Program Files\Microsoft SQL Server\MSRS12.MSSQLSERVER\Reporting Services\ReportServer\rsreportserver.config (для собственного режима) или
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\WebServices\Reporting\rsreportserver.config (для режима интеграции с SharePoint). Опция Recycle Time задает в минутах (значение по умолчанию 720) время очистки домена приложений, т.е. через сколько минут Reporting Services очистит ресурсы, выделенные для отчетов. Это значение может быть увеличено, чтобы позволить SSRS удерживать ресурсы на более длительный период для предотвращения замедления старта отчета из-за повторной инициализации ресурсов службы Reporting Services.
Рекомендую обратить внимание на этот параметр особенно в тех случаях, если у вас территориально распределенная организация и очистка домена приложений может негативно сказаться на работе филиалов.
Второе решение проблемы с задержками работы отчетов – это управление доступной для сервера отчетов памяти.
У большинства организаций Reporting Services устанавливается не на отдельный сервер, а вместе с какими-нибудь другими службами. В этом случае в течении рабочего дня пока Reporting Services загружен ему выделяется достаточно памяти. Но как только наступает время простоя (например, ночью) операционная система может отобрать у сервера отчетов ресурсы. Решить эту проблему можно добавлением оперативной памяти, но не всегда это возможно. Другим решением может быть настройка периодического выполнения какого-нибудь отчета, чтобы сервер отчетов не простаивал. Но лучше всего провести настройку минимального значения используемого объема оперативной памяти.
Указанная опция называется WorkingSetMinimum, задается в килобайтах и не включена по-умолчанию в конфигурационный файл. Для определения необходимого значения рекомендуется понаблюдать за процессом Reporting Services (ReportingServicesService.exe).
В приведенном примере ReportingServicesService.exe использует 46,772Kb оперативной памяти. Мы можем округлить это значение до 50,000Kb и добавить соответствующий параметр в конфигурационном файле
Но не забывайте, что такая принудительная выемка оперативной памяти из работы может негативно сказаться на других приложениях/службах, работающих на этом сервере, при большом объёме задействованной памяти. Проводите периодический мониторинг производительности.
Ссылка на наш канал YouTube
Рекомендуем ознакомиться с другими темами по SQL Server Reporting Services тут
Перечень наиболее часто встречающихся проблем связанных с памятью:
- SQL Server “съел” всю память (или очень много), что начало “угнетать” ОС и приложения работающие на ней.
- Вы установили ограничения на память потребляемую SQL Server и ему стало не хватать выделенной памяти.
- Какое-либо приложение потребило слишком много памяти и SQL Server-у стало не хватать выделенной памяти
- “Перекос” в потреблении памяти каким-либо компонентом SQL Server, что стало причиной “угнетения” других компонентов SQL Server.
Первые три причины называются внешним “нажимом” на память и методика их анализа почти одинакова. Третья же причина называется “внутренним” нажимом на память и методики ее анализа совершенно другие.
Итак начнем рассмотрение первой причины – “SQL Server “съел” всю (или очень много) память, что начало угнетать ОС и приложения работающие на ней.”
В качестве ограничения накладываемого на рассмотрение – в блоге мы будем рассматривать только 64-битовую версию SQL Server и ОС, поскольку 32-битовых остается все меньше и меньше.
Для начала надо установить факт, что ОС действительно не хватает памяти и эту память потребил SQL Server. Выполнить это можно посмотрев счетчик Memory: Available Bytes. Он показывает сколько памяти осталось у ОС для распределения приложениям и внутреннего использования. Возникает справедливый вопрос:”Каким образом приложение может потребить много памяти и угнетать ОС?”. Причин тому может быть несколько:
- Утечка памяти в приложении или драйвере, особенно утечка невыгружаемого пула.
- Установка завышенного значения параметра “max server memory” в свойствах SQL Server и права “Lock Pages in Memory” для учетной записи от которой работает SQL Server.
У нас (Microsoft) есть принятая норма на остаток памяти который должен оставаться доступным для распределения ОС. Эта норма составляет 5% от объема установленного RAM, т.е. в свободном распределении у ОС должно остаться не менее 5% от общего объема RAM установленного на сервере. И как бы это число не казалось большим (особенно при больших объемах установленной памяти), лучше этого правила придерживаться.
Что будет предпринимать ОС, когда приложения потребят слишком много оперативной памяти? При достижении порога Memory: Available Bytes в 100…50 MB Windows включит агрессивный сброс (trimming) рабочих наборов процессов, включая системные драйверы, что тут же приведет к резкому снижению производительности всех компонентов ОС. В данной статье мы не будем рассматривать эти вопросы, возможно мы рассмотрим их в будущем.
Каким образом рассчитать правильное значение “max server memory”?
Здесь есть два случая:
- Некластеризованный SQL Server, либо кластеризованный SQL Server в режиме Актив/Пассив .
- Кластеризованный SQL Server работающий в режиме Актив/Актив.
В этом разделе
Хотя службы Службы Reporting Services могут использовать всю доступную память, можно переопределить поведение по умолчанию, настроив верхний предел ресурсов памяти, выделяемых серверным приложениям служб Службы Reporting Services . Можно также задать пороговые значения, которые изменяют способ назначения приоритета и обработки запросов сервером отчетов в зависимости от дефицита свободной памяти. При малом дефиците свободной памяти сервер отчетов назначает чуть более высокий приоритет интерактивной обработке отчетов или обработке отчетов по запросу. При серьезном дефиците свободной памяти сервер отчетов использует многочисленные приемы, чтобы сохранить работоспособность в условиях ограниченных доступных ресурсов.
В этой статье описаны настраиваемые пользователем параметры конфигурации и реакция сервера в случаях, когда при обработке запросов нужно учитывать недостаток свободной памяти.
Шаг 9. Настройка виртуальной машины
Если вы используете виртуальную машину, убедитесь, что вы не перепроизводите ЦП и что они настроены правильно. Дополнительные сведения см. в статье об устранении неполадок с производительностью виртуальных машин ESX и ESXi (2001003).
Шаг 8. Устранение SOS_CACHESTORE спин-блокировки
Если в экземпляре SQL Server SOS_CACHESTORE происходит интенсивное состязание за спин-блокировку или вы заметили, что планы запросов часто удаляются в незапланированных рабочих нагрузках запросов, T174 DBCC TRACEON (174, -1) просмотрите следующую статью и включите флаг трассировки с помощью команды:
Исправление. SOS_CACHESTORE спин-блокировок в кэше нерегламентированного SQL Server планов приводит к высокой загрузке ЦП в SQL Server.
Если условие высокой загрузки ЦП разрешается с помощью, T174 включите его в качестве параметра запуска с помощью диспетчер конфигурации SQL Server.
Высокая загрузка ЦП может возникать из-за конфликтов спин-блокировок во многих других типах спин-блокировок, SOS_CACHESTORE но обычно сообщается о них. Дополнительные сведения о спин-блокировках см. в разделе "Диагностика и устранение конфликтов спин-блокировок на SQL Server
Параметры конфигурации для управления памятью
Параметры конфигурации, которые управляют распределением памяти для сервера отчетов — WorkingSetMaximum, WorkingSetMinimum, MemorySafetyMarginи MemoryThreshold.
ПараметрыWorkingSetMaximum и WorkingSetMinimum определяют область доступной памяти. Настраивая эти параметры, можно установить область доступной памяти для приложений сервера отчетов. Это полезно, если несколько приложений размещаются на одном компьютере, и известно, что сервер отчетов использует непропорциональное количество системных ресурсов по сравнению с другими приложениями на том же компьютере.
ПараметрыMemorySafetyMargin и MemoryThreshold указывают границы низкого, среднего и высокого уровней нехватки свободной памяти. Для каждого состояния службы Службы Reporting Services предпринимают действие по исправлению, чтобы обработка отчетов и другие запросы выполнялись в соответствии с объемом памяти, доступной на компьютере. Можно указать параметры конфигурации, которые определяют разграничение между низким, средним и высоким уровнями нехватки свободной памяти.
Параметры конфигурации можно изменить, но это не улучшит производительность при обработке отчетов. Изменение параметров конфигурации полезно, только если запросы теряются прежде, чем будут завершены. Лучший способ повысить производительность сервера — развернуть сервер отчетов или его отдельные приложения на разных компьютерах.
На следующей иллюстрации показано, как параметры используются совместно, чтобы различить низкий, средний и высокий уровни нехватки свободной памяти:
В следующей таблице приведены описания параметров WorkingSetMaximum, WorkingSetMinimum, MemorySafetyMarginи MemoryThreshold . Параметры конфигурации задаются в файле RSReportServer.config.
По умолчанию сервер отчетов устанавливает значение WorkingSetMaximum равным объему доступной памяти в компьютере. Это значение обнаруживается при запуске службы.
Этот параметр не появляется в файле конфигурации RSReportServer.config, если не добавить его вручную. Чтобы сервер отчетов использовал меньше памяти, можно изменить файл RSReportServer.config, добавив элемент и значение. Диапазон допустимых значений — от 0 до максимального целого числа. Значение указывается в килобайтах.
При достижении значения WorkingSetMaximum сервер отчетов прекращает принимать новые запросы. Обрабатываемые в это время запросы продолжают выполняться. Новые запросы принимаются лишь после того, как объем использованной памяти станет меньше значения, указанного параметром WorkingSetMaximum.
Его значение по умолчанию рассчитывается при запуске службы. В соответствии с этим расчетом, запрашиваемый объем выделенной памяти составляет 60 процентов от WorkingSetMaximum.
ПараметрыMemoryLimit и MaximumMemoryLimit в SQL Server 2008 и более поздних версиях. Если обновить существующую установку или использовать файл RSReportServer.config с этими значениями, то сервер отчетов не будет их считывать.
Пример параметров конфигурации памяти
Следующий пример показывает параметры конфигурации для компьютера серверов отчетов, в котором используются пользовательские значения конфигурации памяти. Чтобы добавить параметр WorkingSetMaximum или WorkingSetMinimum, необходимо вставить соответствующие элементы и значения в файл RSReportServer.config. Оба значения представляют собой целые числа, указывающие объем ОЗУ в килобайтах, выделяемый для серверных приложений. В следующем примере указывается, что общая память, выделенная для приложений сервера отчетов, не может превышать 4 гигабайт. Если значение параметра WorkingSetMinimum по умолчанию (60 % от значения WorkingSetMaximum) приемлемо, его можно опустить и задать в файле RSReportServer.config только параметр WorkingSetMaximum . Пример содержит параметр WorkingSetMinimum , чтобы показать, как выглядит этот параметр, если понадобится его добавить:
В этой статье приведены процедуры диагностики и устранения проблем, вызванных высокой загрузкой ЦП на компьютере, на котором выполняется Microsoft SQL Server. Хотя существует множество возможных причин высокой загрузки ЦП, которые возникают в SQL Server, наиболее распространенными причинами являются следующие:
- Высокие логические операции чтения, вызванные сканированием таблицы или индекса из-за следующих условий:
- Устарелая статистика
- Отсутствующие индексы
- Плохо спроектированные запросы
Чтобы устранить проблемы с высокой загрузкой ЦП в SQL Server, выполните следующие действия.
Объекты производительности служб Reporting Services
Службы SQL Server 2016 Reporting Services включают следующие объекты производительности.
MSRS 2016 Web Service и MSRS 2016 Web Service SharePoint Mode для наблюдения за производительностью сервера отчетов. Эти объекты производительности включают коллекцию счетчиков, используемых для отслеживания работы сервера отчетов, обычно инициируемой интерактивными операциями просмотра отчетов. Эти счетчики сбрасываются, когда веб-служба сервера отчетов останавливается или перезапускается.
MSRS 2016 Windows Service и MSRS 2016 Windows Service SharePoint Mode для наблюдения за проводимыми по расписанию операциями и доставкой отчетов. Эти объекты производительности включают коллекцию счетчиков, используемых для отслеживания обработки отчетов, обычно инициируемой операциями по расписанию. Назначенные операции включают подписку и доставку, создание снимков состояния выполнения отчетов, а также ведение журнала отчетов.
Если на одном компьютере имеется несколько экземпляров сервера отчетов, их можно контролировать вместе или по отдельности. При добавлении счетчика необходимо выбрать включаемые в него экземпляры. Дополнительные сведения об использовании Монитора производительности (perfmon.msc) и добавлении счетчиков см. в документации по продукту Монитор производительности Microsoft Windows.
Когда следует настраивать параметры управления памятью
Параметры по умолчанию указывают неравные области для низкой, средней и высокой нехватки свободной памяти. По умолчанию область низкой нехватки свободной памяти больше, чем зоны средней и высокой нехватки свободной памяти. Такая конфигурация оптимальна для нагрузки, которая распределена равномерно, либо увеличивается или сокращается постепенно. В этом случае переход между зонами совершается постепенно, и у сервера отчетов есть время скорректировать реакцию.
Если нагрузка изменяется скачками, то полезно изменить параметры по умолчанию. Если нагрузка изменяется внезапными скачками, то сервер отчетов может очень быстро перейти от состояния без недостатка свободной памяти к отказам выделения памяти. Это может произойти, если имеется несколько экземпляров отчетов, требующих много памяти и запускаемых одновременно. Для обработки нагрузки такого типа рекомендуется как можно скорее перевести сервер отчетов в область средней или высокой нехватки памяти, чтобы замедлить обработку. Это позволит завершить больше запросов. Для этого нужно уменьшить значение для MemorySafetyMargin , чтобы уменьшить область низкой нехватки памяти относительно других областей. В результате реакция на среднюю и высокую нехватку памяти будет происходить раньше.
Шаг 2. Определение запросов, влияющих на использование ЦП
Sqlservr.exe Если этот процесс приводит к высокой загрузке ЦП, наиболее распространенной причиной являются запросы SQL Server, которые выполняют сканирование таблицы или индекса, за которыми следует сортировка, хэш-операции и циклы (оператор вложенного цикла или WHILE (T-SQL)). Чтобы получить представление о том, какой объем ЦП в настоящее время используются запросами из общей емкости ЦП, выполните следующую инструкцию:
Чтобы определить запросы, отвечающие за высокую активность ЦП, выполните следующую инструкцию:
Если в настоящее время запросы не управляют ЦП, но произошла высокая загрузка ЦП, можно выполнить следующую инструкцию, чтобы найти исторические запросы с привязкой к ЦП:
Источники данных о производительности
Для получения всеобъемлющих сведений о работе системы используется комбинация определенных технологий и средств. Microsoft Windows Server предоставляют сведения о производительности с помощью следующих средств:
Средство просмотра событий
Диспетчер задач предоставляет сведения о программах и процессах, выполняющихся на компьютере. Диспетчер задач можно использовать для контроля ключевых показателей производительности сервера отчетов. Можно также получить доступ к параметрам активности выполняющихся процессов и просматривать данные и графики использования ЦП и памяти. Дополнительные сведения об использовании диспетчера задач см. в документации по продукту Microsoft Windows.
Средство просмотра событий и Монитор производительности можно использовать для создания журналов и предупреждений об обработке отчетов и потреблении ресурсов. Сведения о событиях Windows, формируемых службами Службы Reporting Services, см. в разделе Журнал приложений Windows. Дополнительные сведения о Мониторе производительности см. в разделе "Счетчики производительности Windows" далее в этой статье.
Служебные программы SQL Server, такие как SQL Server Profiler и Расширенные события, предоставляют также сведения о базе данных сервера отчетов и временных базах данных, используемых для кэширования и управления сеансами.
Политики управления памятью
Службы Reporting Services изменяют объем памяти, выделяемый определенным приложениям и типы обработки запросов. Приложения, которые выполняются в службе сервера отчетов и участвуют в управлении памятью.
Веб-портал, клиентский веб-интерфейс для сервера отчетов.
Веб-служба сервера отчетов, используемая для интерактивной обработки отчетов и запросов по требованию.
Приложение фоновой обработки, используемое для обработки отчетов по расписанию, доставки подписок и обслуживания баз данных.
Политики управления памятью применяются к службе сервера отчетов в целом, а не к отдельным приложениям, выполняемым внутри процесса.
Если недостатка памяти нет, то каждое серверное приложение запрашивает некоторый объем памяти при запуске, не дожидаясь получения запросов, чтобы обеспечить оптимальную производительность, когда запросы будут, наконец, получены. По мере возникновения недостатка памяти, сервер отчетов корректирует модель процесса, как описано в следующей таблице.
Нельзя настроить реакцию сервера отчетов для различных сценариев нехватки свободной памяти, но можно назначить параметры конфигурации, которые определяют границы, разделяющие реакцию на высокий, средний и низкий недостаток свободной памяти.
Шаг 3. Обновление статистики
Определив запросы с наибольшим потреблением ЦП , обновите статистику таблиц, используемых этими запросами. Системную хранимую sp_updatestats процедуру можно использовать для обновления статистики всех определяемых пользователем и внутренних таблиц в текущей базе данных. Например.
Системная sp_updatestats хранимая процедура выполняется UPDATE STATISTICS для всех пользовательских и внутренних таблиц в текущей базе данных. Для регулярного обслуживания убедитесь, что регулярное планирование обслуживания обновляет статистику. Используйте такие решения, как " Дефрагментация адаптивного индекса", для автоматического управления дефрагментативной индекса и обновлениями статистики для одной или нескольких баз данных. Эта процедура автоматически выбирает, следует ли перестраивать или реорганизовать индекс в соответствии с уровнем фрагментации, помимо других параметров, и обновлять статистику с помощью линейного порогового значения.
Дополнительные сведения см sp_updatestats . в sp_updatestats.
Если SQL Server по-прежнему использует чрезмерную емкость ЦП, перейдите к следующему шагу.
Счетчики производительности Windows
Контроль конкретных счетчиков производительности позволяет:
оценить системные требования, необходимые для поддержки предполагаемой рабочей нагрузки;
определить базовый уровень производительности для оценки влияния изменений конфигурации или обновлений приложений;
контролировать производительность приложений при определенных нагрузках, естественных или искусственных;
убедиться в том, что обновление оборудования оказывает необходимое влияние на производительность;
убедиться в том, что изменения конфигурации системы оказывают необходимое влияние на производительность.
Шаг 5. Изучение и устранение проблем, чувствительных к параметрам
Используйте команду DBCC FREEPROCCACHE , чтобы проверить, устранена ли проблема с высокой загрузкой ЦП.
Если проблема по-прежнему существует, RECOMPILE можно добавить указание запроса к каждому из запросов с высокой загрузкой ЦП, которые определены на шаге 2.
Если проблема устранена, это указывает на проблему с учетом параметров (PSP, также известная как "проблема с сканированием параметров"). Чтобы устранить проблемы, чувствительные к параметрам, используйте следующие методы. Каждый метод имеет связанные компромиссы и недостатки.
Используйте указание запроса RECOMPILE для каждого выполнения запроса. Это указание помогает сбалансировать небольшое увеличение загрузки ЦП компиляции с более оптимальной производительностью при каждом выполнении запроса. Дополнительные сведения см. в разделах "Параметры" и "Повторное использование плана выполнения", " Конфиденциальность параметров" и "Указание запроса RECOMPILE".
Ниже приведен пример применения этого указания к запросу.
Используйте указание запроса OPTIMIZE FOR , чтобы переопределить фактическое значение параметра, используя типичное значение параметра, достаточное для большинства возможных значений параметров. Этот параметр требует полного понимания оптимальных значений параметров и связанных характеристик плана. Ниже приведен пример использования этого указания в запросе.
Используйте указание запроса OPTIMIZE FOR UNKNOWN , чтобы переопределить фактическое значение параметра средой вектора плотности. Это также можно сделать, захватив значения входящих параметров в локальных переменных, а затем используя локальные переменные в предикатах вместо использования самих параметров. Для этого исправления средняя плотность должна быть достаточно высокой.
Используйте DISABLE_PARAMETER_SNIFFING запроса, чтобы полностью отключить сканирование параметров. Ниже приведен пример использования в запросе.
Используйте указание запроса KEEPFIXED PLAN , чтобы предотвратить повторную компиляцию в кэше. Это решение предполагает, что общий план "достаточно хороший" — это план, который уже находится в кэше. Вы также можете отключить автоматическое обновление статистики, чтобы снизить вероятность вытеснения хорошего плана и компиляции нового неверного плана.
Используйте команду DBCC FREEPROCCACHE в качестве временного решения, пока код приложения не будет исправлен. С помощью этой команды DBCC FREEPROCCACHE (plan_handle) можно удалить только план, который вызывает проблему. Например, чтобы найти планы запросов Person.Person , ссылающееся на таблицу в AdventureWorks, этот запрос можно использовать для поиска дескриптора запроса. Затем можно освободить определенный план запроса из кэша DBCC FREEPROCCACHE (plan_handle) , используя созданный во втором столбце результатов запроса.
Шаг 4. Добавление отсутствующих индексов
Выполните следующий запрос, чтобы определить запросы, которые приводят к высокой загрузке ЦП и содержат по крайней мере один отсутствующий индекс в плане запроса:
Просмотрите планы выполнения для идентифицированных запросов и настройте запрос, внося необходимые изменения. На следующем снимке экрана показан пример, в котором SQL Server будет указывать на отсутствующий индекс для запроса. Щелкните правой кнопкой мыши часть "Отсутствующий индекс" в плане запроса, а затем выберите "Отсутствующие сведения об индексе", чтобы создать индекс в другом окне SQL Server Management Studio.
Используйте следующий запрос, чтобы проверить отсутствие индексов и применить все рекомендуемые индексы с высокими значениями мер улучшения. Начните с 5 или 10 рекомендаций из выходных данных с наибольшим improvement_measure значения. Эти индексы имеют наиболее значительное положительное влияние на производительность. Решите, следует ли применять эти индексы, и убедитесь, что для приложения выполнено тестирование производительности. Затем продолжайте применять рекомендации по отсутствующим индексам, пока не дойдет желаемых результатов производительности приложения. Дополнительные сведения об этом разделе см. в разделе "Настройка некластеризованных индексов с отсутствующим предложением индекса".
Читайте также: