Сбор дампов памяти на платформе Службы приложений Azure

В этой статье содержатся рекомендации по функциям отладки Службы приложений Microsoft Azure для записи дампов памяти. Используемый метод отслеживания определяется сценарием, в котором выполняется сбор дампа памяти для устранения проблем с производительностью или доступностью. Например, запись дампа памяти отличается для процесса, который испытывает чрезмерное потребление памяти, чем для процесса, который создает исключения или медленно реагирует. Процесс в этом контексте представляет собой рабочий процесс служб IIS (W3WP, который выполняется какw3wp.exe).

Сопоставление сценариев дампа памяти с функциями отладки Службы приложений Azure

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

Описания расширенных сценариев процесса

В этом разделе содержатся подробные описания шести сценариев, показанных в предыдущей таблице.

Сценарий без ответа или медленный

При выполнении запроса к веб-серверу обычно необходимо выполнить некоторый код. Выполнение кода выполняется в рамках процессаw3wp.exe в потоках. Каждый поток имеет стек, показывающий, что в настоящее время выполняется.

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

Сценарий сбоя (завершение процесса)

На протяжении многих лет Microsoft .NET Framework улучшила обработку исключений. В текущей версии .NET процесс обработки исключений еще лучше.

Исторически сложилось так, что если разработчик не помещал фрагменты кода в блок try-catch и вызывалось исключение, процесс завершался. В этом случае необработанное исключение в коде разработчика завершило процесс. Более современные версии .NET обрабатывают некоторые из этих необработанных исключений, чтобы процесс, выполняющий код, не сбой. Однако не все необработаемые исключения создаются непосредственно из пользовательского кода. Например, нарушения доступа (такие как 0xC0000005 и 0x80070005) или переполнение стека могут завершить процесс.

Сценарий сбоя (обрабатываемые исключения)

Хотя разработчик программного обеспечения особенно тщательно определяет все возможные сценарии, в которых выполняется код, может произойти что-то непредвиденное. Исключение могут вызвать следующие ошибки:

• Непредвиденные значения NULL
• Недопустимое приведение
• Отсутствующий экземпляр объекта

Рекомендуется поместить выполнение кода в блоки кода try-catch. Если разработчик использует эти блоки, код имеет возможность корректно завершить сбой, специально управляя тем, что следует за непредвиденным событием. Обработанное исключение — это исключение, которое создается внутри блока try и попадает в соответствующий блок catch. В этом случае разработчик ожидал, что может возникнуть исключение, и закодировал соответствующий блок try-catch вокруг этого раздела кода.

В блоке catch полезно записать достаточно информации в источник ведения журнала, чтобы можно было воспроизвести проблему и в конечном итоге устранить ее. Исключения — это дорогие пути к коду с точки зрения производительности. Таким образом, наличие множества исключений влияет на производительность.

Сценарий сбоя (необработанных исключений)

Необработанных исключений возникают, когда код пытается выполнить действие, которое не ожидается. Как и в сценарии сбоя (завершение процесса), этот код не содержится в блоке кода try-catch. В этом случае разработчик не ожидал, что в этом разделе кода может возникнуть исключение.

Этот сценарий отличается от двух предыдущих сценариев исключений. В сценарии сбоя (необработанных исключений) рассматриваемый код является кодом, написанным разработчиком. Это не код платформы, который создает исключение, и это не одно из необработанных исключений, которое убивает процессw3wp.exe . Кроме того, так как код, который вызывает исключение, не находится в блоке try-catch, нет возможности корректно обработать исключение. Устранение неполадок кода изначально немного сложнее. Ваша цель — найти текст, тип и стек исключений, определяющий метод, который вызывает это необработанное исключение. Эти сведения позволяют определить, куда нужно добавить блок кода try-catch. Затем разработчик может добавить аналогичную логику в сведения об исключении журнала, которые должны существовать в сценарии аварийного завершения (необработанных исключений).

Сценарий чрезмерного использования ЦП

Что такое чрезмерная загрузка ЦП? Эта ситуация зависит от того, что делает код. Как правило, если загрузка ЦП в процессеw3wp.exe составляет 80 %, приложение находится в критической ситуации, которая может вызвать различные симптомы. Некоторые возможные симптомы:

• Медлительность
• Ошибки
• Другое неопределенное поведение

Даже 20-процентное использование ЦП может считаться чрезмерным, если веб-сайт просто предоставляет статические HTML-файлы. Устранение неполадок при чрезмерном пике загрузки ЦП путем создания дампа памяти, вероятно, не поможет определить конкретный метод, который его использует. Лучше всего определить, какие запросы, скорее всего, занимают больше всего времени, а затем попытаться воспроизвести проблему, проверив обнаруженный метод. В этой процедуре предполагается, что мониторы производительности не запускаются в системах производительности, которые фиксируют этот всплеск. Во многих случаях вы можете вызвать проблемы с производительностью, постоянно выполняя мониторы в режиме реального времени.

Сценарий чрезмерного потребления памяти

Если приложение выполняется в 32-разрядном процессе, может возникнуть проблема с чрезмерным потреблением памяти. Даже небольшое количество действий может потреблять 2–3 ГБ выделенного виртуального адресного пространства. 32-разрядный процесс никогда не может превышать 4 ГБ, независимо от объема доступной физической памяти.

64-разрядный процесс выделяет больше памяти, чем 32-разрядный процесс. Более вероятно, что 64-разрядный процесс будет потреблять объем физической памяти на сервере, чем процесс будет потреблять выделенное виртуальное адресное пространство.

Таким образом, проблема с чрезмерным потреблением памяти зависит от следующих факторов:

• Битность процесса (32-разрядная или 64-разрядная)
• Объем использования памяти, который считается "нормальным".

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

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

Развернутые описания функций отладки Службы приложений Azure

В таблице раздела "Сопоставление сценариев дампа памяти с функциями отладки Службы приложений Azure" мы определили шесть функций отладки, предназначенных для сбора дампов памяти. Каждая из этих функций доступна на портале Azure на странице Диагностика и решение проблем при выборе плитки Средства диагностики .

В следующих разделах мы более подробно рассмотрим каждую из этих функций отладки.

Функция автоматического восстановления (длительность запроса)

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

• Автоматическое восстановление служб приложений

• Сбор и автоматизация диагностических действий с помощью Служб приложений Azure

Функция автоматического восстановления показана на следующем снимке экрана.

Другая функция с именем "Сбор дампа памяти" полезна в этом сценарии, когда проблема возникает или воспроизводима. Эта функция быстро собирает дамп памяти по запросу вручную.

Сбор функции дампа памяти

Сведения о конфигурации функции Сбора дампа памяти см. в статье Сбор служб приложений дампа памяти. Этот подход требует вмешательства вручную. На следующем снимке экрана показана страница Сбор дампа памяти .

Чтобы использовать эту функцию, выберите учетную запись хранения, в которой будет храниться дамп памяти. Затем выберите экземпляр сервера, с которого требуется собрать дамп памяти. Если у вас более одного экземпляра, убедитесь, что проблема, которую выполняется отладка, возникает в этом экземпляре. Обратите внимание, что перезапуск может оказаться неоптимальным для рабочего приложения, которое находится в работе.

Функция мониторинга сбоев

Функция мониторинга сбоев полезна для записи дампа памяти, если необработанное исключение приводит к завершению процесса W3WP. На следующем снимке экрана показана страница "Мониторинг сбоев" в средствах диагностики:

Чтобы просмотреть пошаговое руководство по настройке функции мониторинга сбоев в Службе приложений Azure, см. статью Мониторинг сбоев в Службе приложений Azure.

Трассировка в Функции Application Insights и Log Analytics

Обработанное исключение — это сценарий, в котором код, содержащийся в блоке try-catch, пытается выполнить непредвиденное или неподдерживаемое действие. Например, следующий фрагмент кода пытается разделить число на ноль, даже если это недопустимая операция:

decimal percentage = 0, number = 1000, total = 0;
try
{
  percentage = number / total;
}
catch (DivideByZeroException divEx)
{
  _logger.LogError("A handled exception just happened: -> {divEx.Message}", divEx.Message);
}

Этот фрагмент кода вызывает исключение деления на ноль, которое обрабатывается, так как неподдерживаемая математическая операция помещается в блок try-catch. Application Insights не регистрирует обрабатываемые исключения, если вы намеренно не включаете пакет NuGet Microsoft.ApplicationInsights в код приложения, а затем добавляете код для регистрации сведений. Если исключение возникает после добавления кода, вы можете просмотреть запись в Log Analytics, как показано на следующем снимке экрана.

Следующий код Kusto содержит запрос, используемый для извлечения данных из Log Analytics:

traces
| where message has "handled"
 | project timestamp, severityLevel, message, operation_Name, cloud_RoleInstance

Столбец message — это расположение, в котором можно хранить сведения, необходимые для поиска первопричины исключения. Код, используемый для написания этого запроса, находится в фрагменте кода деления на ноль. Разработчик программного обеспечения, написавший этот код, лучше всего спросить об этих исключениях и атрибутах, необходимых для анализа первопричин.

Лучший подход к добавлению этой функции в код приложения зависит от используемого стека кода приложения и версии (например, ASP.NET, ASP.NET Core, MVC, Razor и т. д.). Чтобы определить оптимальный подход к вашему сценарию, ознакомьтесь с разделом Ведение журнала Application Insights с помощью .NET.

Функция журналов событий приложений (обрабатываемые исключения)

Необработанных исключений можно также найти в обработанном исключении на странице Журналы событий приложенийсредства диагностики на портале Azure, как показано на следующем снимке экрана.

В этом случае вы получите то же сообщение об ошибке, которое вы выполнили в коде. Однако вы теряете некоторую гибкость в настройке запросов в журналах трассировки Application Insights.

Функция отладчика моментальных снимков Application Insights

Необработанных исключений также регистрируются на странице Журналы событий приложений , как показано в тексте выходных данных в следующем разделе. Однако можно также включить отладчик моментальных снимков Application Insights. Этот подход не требует добавления кода в приложение.

Функция журналов событий приложений (необработанных исключений)

Следующие выходные данные приведены на странице Журналы событий приложенийв средствах диагностики на портале Azure. В нем показан пример текста необработанного исключения приложения:

Category: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
EventId: 1
SpanId: 311d8cb5d10b1a6e
TraceId: 041929768411c12f1c3f1ccbc91f6751
ParentId: 0000000000000000
RequestId: 8000006d-0001-bf00-b63f-84710c7967bb
RequestPath: /Unhandled

An unhandled exception has occurred while executing the request.

Exception:
System.DivideByZeroException: Attempted to divide by zero.
   at System.Decimal.DecCalc.VarDecDiv(DecCalc& d1, DecCalc& d2)
   at System.Decimal.op_Division(Decimal d1, Decimal d2)
   at contosotest.Pages.Pages Unhandled.ExecuteAsync()
     in C:\Users\contoso\source\repos\contosorepo\contosorepo\Pages\Unhandled.cshtml:line 12

Одно отличие здесь от обработанного исключения в журнале приложения заключается в наличии стека, который идентифицирует метод и строку, из которой создается исключение. Кроме того, можно с уверенностью предположить, что функциональность Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware содержит код для перехвата этого необработанного исключения, чтобы избежать завершения процесса. Исключение отображается в Application Insights на вкладке Исключения на странице Сбои , как показано на следующем снимке экрана.

В этом представлении отображаются все исключения, а не только те, которые вы ищете. Графическое представление всех исключений, возникающих в приложении, полезно для получения общего представления о работоспособности системы. Панель мониторинга Application Insights визуально более полезна по сравнению с журналами событий приложения.

Функция упреждающего мониторинга ЦП

Во время сценариев чрезмерного использования ЦП можно использовать упреждающее средство мониторинга ЦП. Сведения об этом средстве см. в статье Устранение проблем с ЦП до их возникновения. На следующем рисунке показана страница "Упреждающий мониторинг ЦП" в средствах диагностики.

Использование ЦП на 80% или более следует рассматривать как критичную ситуацию, требующую немедленного изучения. На странице "Упреждающий мониторинг ЦП " можно задать сценарий, для которого требуется записать дамп памяти, на основе следующих категорий мониторинга данных:

• Пороговое значение ЦП
• Пороговое значение в секундах
• Частота монитора

Пороговое значение ЦП определяет, сколько ЦП компьютера использует целевой процесс (W3WP в данном случае). Пороговая секунда — это время использования ЦП в пороговом значении ЦП. Например, если загрузка ЦП составляет 75 % в общей сложности 30 секунд, дамп памяти будет записан. Как указано на странице "Упреждающий мониторинг ЦП ", процесс будет проверяться на наличие нарушений пороговых значений каждые 15 секунд.

Функция автоматического восстановления (ограничение памяти)

Функция автоматического восстановления (ограничение памяти) полезна для записи дампа памяти, если процесс потребляет больше памяти, чем ожидалось. Опять же, обратите внимание на разрядность (32 или 64). Если вы испытываете нехватку памяти в контексте 32-разрядного процесса и ожидается потребление памяти, вы можете рассмотреть возможность изменения разрядности на 64. Как правило, при изменении разрядности необходимо также выполнить повторную компиляцию приложения.

Изменение разрядности не приводит к уменьшению объема используемой памяти. Это позволяет процессу использовать более 4 ГБ общей памяти. Однако если потребление памяти не так, как ожидалось, вы можете использовать эту функцию, чтобы определить, что потребляет память. Затем можно выполнить действие для управления потреблением памяти.

В разделе "Расширенные описания функций отладки Службы приложений Azure" ссылка на автоматическое восстановление отображается на плитке Средства диагностики на первом снимке экрана. Выберите эту ссылку, чтобы перейти непосредственно к компоненту, или выберите плитку и просмотрите все доступные средства на странице Средства диагностики . Дополнительные сведения см. в разделе "Автоматическое восстановление"статьи Общие сведения о диагностике Службы приложений Azure.

Функция автоматического восстановления показана на следующем снимке экрана.

При выборе плитки Ограничение памяти можно ввести значение памяти, которое активирует запись дампа памяти при нарушении этого ограничения памяти. Например, если ввести 6291456 в качестве значения, при использовании 6 ГБ памяти создается дамп памяти процесса W3WP.

Функция Сбор дампа памяти полезна в этом сценарии, если проблема возникает в настоящее время или воспроизводима. Эта функция быстро собирает дамп памяти по запросу вручную. Дополнительные сведения см. в разделе "Сбор дампа памяти".

Развернутые описания команд

Искусство сбора дампов памяти занимает некоторое время для изучения, опыта и совершенства. Как вы узнали, различные процедуры основаны на симптомах, которые показывает процесс, как указано в таблице в разделе "Описания сценариев расширенного процесса". В следующей таблице сравнивается команда сбора дампа памяти Службы приложений Azure с командой procdump , выполняемой вручную из консоли Kudu.

Команды, используемые в функциях сбора дампа памяти в Службе приложений Azure, отличаются от команд procdump, которые используются при сборе дампов вручную. Если вы просмотрите предыдущий раздел, обратите внимание, что функция портала сбора дампов памяти в Службе приложений Azure предоставляет конфигурацию. Например, в сценарии чрезмерного потребления памяти в таблице команда, выполняемая платформой, не содержит порогового значения памяти. Однако команда, показанная в столбце общих команд procdump, задает порог памяти.

Средство с именем DaaS (диагностика как услуга) отвечает за управление и мониторинг конфигурации, указанной на портале отладки Службы приложений Azure. Это средство выполняется как веб-задание на виртуальных машинах, на которые выполняется веб-приложение. Преимущество этого средства заключается в том, что вы можете ориентироваться на определенную виртуальную машину в веб-ферме. Если вы попытаетесь записать дамп памяти напрямую с помощью procdump, может быть сложно определить, нацелить, получить доступ и выполнить эту команду на определенном экземпляре. Дополнительные сведения о DaaS см. в статье DaaS — диагностика как услуга для веб-сайтов Azure.

Чрезмерное использование ЦП — еще одна причина, по которой платформа управляет сбором дампов памяти, чтобы они соответствовали рекомендуемым шаблонам procdump. Команда procdump, как показано в предыдущей таблице, собирает три (-n 3) полных дампа памяти (-ma) с разницей в 30 секунд (-s #, в которых # значение равно 30), если загрузка ЦП превышает или равна 80 процентам (-c 80). Наконец, необходимо указать идентификатор процесса (<PID>) для команды : procdump -accepteula -ma -n 3 -s # -c 80 <PID>.

Конфигурацию портала можно просмотреть в разделе "Упреждающий мониторинг ЦП". Для краткости в этом разделе показаны только первые три параметра конфигурации: пороговое значение ЦП (-c), пороговое значение секунд (-s) и частота монитора. На следующем снимках экрана показано, что настройка действия, максимальное количество действий (-n) и максимальная длительность являются дополнительными доступными функциями.

После изучения различных подходов к захвату дампов памяти следующим шагом будет практика создания записей. Примеры кода можно использовать на GitHub вместе с лабораториями отладки IIS и Функциями Azure для имитации каждого из сценариев, перечисленных в двух таблицах. После развертывания кода на платформе Службы приложений Azure эти средства можно использовать для записи дампа памяти в каждом сценарии. Со временем и после практики вы можете усовершенствовать подход к сбору дампов памяти с помощью функций отладки Службы приложений Azure. В следующем списке содержится несколько рекомендаций, которые следует учитывать при дальнейшем изучении сбора дампов памяти:

• Захват дампа памяти потребляет значительные системные ресурсы и еще больше нарушает производительность.

• Запись дампов памяти при первом шансе не является оптимальным, так как вы, вероятно, зафиксируете слишком много. Эти дампы памяти первого шанса, скорее всего, не имеют значения.

• Мы рекомендуем отключить Application Insights перед записью дампа памяти W3WP.

После сбора дампа памяти следующим шагом является анализ дампа памяти, чтобы определить причину проблемы, а затем устранить эту проблему.

Дальнейшие действия (анализ дампа памяти)

Обсуждение того, как анализировать дампы памяти, выходит за рамки этой статьи. Однако для этой темы существует множество ресурсов, таких как серия учебных курсов "Средства дефрагментации" и список команд WinDbg, которые необходимо знать.

Возможно, вы заметили параметр Настроить действие на предыдущем снимке экрана. Параметр по умолчанию для этого параметра — CollectAndKill. Этот параметр означает, что процесс завершается после сбора дампа памяти. Параметр с именем CollectKillAndAnalyze анализирует собранный дамп памяти. В этом сценарии анализ платформы может обнаружить проблему, чтобы вам не нужно было открывать дамп памяти в WinDbg и анализировать его.

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

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.