Запись дампов памяти на платформе службы приложение Azure

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

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

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

Развернутые описания сценариев процесса

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

Неответственный или медленный сценарий

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

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

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

На протяжении многих лет корпорация Майкрософт платформа .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 на странице диагностики и решения проблем при выборе плитки "Средства диагностики".

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

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

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

• Объявление о новом интерфейсе автоматического восстановления в диагностике Служба приложений

• Объявление об автоматическом исцелении для Linux

• Сбор и автоматизация диагностических действий с помощью служб приложение 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 более полезна визуально по сравнению с журналами событий приложения.

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

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

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

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

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

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

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

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

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

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

При выборе плитки "Ограничение памяти" можно ввести значение памяти, которое активирует запись дампа памяти при нарушении этого ограничения памяти. Например, если ввести 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.