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

En este artículo se proporcionan instrucciones sobre las características de depuración de Microsoft App de Azure Service para capturar volcados de memoria. El método de captura que usa está determinado por el escenario en el que se captura un volcado de memoria para solucionar un problema de rendimiento o disponibilidad. Por ejemplo, la captura de un volcado de memoria es diferente para un proceso que experimenta un consumo excesivo de memoria que para un proceso que produce 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 las características de depuración de App de Azure Service

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

Escenario	característica de depuración de App de Azure Service	Comando
No responde o 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 de proceso de W3WP en el escenario no responde o lento. Si ese escenario es reproducible y desea capturar el volcado inmediatamente, puede usar la herramienta recopilar un diagnóstico de volcado de memoria . Esta herramienta se encuentra en la página Diagnosticar y resolver problemas de la aplicación web de App Service determinada en Azure Portal. Otra ubicación para comprobar las excepciones generales y un rendimiento deficiente está en la página Registros de eventos de la aplicación. (También puede acceder a los registros de la aplicación desdePágina Diagnosticar y resolver problemas). Se describen todos los métodos disponibles en la sección "Descripciones de características de depuración expandidas App de Azure Service".

Descripciones de escenarios de proceso expandidos

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

Escenario no responde o lento

Cuando se realiza una solicitud a un servidor web, normalmente se debe ejecutar código. La ejecución del código se produce dentro del proceso de w3wp.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 agote el tiempo de espera) o lento. Por lo tanto, el escenario que no responde es uno en el que una solicitud tarda más de lo esperado en ejecutarse. Lo que podría considerar ser lento depende de lo que hace 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 lento de lo normal, tiene un escenario que no responde o lento.

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 dentro de un bloque try-catch y se produjo una excepción, el proceso finalizó. 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 nulos inesperados
• Conversión no válida
• Falta un objeto creado por instancias

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 generar errores 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 se podría producir una excepción y codificar un bloque try-catch adecuado alrededor de esa sección de código.

En el bloque catch, resulta útil capturar suficiente información en un origen de registro para que el problema se pueda reproducir y, en última instancia, resolverlo. 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 bloqueo (terminación del proceso), ese código no está incluido en un bloque de código try-catch. En este caso, el desarrollador no esperaba que se pudiera producir 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 que inicia la excepción y no es una de las excepciones no controladas que elimina el proceso de w3wp.exe . Además, dado que el código que produce 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. El objetivo sería buscar el texto de excepción, el tipo y la pila que identifica el método que produce 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 bloqueo (excepciones no controladas).

Escenario de uso excesivo de CPU

¿Qué es un uso excesivo de CPU? Esta situación depende de lo que hace el código. En general, si el uso de cpu del proceso de w3wp.exe es del 80 por ciento, 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 no definido

Incluso un uso de CPU del 20 % puede considerarse excesivo si el sitio web simplemente entrega archivos HTML estáticos. La solución de problemas posteriores a la solución de problemas de un pico excesivo de CPU mediante la generación de 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 tardaban más tiempo y, a continuación, intentar reproducir el problema probando el método identificado. Ese procedimiento supone que no ejecuta monitores de rendimiento en los sistemas de rendimiento que capturaron esa ráfaga. En muchos casos, puede causar problemas de rendimiento al tener monitores que 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 asignado. Un proceso de 32 bits nunca puede superar un total de 4 GB, independientemente de la cantidad de memoria física disponible.

Un proceso de 64 bits se asigna más memoria que 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 el proceso consumirá su espacio de direcciones virtual asignado.

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

• Bits de proceso (32 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 el análisis para determinar qué consume recursos de memoria. Para más información, consulte Creación de un volcado de memoria de 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 servicio App de Azure.

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

En la tabla de la sección "Asignación de escenarios de volcado de memoria para App de Azure características de depuración del servicio", hemos identificado seis características de depuración destinadas a recopilar volcados de memoria. Cada una de estas características es accesible desde Azure Portal en 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 Auto-Heal 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 siguientes artículos:

• 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. 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 de 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 App de Azure Service, consulte Supervisión de bloqueos en App de Azure 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 por 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 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 está 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 principales.

El mejor enfoque para agregar esta funcionalidad al código de la aplicación depende de la pila de código de la 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, consulte Registro de Application Insights con .NET.

Característica 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 Azure Portal, como se muestra en la captura de pantalla siguiente.

En esta situación, recibirá el mismo mensaje de error que registró a través del código. Sin embargo, pierde cierta flexibilidad en cómo puede 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 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 registros de eventos de aplicación (excepciones no controladas)

La salida siguiente es de la página Registros de eventos de la aplicación de Herramientas de diagnóstico en Azure Portal. Muestra algún 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í de la excepción controlada en el registro de aplicación es la existencia de la pila que identifica el método y la línea desde la que se produce 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 para que se evite la terminació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 resulta ú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 proactiva de supervisión de CPU

Durante escenarios excesivos de uso 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 % 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 que usa el proceso de destino del equipo (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 % durante un total de 30 segundos, se capturaría el volcado de memoria. Tal y como se ha configurado en la página Supervisión proactiva de CPU, el proceso se comprobaría para detectar 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 lo esperado. De nuevo, preste atención al 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, puede considerar la posibilidad de cambiar el bit a 64. Normalmente, si cambia el valor de bits, también debe volver a compilar la aplicación.

Cambiar el valor de bits 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 "Expandida App de Azure Descripciones de características de depuración del servicio", puede ver el vínculo a Auto-Heal 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 App de Azure Información general sobre diagnósticos del servicio.

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 desencadena la captura de un volcado de memoria cuando se infringe ese límite de memoria. Por ejemplo, si escribes 6291456 como valor, se toma un volcado de memoria del proceso de 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, vea la sección "Recopilar un volcado de memoria".

Descripciones de comandos expandidas

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

Escenario	Comando App de Azure Service	Comando procdump general
No responde o 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)	None (Application Insights)	procdump -accepteula -ma -e 1 -f <filter> <PID>
Bloqueo (excepciones no controladas)	Ninguno (Depurador de instantáneas de Application Insights)	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 de App de Azure Service difieren de los comandos procdump que usaría si capturaba volcados manualmente. Si revisa la sección anterior, debe observar que la característica del portal de recopilación de volcados de memoria de App de Azure 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 App de Azure 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 tener como destino una máquina virtual específica en la granja de servidores web. Si intenta capturar un volcado de memoria mediante procdump directamente, puede resultar difícil identificar, dirigir, acceder y ejecutar ese comando en una instancia específica. Para más información sobre DaaS, consulte DaaS : diagnóstico como servicio para sitios web de Azure.

El uso excesivo de la CPU es otro motivo por el que la plataforma administra la colección de volcados de memoria para que coincidan con los patrones de procdump recomendados. El comando procdump, como se muestra en la tabla anterior, recopila tres-n 3 volcados de memoria completos () (-ma) 30 segundos (-s #, en los que # es 30) cuando el uso de la CPU es mayor o igual que el 80 % (-c 80). 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". Por motivos de brevedad, esa sección solo mostró las tres primeras opciones de configuración: Umbral de CPU (), Segundos de umbral (-s-c) 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 diferentes 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 los 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 App de Azure 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 App de Azure Service. La lista siguiente contiene algunas sugerencias que se deben tener en cuenta a medida que continúa aprendiendo sobre la recopilación de volcados de memoria:

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

• Capturar volcados de memoria en la primera oportunidad no es óptimo porque probablemente capturará demasiados. Es probable que esos volcados de memoria de primera oportunidad sean irrelevantes.

• Se recomienda deshabilitar Application Insights antes de capturar un volcado de memoria de 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, corregirlo.

Pasos siguientes (análisis del volcado de memoria)

Describir 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 Herramientas de desfragmentación y una lista de comandos de WinDbg que deben conocerse.

Es posible que haya observado la opción Configurar acción en la captura de pantalla anterior. El valor predeterminado 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 la 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 App de Azure 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 sus procedimientos de colecció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.