Captura de volcados de memoria en la plataforma de Azure App Service

En este artículo se proporcionan instrucciones sobre las características de depuración de Microsoft Azure App Service para capturar volcados de memoria. El método de captura que se usa viene determinado por el escenario en el que se captura un volcado de memoria para solucionar un problema de rendimiento o disponibilidad. Por ejemplo, capturar un volcado de memoria es diferente para un proceso que experimenta un consumo excesivo de memoria que para un proceso que genera excepciones o responde lentamente. El proceso en este contexto es el proceso de trabajo de Internet Information Services (IIS) (W3WP, que se ejecuta como w3wp.exe).

Asignación de escenarios de volcado de memoria a características de depuración Azure App Service

En la tabla siguiente se proporcionan recomendaciones sobre los comandos que se ejecutan cada característica App Service para generar un volcado de memoria. Hay tantos enfoques para capturar un volcado de memoria que el proceso podría ser confuso. Si ya tiene la capacidad de capturar un volcado de memoria W3WP, esta información no está pensada para cambiar el enfoque. En su lugar, esperamos proporcionar instrucciones para los usuarios inexpertos que aún no han desarrollado una preferencia.

Escenario	Azure App Service característica de depuración	Get-Help
No responde o es lento	Recuperación automática (duración de la solicitud)	procdump -accepteula -r -dc "Message" -ma <PID> <PATH>
Bloqueo (finalización del proceso)	Supervisión de bloqueos	Usa DbgHost para capturar un volcado de memoria
Bloqueo (excepciones controladas)	Seguimientos en Application Insights/Log Analytics	Ninguno
Bloqueo (excepciones no controladas)	Depurador de instantáneas de Application Insights	Ninguno
Uso excesivo de CPU	Supervisión proactiva de CPU	procdump -accepteula -dc "Message" -ma <PID> <PATH>
Consumo excesivo de memoria	Recuperación automática (límite de memoria)	procdump -accepteula -r -dc "Message" -ma <PID> <PATH>

Nota:

Tenemos una recomendación secundaria para capturar un volcado de memoria del proceso W3WP en el escenario lento o no responde. Si ese escenario es reproducible y desea capturar el volcado inmediatamente, puede usar la herramienta de diagnóstico Recopilar un volcado de memoria . Esta herramienta se encuentra en la página Conjunto de herramientas Diagnosticar y resolver problemas de la aplicación web de App Service determinada en el Azure Portal. Otra ubicación para comprobar si hay excepciones generales y un rendimiento deficiente es en la página Registros de eventos de la aplicación . (También puede acceder a los registros de aplicaciones desde la página Diagnosticar y resolver problemas). Se describen todos los métodos disponibles en la sección "Expanded Azure App Service debugging feature descriptions" (Descripciones de características de depuración expandidas Azure App Service).

Descripciones del escenario de proceso expandido

Esta sección contiene descripciones detalladas de los seis escenarios que se muestran en la tabla anterior.

Escenario lento o no responde

Cuando se realiza una solicitud a un servidor web, normalmente se debe ejecutar algún código. La ejecución del código se produce dentro del proceso dew3wp.exe en subprocesos. Cada subproceso tiene una pila que muestra lo que se está ejecutando actualmente.

Un escenario que no responde puede ser permanente (y es probable que se agote el tiempo de espera) o lento. Por lo tanto, el escenario que no responde es aquel en el que una solicitud tarda más de lo esperado en ejecutarse. Lo que podría considerarse lento depende de lo que haga el código. Para algunas personas, un retraso de tres segundos es lento. Para otros, un retraso de 15 segundos es aceptable. Básicamente, si ve métricas de rendimiento que indican lentitud o un superusuario indica que el servidor responde más lentamente de lo normal, tiene un escenario lento o no responde.

Escenario de bloqueo (finalización del proceso)

Durante muchos años, Microsoft .NET Framework ha mejorado el control de excepciones. En la versión actual de .NET, la experiencia de control de excepciones es aún mejor.

Históricamente, si un desarrollador no colocaba fragmentos de código en un bloque try-catch y se iniciaba una excepción, el proceso finalizaba. En ese caso, una excepción no controlada en el código del desarrollador finalizó el proceso. Las versiones más modernas de .NET controlan algunas de estas excepciones "no controladas" para que el proceso que ejecuta el código no se bloquee. Sin embargo, no todas las excepciones no controladas se inician directamente desde el código personalizado. Por ejemplo, las infracciones de acceso (como 0xC0000005 y 0x80070005) o un desbordamiento de pila pueden finalizar el proceso.

Escenario de bloqueo (excepciones controladas)

Aunque un desarrollador de software tiene especial cuidado para determinar todos los escenarios posibles en los que se ejecuta el código, puede producirse algo inesperado. Los errores siguientes pueden desencadenar una excepción:

• Valores NULL inesperados
• Conversión no válida
• Un objeto con instancia que falta

Se recomienda colocar la ejecución de código en bloques de código try-catch. Si un desarrollador usa estos bloques, el código tiene la oportunidad de producir un error correctamente mediante la administración específica de lo que sigue al evento inesperado. Una excepción controlada es una excepción que se produce dentro de un bloque try y se detecta en el bloque catch correspondiente. En este caso, el desarrollador anticipó que podría producirse una excepción y codificara un bloque try-catch adecuado alrededor de esa sección de código.

En el bloque catch, es útil capturar suficiente información en un origen de registro para que el problema se pueda reproducir y, en última instancia, resolverse. Las excepciones son rutas de acceso de código costosas en términos de rendimiento. Por lo tanto, tener muchas excepciones afecta al rendimiento.

Escenario de bloqueo (excepciones no controladas)

Las excepciones no controladas se producen cuando el código intenta realizar una acción que no espera encontrar. Como en el escenario de bloqueo (finalización del proceso), ese código no está incluido en un bloque de código try-catch. En este caso, el desarrollador no anticipó que podría producirse una excepción en esa sección de código.

Este escenario difiere de los dos escenarios de excepción anteriores. En el escenario bloqueo (excepciones no controladas), el código en cuestión es el código que escribió el desarrollador. No es el código de marco el que inicia la excepción y no es una de las excepciones no controladas que elimina el proceso dew3wp.exe . Además, dado que el código que inicia una excepción no está dentro de un bloque try-catch, no hay ninguna oportunidad de controlar la excepción correctamente. La solución de problemas del código es inicialmente un poco más compleja. Su objetivo sería encontrar el texto, el tipo y la pila de excepciones que identifica el método que inicia esta excepción no controlada. Esa información le permite identificar dónde tiene que agregar el bloque de código try-catch. A continuación, el desarrollador puede agregar la lógica similar para registrar los detalles de excepción que deben existir en el escenario de bloqueo (excepciones no controladas).

Escenario de uso excesivo de CPU

¿Qué es el uso excesivo de CPU? Esta situación depende de lo que haga el código. En general, si el uso de CPU del proceso dew3wp.exe es del 80 %, la aplicación se encuentra en una situación crítica que puede causar varios síntomas. Algunos síntomas posibles son:

• Lentitud
• Errores
• Otro comportamiento indefinido

Incluso un uso de CPU del 20 por ciento se puede considerar excesivo si el sitio web solo ofrece archivos HTML estáticos. La solución de problemas post-mortem de un pico excesivo de CPU al generar un volcado de memoria probablemente no le ayudará a determinar el método específico que lo usa. Lo mejor que puede hacer es determinar qué solicitudes probablemente tardaron más tiempo y, a continuación, intentar reproducir el problema mediante la prueba del método identificado. En ese procedimiento se supone que no se ejecutan monitores de rendimiento en los sistemas de rendimiento que capturaron esa ráfaga. En muchos casos, puede causar problemas de rendimiento si los monitores se ejecutan constantemente en tiempo real.

Escenario de consumo excesivo de memoria

Si una aplicación se ejecuta en un proceso de 32 bits, el consumo excesivo de memoria puede ser un problema. Incluso una pequeña cantidad de actividad puede consumir los 2-3 GB de espacio de direcciones virtuales asignados. Un proceso de 32 bits nunca puede superar un total de 4 GB, independientemente de la cantidad de memoria física disponible.

A un proceso de 64 bits se le asigna más memoria que a un proceso de 32 bits. Es más probable que el proceso de 64 bits consuma la cantidad de memoria física en el servidor que que el proceso consuma su espacio de direcciones virtuales asignado.

Por lo tanto, lo que constituye un problema de consumo excesivo de memoria depende de los siguientes factores:

• Bitness de proceso (32 bits o 64 bits)
• Cantidad de uso de memoria que se considera "normal".

Si el proceso consume más memoria de la esperada, recopile un volcado de memoria para su análisis a fin de determinar qué consume recursos de memoria. Para obtener más información, consulte Creación de un volcado de memoria de la App Service cuando consume demasiada memoria.

Ahora que tiene un poco más de contexto sobre los diferentes escenarios de proceso que un volcado de memoria puede ayudarle a solucionar problemas, analizaremos la herramienta recomendada para capturar volcados de memoria en la plataforma de Azure App Service.

Descripciones de características de depuración Azure App Service expandidas

En la tabla de la sección "Asignación de escenarios de volcado de memoria a Azure App Service características de depuración", hemos identificado seis características de depuración destinadas a recopilar volcados de memoria. Cada una de estas características es accesible desde el Azure Portal de la página Diagnosticar y resolver problemas al seleccionar el icono Herramientas de diagnóstico.

En las secciones siguientes, se describe cada una de estas características de depuración con más detalle.

Característica de recuperación automática (duración de la solicitud)

La característica de recuperación automática (duración de la solicitud) es útil para capturar un volcado de memoria si la respuesta tarda más de lo esperado en finalizar. Puede ver el vínculo a Recuperación automática en el icono Herramientas de diagnóstico en la captura de pantalla anterior. Seleccione ese vínculo para ir directamente a la característica o seleccione el icono Herramientas de diagnóstico para revisar todas las herramientas disponibles en la página Herramientas de diagnóstico . Para obtener información sobre cómo configurar esta característica, consulte los artículos siguientes:

• Recuperación automática de App Services

• Recopilación y automatización de acciones de diagnóstico con App de Azure Services

La característica de recuperación automática se muestra en la captura de pantalla siguiente.

Otra característica denominada "Recopilar un volcado de memoria" es útil en este escenario cuando el problema se está produciendo o reproducible actualmente. Esta característica recopila rápidamente un volcado de memoria a petición manual.

Recopilación de una característica de volcado de memoria

Para comprender la configuración de la característica Recopilar un volcado de memoria, consulte Recopilación de servicios de aplicaciones de volcado de memoria. Este enfoque requiere intervención manual. En la captura de pantalla siguiente se muestra la página Recopilar un volcado de memoria .

Para usar la característica, seleccione una cuenta de almacenamiento en la que almacenar el volcado de memoria. A continuación, seleccione la instancia de servidor de la que desea recopilar el volcado de memoria. Si tiene más de una sola instancia, asegúrese de que el problema que está depurando se está produciendo en esa instancia. Además, esta configuración reinicia la aplicación. Tenga en cuenta que es posible que un reinicio no sea óptimo en una aplicación de producción que esté en funcionamiento.

Característica de supervisión de bloqueos

La característica Supervisión de bloqueos es útil para capturar un volcado de memoria si una excepción no controlada hace que el proceso W3WP finalice. En la captura de pantalla siguiente se muestra la página Supervisión de bloqueos en Herramientas de diagnóstico:

Para ver un tutorial guiado sobre cómo configurar la característica de supervisión de bloqueos en Azure App Service, consulte Supervisión de bloqueos en Azure App Service.

Seguimientos en la característica Application Insights/Log Analytics

Una excepción controlada es un escenario en el que el código contenido en un bloque try-catch intenta realizar una acción inesperada o no admitida. Por ejemplo, el siguiente fragmento de código intenta dividir un número entre cero aunque se trate de una operación no válida:

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);
}

Este fragmento de código provoca una excepción de división por cero que se controla porque la operación matemática no admitida se coloca dentro de un bloque try-catch. Application Insights no registra excepciones controladas a menos que incluya intencionadamente el paquete NuGet Microsoft.ApplicationInsights en el código de la aplicación y, a continuación, agregue el código para registrar la información. Si la excepción se produce después de agregar el código, puede ver la entrada en Log Analytics, como se muestra en la captura de pantalla siguiente.

El siguiente código de Kusto contiene la consulta que se usa para extraer los datos de Log Analytics:

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

La message columna es la ubicación en la que puede almacenar los detalles necesarios para encontrar la causa principal de la excepción. El código que se usa para escribir esta consulta se encuentra en el fragmento de código de división por cero. El desarrollador de software que escribió este código es la mejor persona para preguntar sobre estos tipos de excepciones y los atributos necesarios para capturar para analizar las causas raíz.

El mejor enfoque para agregar esta funcionalidad al código de la aplicación depende de la pila de código de aplicación y la versión que tenga (por ejemplo, ASP.NET, ASP.NET Core, MVC, Razor, etc.). Para determinar el mejor enfoque para su escenario, revise el registro de Application Insights con .NET.

Característica de registros de eventos de aplicación (excepciones controladas)

También puede encontrar excepciones no controladas en la excepción controlada en la página Registros de eventos de la aplicación de Herramientas de diagnóstico en el Azure Portal, como se muestra en la captura de pantalla siguiente.

En esta situación, recibirá el mismo mensaje de error que ha registrado a través del código. Sin embargo, pierde cierta flexibilidad para personalizar las consultas en los registros de seguimiento de Application Insights.

Característica del depurador de instantáneas de Application Insights

Las excepciones no controladas también se registran en la página Registros de eventos de la aplicación, como se muestra en el texto de salida de la sección siguiente. Sin embargo, también puede habilitar el depurador de instantáneas de Application Insights. Este enfoque no requiere que agregue ningún código a la aplicación.

Característica de registros de eventos de aplicación (excepciones no controladas)

La siguiente salida procede de la página Registros de eventos de la aplicación de Herramientas de diagnóstico en el Azure Portal. Muestra un texto de ejemplo de una excepción de aplicación no controlada:

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

Una diferencia aquí con respecto a la excepción controlada en el registro de aplicaciones es la existencia de la pila que identifica el método y la línea desde la que se inicia la excepción. Además, puede suponer de forma segura que la funcionalidad Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware contiene código para detectar esta excepción no controlada de modo que se evite la finalización del proceso. La excepción se muestra en Application Insights en la pestaña Excepciones de la página Errores , como se muestra en la captura de pantalla siguiente.

En esta vista, verá todas las excepciones, no solo la que está buscando. La representación gráfica de todas las excepciones que se producen en la aplicación es útil para obtener información general sobre el estado del sistema. El panel de Application Insights es más útil visualmente en comparación con los registros de eventos de la aplicación.

Característica de supervisión proactiva de CPU

Durante escenarios de uso excesivo de CPU, puede usar la herramienta de supervisión proactiva de CPU. Para obtener información sobre esta herramienta, consulte Mitigación de los problemas de CPU antes de que se produzcan. En la imagen siguiente se muestra la página Supervisión proactiva de CPU en Herramientas de diagnóstico.

Debe considerar el uso de CPU del 80 por ciento o más como una situación crítica que requiere una investigación inmediata. En la página Supervisión proactiva de CPU , puede establecer el escenario para el que desea capturar un volcado de memoria en función de las siguientes categorías de supervisión de datos:

• Umbral de CPU
• Umbral de segundos
• Frecuencia de supervisión

Umbral de CPU identifica la cantidad de CPU del equipo que usa el proceso de destino (W3WP en este caso). Umbral segundos es la cantidad de tiempo que se usó la CPU en el umbral de CPU. Por ejemplo, si hay un uso de CPU del 75 por ciento durante un total de 30 segundos, se capturará el volcado de memoria. Tal como se ha configurado en la página Supervisión proactiva de CPU , el proceso se comprobaría si hay infracciones de umbral cada 15 segundos.

Característica de recuperación automática (límite de memoria)

La característica de recuperación automática (límite de memoria) es útil para capturar un volcado de memoria si el proceso consume más memoria de la esperada. De nuevo, preste atención a la bitness (32 o 64). Si experimenta presión de memoria en el contexto de proceso de 32 bits y se espera el consumo de memoria, podría considerar la posibilidad de cambiar el bitness a 64. Normalmente, si cambia el bitness, también tiene que volver a compilar la aplicación.

Cambiar el bitness no reduce la cantidad de memoria que se usa. Permite que el proceso use más de 4 GB de memoria total. Sin embargo, si el consumo de memoria no es el esperado, puede usar esta característica para determinar qué consume la memoria. A continuación, puede realizar una acción para controlar el consumo de memoria.

En la sección "Descripciones de características de depuración Azure App Service expandidas", puede ver el vínculo a Recuperación automática en el icono Herramientas de diagnóstico en la primera captura de pantalla. Seleccione ese vínculo para ir directamente a la característica o seleccione el icono y revise todas las herramientas disponibles en la página Herramientas de diagnóstico . Para obtener más información, vaya a la sección "Recuperación automática" de Azure App Service información general de diagnóstico.

La característica de recuperación automática se muestra en la captura de pantalla siguiente.

Al seleccionar el icono Límite de memoria , tiene la opción de escribir un valor de memoria que desencadene la captura de un volcado de memoria cuando se infringe ese límite de memoria. Por ejemplo, si escribe 6291456 como valor, se realiza un volcado de memoria del proceso W3WP cuando se consumen 6 GB de memoria.

La característica Recopilar un volcado de memoria es útil en este escenario si el problema se está produciendo o reproducible actualmente. Esta característica recopila rápidamente un volcado de memoria a petición manual. Para obtener más información, consulte la sección "Recopilar un volcado de memoria" .

Descripciones de comandos expandidas

El arte de la colección de volcados de memoria tarda algún tiempo en estudiar, experimentar y ser perfecto. Como ha aprendido, los distintos procedimientos se basan en los síntomas que muestra el proceso, como se muestra en la tabla de la sección "Descripciones del escenario de proceso expandido" . Por el contrario, en la tabla siguiente se compara el comando de captura de volcado de memoria del Azure App Service con el comando procdump que se ejecuta manualmente desde la consola de Kudu.

Escenario	comando Azure App Service	Comando procdump general
No responde o es lento	procdump -accepteula -r -dc "Message" -ma <PID> <PATH>	procdump -accepteula -ma -n 3 -s # <PID>
Bloqueo (finalización del proceso)	Usa DbgHost para capturar el volcado de memoria	procdump -accepteula -ma -t <PID>
Bloqueo (excepciones controladas)	Ninguno (Application Insights)	procdump -accepteula -ma -e 1 -f <filter> <PID>
Bloqueo (excepciones no controladas)	None (Application Insights Snapshot Debugger)	procdump -accepteula -ma -e <PID>
Uso excesivo de CPU	procdump -accepteula -dc "Message" -ma <PID> <PATH>	procdump -accepteula -ma -n 3 -s # -c 80 <PID>
Consumo excesivo de memoria	procdump -accepteula -r -dc "Message" -ma <PID> <PATH>	procdump -accepteula -ma -m 2000 <PID>

Los comandos que se usan en las características de captura de volcado de memoria en Azure App Service difieren de los comandos procdump que usaría si capturara volcados manualmente. Si revisa la sección anterior, debe observar que la característica del portal de recopilación de volcado de memoria en Azure App Service expone la configuración. Por ejemplo, en el escenario de consumo excesivo de memoria de la tabla, el comando que ejecuta la plataforma no contiene un umbral de memoria. Sin embargo, el comando que se muestra en la columna de comandos procdump general especifica un umbral de memoria.

Una herramienta denominada DaaS (Diagnóstico como servicio) es responsable de administrar y supervisar la configuración especificada en el portal de depuración de Azure App Service. Esta herramienta se ejecuta como un trabajo web en las máquinas virtuales (VM) que ejecutan la aplicación web. Una ventaja de esta herramienta es que puede dirigirse a una máquina virtual específica en la granja de servidores web. Si intenta capturar un volcado de memoria mediante procdump directamente, puede ser difícil identificar, dirigir, acceder y ejecutar ese comando en una instancia específica. Para obtener más información sobre DaaS, consulte DaaS: diagnóstico como servicio para sitios web de Azure.

El uso excesivo de CPU es otra razón por la que la plataforma administra la colección de volcado de memoria para que coincidan con los patrones de procesamiento recomendados. El comando procdump, como se muestra en la tabla anterior, recopila tres volcados de memoria completos () con-ma 30 segundos de diferencia (-s #en los que # es 30) cuando el uso de CPU es mayor o igual que el 80 por ciento (-c 80).-n 3 Por último, proporcione el identificador de proceso (<PID>) al comando : procdump -accepteula -ma -n 3 -s # -c 80 <PID>.

Puede ver la configuración del portal en la sección "Supervisión proactiva de CPU" . Para mayor brevedad, esa sección mostró solo las tres primeras opciones de configuración: Umbral de CPU (-c), Umbral de segundos (-s) y Frecuencia de supervisión. En la captura de pantalla siguiente se muestra que Configurar acción, Acciones máximas (-n) y Duración máxima son características adicionales disponibles.

Después de estudiar los distintos enfoques para capturar volcados de memoria, el siguiente paso es practicar la realización de capturas. Puede usar ejemplos de código en GitHub junto con laboratorios de depuración de IIS y Azure Functions para simular cada uno de los escenarios que se enumeran en las dos tablas. Después de implementar el código en la plataforma de Azure App Service, puede usar estas herramientas para capturar el volcado de memoria en cada escenario determinado. Con el tiempo y después de la práctica, puede perfeccionar el enfoque para capturar volcados de memoria mediante las características de depuración de Azure App Service. La lista siguiente contiene algunas sugerencias que se deben tener en cuenta a medida que continúe aprendiendo sobre la recopilación de volcado de memoria:

• La captura de un volcado de memoria consume recursos significativos del sistema e interrumpe aún más el rendimiento.

• Capturar volcados de memoria en la primera oportunidad no es óptimo porque es probable que capture demasiados. Esos volcados de memoria de primera oportunidad probablemente sean irrelevantes.

• Se recomienda deshabilitar Application Insights antes de capturar un volcado de memoria W3WP.

Una vez recopilado el volcado de memoria, el siguiente paso es analizar el volcado de memoria para determinar la causa del problema y, a continuación, corregir ese problema.

Pasos siguientes (análisis del volcado de memoria)

La explicación de cómo analizar volcados de memoria está fuera del ámbito de este artículo. Sin embargo, hay muchos recursos para ese asunto, como la serie de entrenamiento Defrag Tools y una lista de comandos de WinDbg imprescindibles.

Es posible que haya observado la opción Configurar acción en la captura de pantalla anterior. La configuración predeterminada de esta opción es CollectAndKill. Esta configuración significa que el proceso se elimina después de recopilar el volcado de memoria. Una configuración denominada CollectKillAndAnalyze analiza el volcado de memoria que se recopila. En ese escenario, el análisis de plataforma podría encontrar el problema para que no tenga que abrir el volcado de memoria en WinDbg y analizarlo.

Hay otras opciones para solucionar y diagnosticar problemas de rendimiento en la plataforma de Azure App Service. Este artículo se centra en la recopilación de volcados de memoria y realiza algunas recomendaciones para abordar el diagnóstico mediante estos métodos. Si ya ha estudiado, experimentado y perfeccionado los procedimientos de recopilación, y funcionan bien para usted, debe seguir usando esos procedimientos.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.