Отслеживание ресурсов домена приложения

Статья
08/11/2011

Отслеживание ресурсов домена приложения (ARM) позволяет приложениям следить, как домен приложения использует ресурсы процессора и памяти. Это полезно для приложений, таких как ASP.NET, использующих большое количество приложений в длительном процессе. Ведущее приложение может выгрузить домен приложения, который неблагоприятно влияет на быстродействие всего процесса, но только если оно может определить проблемное приложение. ARM содержит сведения, которые можно использовать для принятия подобных решений.

Например, у размещенной службы может быть несколько приложений, выполняемых на сервере ASP.NET. Если одно из приложений процесса начинает потреблять слишком много ресурсов памяти или процессора, служба размещения может использовать ARM, чтобы определить домен приложения, ставший причиной проблемы.

ARM потребляет немного ресурсов и может использоваться в работающих приложениях. Собранные данные доступны с помощью журнала трассировки событий Windows (ETW) или напрямую с помощью управляемых и неуправляемых интерфейсов API.

Включение отслеживания ресурсов

ARM можно включить четырьмя способами: применяя конфигурационный файл при запуске среды CLR, с помощью неуправляемого интерфейса API размещения, используя управляемый код или прослушивая события ETW для ARM.

Сразу же после своего включения ARM начинает сбор данных для всех доменов приложений в процессе. Если домен приложения был создан до включения ARM, накопление данных начинается после включения ARM, а не при создании домена приложения. Включенный ARM отключить нельзя.

Можно включить ARM при запуске среды CLR, добавляя элемент <appDomainResourceMonitoring> в файл конфигурации и устанавливая для атрибута enabled значение true. Значение false (по умолчанию) означает только, что ARM не включается при запуске, его можно активировать позднее, используя один из других механизмов активации.
Ведущее приложение может включить ARM, запрашивая интерфейс размещения ICLRAppDomainResourceMonitor. После успешного получения этого интерфейса ARM оказывается включенным.
Чтобы включить ARM из управляемого кода, можно задать для статического (Shared в Visual Basic) свойства AppDomain.MonitoringIsEnabled значение true. ARM включается сразу же после задания этого свойства.
Можно включить ARM и после запуска, прослушивая события ETW. При включении открытого поставщика Microsoft-Windows-DotNETRuntime с помощью ключевого слова AppDomainResourceManagementKeyword ARM включается и начинает создавать события для всех доменов приложений. Чтобы связать данные с доменами приложений и потоками, также необходимо включить поставщик Microsoft-Windows-DotNETRuntimeRundown с ключевым словом ThreadingKeyword.

Использование ARM

ARM предоставляет данные о суммарном времени процессора, используемом доменом приложения, и три вида данных об использовании памяти.

Общее время процессора для домена приложения, в секундах: рассчитывается путем сложения времен потоков, сообщенных операционной системой, для всех потоков, выполнявшихся в домене приложения во время его существования. Блокированные или спящие потоки не используют время процессора. Когда поток вызывает неуправляемый код, время, в течение которого поток выполнял неуправляемый код, учитывается для домена приложения, из которого был выполнен вызов.
- Управляемый интерфейс API: свойство AppDomain.MonitoringTotalProcessorTime.
- Интерфейс API размещения: метод ICLRAppDomainResourceMonitor::GetCurrentCpuTime.
- События ETW: события ThreadCreated, ThreadAppDomainEnter и ThreadTerminated. Сведения о поставщиках и ключевых словах см. в подразделе, описывающем события отслеживания ресурсов домена приложения, в разделе События трассировки событий Windows в среде CLR.
Общие управляемые распределения, выполненные доменом распределения во время существования, в байтах: общие выделения не всегда отражают использование памяти доменом приложения, так как распределенные объекты могут быть короткоживущими. Но если приложение распределяет и освобождает большое количество объектов, стоимость распределений может быть значительной.
- Управляемый интерфейс API: свойство AppDomain.MonitoringTotalAllocatedMemorySize.
- Интерфейс API размещения: метод ICLRAppDomainResourceMonitor::GetCurrentAllocated.
- События ETW: событие AppDomainMemAllocated, поле Allocated.
Управляемая память, в байтах, на которую ссылается домен приложения и которая пережила последнюю полную блокирующую сборку мусора: это число оказывается точным только после полной блокирующей сборки. (Это отличается от параллельных сборок мусора, которые выполняются в фоновом режиме и не блокируют приложение.) Например, перегрузка метода GC.Collect() вызывает полную блокирующую сборку мусора.
- Управляемый интерфейс API: свойство AppDomain.MonitoringSurvivedMemorySize.
- Интерфейс API размещения: метод ICLRAppDomainResourceMonitor::GetCurrentSurvived, параметр pAppDomainBytesSurvived.
- События ETW: событие AppDomainMemSurvived, поле Survived.
Общая управляемая память, в байтах, на которую ссылается процесс и которая пережила последнюю полную блокирующую сборку мусора: с этим числом можно сравнить память, сохранившуюся в куче для отдельных доменов приложений.
- Управляемый интерфейс API: свойство AppDomain.MonitoringSurvivedProcessMemorySize.
- Интерфейс API размещения: метод ICLRAppDomainResourceMonitor::GetCurrentSurvived, параметр pTotalBytesSurvived.
- События ETW: событие AppDomainMemSurvived, поле ProcessSurvived.

Определение момента выполнения полной блокирующей сборки мусора

Чтобы определить, когда показатели счетчиков памяти, сохранившиеся в куче, являются точными, нужно знать о полной блокирующей сборке мусора, как только она происходит. Используемый для этого метод зависит от интерфейса API, применяемого для получения статистики ARM.

Управляемый интерфейс API

Если применяются свойства класса AppDomain, для регистрации уведомления о полных сборках мусора можно использовать метод GC.RegisterForFullGCNotification. Используемый порог неважен, так как ожидается завершение сборки мусора, а не ее наступления. Затем можно вызвать метод GC.WaitForFullGCComplete, выполняющий блокировку до завершения полной сборки мусора. Можно создать поток, вызывающий этот метод в цикле и выполняющий весь необходимый анализ после возвращения управления методом.

Либо можно периодически вызывать метод GC.CollectionCount, проверяя, не увеличился ли счетчик сборок мусора для поколения 2. В зависимости от частоты опроса этот метод может не обеспечивать точное указание выполнения полной сборки мусора.

Интерфейс API размещения

При использовании неуправляемого API размещения ведущее приложение должно передать среде CLR реализацию интерфейса IHostGCManager. Среда CLR вызывает метод IHostGCManager::SuspensionEnding при возобновлении выполнения потоков, приостановленных во время сборки мусора. Среда CLR передает поколение выполненной сборки мусора как параметр метода, чтобы ведущее приложение могло определить, является ли сборка полной или частичной. Созданная разработчиком реализация метода IHostGCManager::SuspensionEnding может запросить память, сохранившуюся в куче, чтобы гарантировать получение счетчиков сразу же после их обновления.