Использование отчетов для анализа производительности
Изменения: 17 июля 2006 г.
При анализе производительности служб Microsoft SQL Server Notification Services начните с определения производительности экземпляра и его приложений. Чтобы получить эти сведения, используйте отчет о моментальных снимках приложений и административные отчеты.
- Отчет о моментальных снимках приложений создается хранимой процедурой NSSnapshotApplications (Transact-SQL). Например, этот отчет можно использовать для определения отставания генератора от расписания или определения удаления данных процессом очистки.
- Административный отчет создается хранимой процедурой NSAdministrationHistory (Transact-SQL). Например, этот отчет можно использовать для определения неудачно обработанных пакетов уведомлений.
Эти отчеты помогают определить, функционируют ли приложения ожидаемым образом. Если это не так, то используйте нижеприведенную методологию для анализа низкой производительности.
Анализ низкой производительности
Анализ приложений служб Notification Services начинается с такта генератора. Генератор является основой служб Notification Services и, когда запущен экземпляр, генератор должен срабатывать через регулярный интервал времени, называемый тактом. Продолжительность такта задается в файле определения приложения (ADF). Генератор использует длительность такта для определения частоты обработки правил, определенных в ADF.
При анализе проблем с производительностью обычно осуществляется поиск тактовых периодов, не завершившихся надлежащим образом, а затем определяется, что произошло во время этих тактов. Используйте следующую методологию для поиска тактов для анализа, получения подробных сведений об этих тактах и последующего анализа подробных сведений об экземпляре и приложениях.
Дополнительные сведения о длительности тактов см. в разделе Архитектура обработки подписок и Указание длительности такта генератора.
Шаг 1. Определение интересующего такта
Первым шагом в анализе приложения служб Notification Services является идентификация набора нужных тактовых периодов. Тактовый период, относящийся к низкой производительности, обычно имеет одну из следующих характеристик.
- Такт выполняется дольше, чем ожидается. Это может быть вызвано несколькими факторами, и необходимо провести дальнейший анализ приложения для определения причины.
- Такт отмечен как завершившийся сбоем. Сбои тактовых периодов могут возникать по нескольким причинам, например из-за неправильного выполнения правила.
- Такт был пропущен. Чтобы генератор всегда обрабатывал текущие данные, можно настроить, чтобы он, при необходимости, пропускал тактовые периоды. Пропущенные такты обычно являются побочным эффектом долго выполняющихся тактовых периодов.
Чтобы облегчить идентификацию длительно выполняющихся, закончившихся сбоем или пропущенных тактовых периодов, службы Notification Services предоставляют отчеты о производительности тактов, времени выполнения тактов, сбоях тактов и пропущенных тактах.
- Отчет о производительности тактов распределяет такты по категориям в соответствии со временем их выполнения. Это может помочь определить общую длительность выполнения тактов. Этот отчет создается хранимой процедурой NSQuantumPerformance (Transact-SQL).
- Отчет о времени выполнения тактов содержит такты, которые выполняются дольше заданного времени. Используя идентификаторы тактов, можно затем более подробно проанализировать такты. Этот отчет создается хранимой процедурой NSQuantumExecutionTime (Transact-SQL).
- Отчет о сбоях тактов содержит сведения о сбоях тактов генератора. Сбой такта возникает, если такт не может завершить требуемую обработку, например обработку правил. Этот отчет создается хранимой процедурой Хранимая процедура NSQuantumFailures (Transact-SQL).
- Отчет о пропущенных тактах содержит сведения о пропущенных тактах генератора. Такты могут быть пропущены при отставании генератора и если в ADF установлены пределы тактовой задержки. Этот отчет создается хранимой процедурой NSQuantumsSkipped (Transact-SQL).
Сценарий: используя хранимую процедуру NSQuantumPerformance, можно определить, что такт 188 выполнялся в два раза дольше всех остальных тактов. Следующим шагом является определение того, что произошло во время этого такта.
Шаг 2. Анализ подробных сведений о такте
После идентификации интересующего такта определите, что произошло на его протяжении. Чтобы получить подробные сведения о такте, используйте подробный и списочный отчет о такте.
- Подробный отчет о такте содержит подробные сведения о заданном такте. Этот отчет используется для устранения неполадок тактов, выполняющихся в течение длительного времени и для анализа обработки тактов. Этот отчет создается хранимой процедурой NSQuantumDetails (Transact-SQL).
- Списочный отчет о такте содержит сведения о тактах, обработанных в течение заданного периода времени, и отображает такты в порядке их выполнения. Этот отчет создается хранимой процедурой NSQuantumList (Transact-SQL).
Сценарий: в продолжение сценария, представленного в шаге 1 выше, запущена хранимая процедура NSQuantumDetails для такта 188. В соответствии с отчетом обнаружено, что обработка одного из правил заняла 90 процентов времени такта. Следующим шагом является анализ пакетов событий и уведомлений для этого и других тактов. С использованием этого отчета отмечено, что пакет событий 60 и пакет уведомлений 40 были обработаны в течение этого такта.
Шаг 3. Анализ подробных данных о приложении
После анализа тактового периода может появиться необходимость обратить внимание на конкретные события, подписки или уведомления в пределах такта. Подробный отчет о пакете событий, подробный отчет о плановых подписках и подробный отчет о пакете уведомлений содержат подробные сведения о данных приложения.
- Подробный отчет о пакете событий содержит сведения о конкретном пакете событий для класса событий. В этом отчете показаны сводные данные о пакете событий, а затем сведения о каждом событии в пакете. Этот отчет создается хранимой процедурой NSEventBatchDetails (Transact-SQL). Используйте хранимую процедуру NSEventBatchList (Transact-SQL) для получения идентификаторов пакета событий.
- Подробный отчет о плановых подписках содержит данные обо всех подписках в классе подписки. Этот отчет создается хранимой процедурой NSScheduledSubscriptionDetails (Transact-SQL).
- При использовании условных действий отчет об условиях подписки возвращает запрос, используемый для оценки подписки на основе условия. Этот отчет создается хранимой процедурой NSSubscriptionConditionInformation (Transact-SQL).
- Подробный отчет о пакете уведомлений содержит данные о конкретном пакете уведомлений для класса уведомлений. В этом отчете показаны сводные данные о пакете уведомлений, а затем сведения о каждом уведомлении в пакете. Этот отчет создается хранимой процедурой NSNotificationBatchDetails (Transact-SQL). Используйте хранимую процедуру NSNotificationBatchList (Transact-SQL) для получения идентификаторов пакета уведомлений.
- Можно также использовать любой из диагностических отчетов или отчетово моментальных снимках для анализа приложений на различных уровнях детализации.
Сценарий: для завершения анализа такта 188 вначале запустите хранимую процедуру NSEventBatchDetails для пакета событий 60 и обратите внимание, что в течение этого такта было собрано большое количество событий. С использованием хранимой процедуры NSDiagnosticEventClass определите, что этот пакет событий содержит значительно больше событий, чем большинство классов событий, что означает, что выполнение этого такта в течение более длительного, чем обычно, периода времени не указывает на проблему с приложением. Однако для повышения производительности может потребоваться оптимизация приложения, например путем оптимизации запросов и добавления индексов.
См. также
Основные понятия
Отчеты о производительности служб Notification Services
Мониторинг производительности и активности служб Notification Services