Compartir a través de

Parte 3.3: depuradores, volcados de memoria principales y recopilación de volcados de memoria principales

Se aplica a: .NET Core 2.1, .NET Core 3.1, .NET 5

En este artículo se presentan depuradores y volcados de memoria principales y las herramientas para capturar y analizar archivos de volcado de memoria principales en Linux.

Requisitos previos

Como en las partes anteriores, esta parte está estructurada para poner más énfasis en la teoría y los principios que se deben seguir al empezar a solucionar problemas. No tiene ningún requisito previo. Sin embargo, debe tener los siguientes elementos ya configurados si ha seguido todos los pasos de este entrenamiento hasta ahora:

  • Nginx tiene dos sitios web:
    • El primer sitio web escucha las solicitudes mediante el encabezado de host myfirstwebsite (http://myfirstwebsite) y enruta las solicitudes a la aplicación de demostración ASP.NET Core que escucha en el puerto 5000.
    • El segundo sitio web escucha las solicitudes mediante el encabezado de host buggyamb (http://buggyamb) y enruta las solicitudes a la segunda aplicación de buggy de ejemplo de ASP.NET Core que escucha en el puerto 5001.
  • Ambas aplicaciones ASP.NET Core se ejecutan como servicios que se reinician automáticamente cuando se reinicia el servidor o las aplicaciones dejan de responder o se producen errores.
  • Un firewall local de Linux está habilitado y configurado para permitir el tráfico SSH y HTTP.

Objetivo de esta parte

En esta parte se presenta el concepto de volcados y depuradores principales, así como las herramientas que puede usar para capturar y analizar los archivos de volcado de memoria principales. La mayoría de las técnicas y herramientas que se describen en esta parte se usarán en los siguientes laboratorios de solución de problemas.

Volcado de memoria principal

Al igual que un volcado de memoria en modo de usuario en Windows, un volcado de memoria principal es una instantánea de la memoria de un proceso. Los volcados de memoria principales son necesarios con frecuencia para solucionar problemas de rendimiento en Linux.

Un depurador puede generar un volcado de núcleo a petición (colección de volcado manual) o se puede configurar para que se recopile automáticamente después de un error de proceso.

¿Qué ocurre cuando se produce un error en un proceso en Linux?

La mayoría de los sistemas Linux tienen volcados principales habilitados de forma predeterminada. El sistema genera un volcado de núcleo para cualquier proceso que finalice inesperadamente. Esto es similar a la manera en que Informe de errores de Windows (WER) genera volcados de memoria para los procesos que finalizan de forma anómala.

Estos son algunos aspectos clave de cómo se comporta un sistema Linux relacionado con la generación de archivos de volcado de memoria principal:

  • De forma predeterminada, se genera un archivo de volcado de núcleo cuando un proceso finaliza inesperadamente.
  • El archivo de volcado de núcleo se denomina "core" y se crea en el directorio de trabajo actual o en el /var/lib/systemd/coredump directorio .
  • Aunque el comportamiento predeterminado es para que el sistema operativo genere un archivo de volcado de núcleo, esta configuración se puede sobrescribir en /proc/sys/kernel/core_pattern para canalizar directamente la salida del archivo de volcado de memoria principal a otra aplicación.

Estos valores predeterminados y otros, como los límites de tamaño, se pueden establecer en los archivos de configuración. Los siguientes recursos profundizan en este tema:

Apport: la manera de Ubuntu de administrar volcados de memoria principales

En Ubuntu, el servicio del sistema apport administra la generación de volcado de memoria principal. Incluso si la generación de volcado de memoria principal del sistema operativo está deshabilitada, apport seguirá creando archivos de volcado de memoria principales.

Apport usa /proc/sys/kernel/core_pattern para canalizar directamente el archivo de volcado de núcleo en apport. Si ejecuta el cat /proc/sys/kernel/core_pattern comando mientras se ejecuta apport, debería ver el siguiente resultado.

Captura de pantalla del comando cat core.

Si deshabilita apport, esto no impide la generación de volcado de memoria principal tras la finalización del proceso. En su lugar, simplemente se detiene apport. A continuación, el sistema volverá a su comportamiento predeterminado mediante la generación de volcados de núcleo. Si ejecuta lo mismo cat /proc/sys/kernel/core_pattern después de detener la ventanilla, verá el siguiente comportamiento predeterminado del sistema.

Captura de pantalla del comando sudo y cat.

Deshabilitación de la generación automática de volcado de memoria principal

Para deshabilitar la generación automática de archivos de volcado de núcleo, siga estos pasos:

  1. Detenga y deshabilite apport.
  2. Deshabilite la acción predeterminada del sistema.

Apport se puede detener y deshabilitar igual que cualquier otro servicio. Use el sudo systemctl stop apport comando y el sudo systemctl disable apport comando para detener el servicio y, a continuación, deshabilite para evitar que se reinicie.

Captura de pantalla del comando sudo systemctl stop apport.

Para deshabilitar la generación automática de archivos de volcado de memoria del sistema operativo para todos los procesos que se ejecutan en todas las cuentas de usuario del equipo, debe realizar los pasos que se proporcionan en artículos como este.

Capturar volcado de memoria principal y depuradores

Hay varias herramientas disponibles para capturar un archivo de volcado de núcleo, como gcore, gdb y varias herramientas para analizar un archivo de volcado principal, como objdump, kdump, gdb y lldb.

Sin embargo, encontrará algunas dificultades importantes al trabajar con estas herramientas para intentar realizar la depuración de .NET:

  • La configuración podría ser difícil en comparación con el proceso de configuración de símbolos para el depurador de WinDbg en Windows.
  • Los archivos de volcado de núcleo son grandes porque estas herramientas no saben qué región de memoria se usa en un proceso de .NET Core y no pueden recortar la información de memoria solo a lo que se necesita.
  • Los archivos de volcado de memoria no son portátiles. Tendrá que analizar los archivos de volcado en el equipo Linux en el que se generaron. Si desea analizar los archivos de volcado en un equipo Linux diferente, es necesario realizar pasos adicionales para configurar el equipo host para la sesión de depuración.

lldb

Lldb es la herramienta recomendada para analizar el volcado de memoria de .NET Core. El SDK de .NET incluye herramientas útiles para configurar lldb correctamente. Sin embargo, debe instalar al menos la versión 3.9 para poder realizar este análisis de depuración para .NET Core.

Para instalar lldb 3.9 o una versión posterior, use Administrador de paquetes (por ejemplo: sudo apt install lldb).

Herramientas y comandos disponibles en el entorno de ejecución y el SDK de .NET Core

Se incluyen varias herramientas útiles junto con el entorno de ejecución de .NET Core. Por ejemplo, createdump se instala como parte de cada instalación en tiempo de ejecución de .NET Core.

También puede desarrollar sus propias herramientas o elegir usar varias herramientas de terceros. La plataforma Microsoft .NET Core también incluye algunas herramientas de .NET Core que son útiles para depurar problemas de .NET Core. que incluyen la siguiente información:

  • dotnet-dump
  • dotnet-gcdump
  • dotnet-symbol

Para instalar estas herramientas junto con las demás, debe tener instalado el SDK de .NET Core. Para obtener más información sobre el SDK de .NET Core, consulte: Introducción al SDK de .NET.

Nota:

Procdump también merece una mención, aunque no forma parte del SDK. Se puede encontrar una explicación detallada de las opciones de ProcDump al final de esta parte.

createdump

Createdump se instala en cada versión de .NET Core. Para obtener más información, consulte los detalles de implementación.

Createdump es la mejor manera de generar un archivo de volcado de núcleo en Linux. Esto se debe a que es posible que los archivos de volcado de memoria generados automáticamente por el sistema no incluyan todos los estados administrados. Además, algunos comandos SOS o dotnet-dump pueden mostrar "UNKNOWN" para los nombres de tipo y función.

Del mismo modo, los archivos de volcado manual que se crean mediante gdb o gcore no incluirán toda la información de estado administrado, y algunos comandos SOS o dotnet-dump también pueden mostrar "UNKNOWN" para los nombres de tipo y función. La manera recomendada de capturar archivos de volcado manual es mediante createdump o alguna otra herramienta de .NET Core, como procdump.

Estas son algunas características importantes de createdump:

  • Los minivolcados de tamaño mínimo se generan automáticamente.
  • Es fácil configurar con un usuario no raíz.
  • Puede usarlo para capturar archivos de volcado de memoria principal de errores del sistema (manual) o a petición.
  • Se detectan la mayoría de los errores de desbordamiento de pila.

Debe usar lldb 3.9 o una versión posterior para analizar los archivos de volcado de memoria principales que se capturan mediante createdump.

Puede encontrar createdump en el directorio de instalación de .NET Core. Para buscar este directorio, ejecute el dotnet --list-runtimes comando . Como se muestra en la captura de pantalla siguiente, se creó un archivo createdump independiente para las dos versiones de los entornos de ejecución activos.

Captura de pantalla del comando dotnet.

dotnet-dump

Debe tener instalado el SDK de .NET Core para poder instalar esta herramienta. Dotnet-dump se introdujo en el SDK de .NET Core 3.0. Ayuda a recopilar y analizar archivos de volcado de memoria principal sin necesidad de ningún depurador nativo. Permite ejecutar comandos SOS para analizar los errores y la salida del recolector de elementos no utilizados (GC).

Nota:

Dotnet-dump no es un depurador nativo. Por lo tanto, algunas características, como mostrar los marcos de pila nativos, no están disponibles. El archivo de volcado de memoria que se genera no es portátil y no se puede abrir en Windows.

Para instalar esta herramienta, ejecute el siguiente comando:

dotnet tool install -g dotnet-dump

Usará esta herramienta para capturar y analizar los archivos de volcado de núcleo en las próximas secciones del laboratorio.

dotnet-gcdump

Esta es otra herramienta que requiere el SDK de .NET Core. Dotnet-gcdump está disponible en .NET Core 3.1 o versiones posteriores.

Este es un enfoque interesante para analizar montones de GC. La idea de esta herramienta es que no se requiere un archivo de volcado de proceso completo para las investigaciones en muchos escenarios. Por lo tanto, la herramienta captura solo la información del montón administrado y genera un informe basado en él.

Lo más importante es que los archivos de volcado generados por esta herramienta son portátiles y se pueden analizar en PerfView o Visual Studio en Windows.

Como se explica brevemente aquí, esta herramienta desencadena una recolección completa de elementos no utilizados para transmitir la información a una "canalización de eventos" para generar el archivo de volcado.

Nota:

Dado que se desencadena una recolección completa de elementos no utilizados gen 2 en el proceso de destino, se pueden cambiar las características de rendimiento de la aplicación. Como podría esperar, mientras la información se escribe en el archivo de volcado de memoria principal, los subprocesos se suspenderán. Cuanto mayor sea el tamaño del montón, más largos son las pausas para escribir la información en el archivo y cuanto más tiempo permanezcan en pausa los subprocesos.

La información contenida dentro de estos archivos de volcado de memoria principal será útil en las siguientes circunstancias:

  • Comparación del número de objetos por tipo en el montón administrado
  • Análisis de raíces de objetos
  • Determinar qué objetos tienen una referencia a qué tipo
  • Otro análisis estadístico sobre objetos en el montón

Una vez generados los datos, el archivo se puede exportar fuera del equipo en el que se creó y se puede analizar en PerfView o en Visual Studio.

Para instalar esta herramienta, ejecute el siguiente comando:

dotnet tool install -g dotnet-gcdump

Usará este comando para generar algunos informes para montones de .NET Core en las próximas secciones del laboratorio.

dotnet-symbol

Dotnet-symbol es una herramienta útil para obtener símbolos para la depuración administrada. Se introdujo en .NET Core 2.1. En cuanto a las otras dos herramientas que se mencionan anteriormente, estas herramientas también requieren que se instale el SDK de .NET Core.

Dotnet-symbol descarga todos los archivos necesarios para la depuración (símbolos, módulos, SOS y DAC para el módulo coreclr) para cualquier archivo de volcado de núcleo determinado.

Para instalar esta herramienta, ejecute el siguiente comando:

dotnet tool install -g dotnet-symbol

Usará esta herramienta para configurar el depurador en las próximas secciones del laboratorio.

procdump

También hay disponible una versión de Linux de ProcDump . Tiene algunos conjuntos de características limitados en comparación con su homólogo de Windows. No admite todas las características que realiza la versión de Windows. Por ejemplo, no se puede configurar para recopilar archivos de volcado de memoria principal cuando el proceso se bloquea o produce una excepción de primera oportunidad. Sin embargo, sigue siendo una herramienta eficaz.

Las siguientes opciones de línea de comandos para la generación de archivos de volcado de núcleo del desencadenador procDump en las condiciones especificadas.

-C: CPU exceeds or equals a specified value (0 to 100 * nCPU)
-c: CPU is less than a specified value (0 to 100 * nCPU)
-M: The memory commit exceeds or equals a specified value (MB)
-m: The memory commit is less than a specified value (MB)
-T: The thread count exceeds or equals a specified value
-F: The filedescriptor count exceeds or equals a specified value

Siga las instrucciones de instalación para instalar ProcDump en su entorno.

Usará esta herramienta para capturar un archivo de volcado de núcleo basado en el uso de CPU en las próximas secciones del laboratorio.

Nota sobre cómo seleccionar la versión del SDK

De forma predeterminada, el SDK se instala en una configuración "en paralelo". Esto significa que varias versiones se pueden ejecutar juntas en un solo equipo. La forma en que se detecta la versión al ejecutar los comandos de la CLI se explica más detalladamente en el artículo Selección de la versión de .NET Core que se va a usar. Sin embargo, el proceso para seleccionar una versión del SDK se puede resumir de la siguiente manera:

  • .NET Core busca un archivo de global.json de forma iterativa invierte la navegación hacia arriba desde el directorio de trabajo actual.
  • .NET Core usa el SDK especificado en la primera global.json que se encuentra.
  • .NET Core usa el SDK instalado más reciente si no se encuentra ninguna instancia de global.json .

Por ejemplo, en la máquina virtual Linux de prueba, debe tener instalados los SDK de .NET Core 3.1 y 5.0. Si ejecuta .NET Core mediante la inclusión del --version modificador, debería ver que se usa la versión más reciente.

Captura de pantalla del comando list.

Ahora, cree un archivo global.json en el directorio actual (su directorio principal) y establezca la versión explícitamente mediante la herramienta cat, como se muestra. A continuación, vuelva a comprobar la versión. Ahora se muestra la versión exacta del SDK que ha colocado en el archivo global.json .

Captura de pantalla del comando cat json.

Esto es importante saber cuándo se ejecutan algunos comandos del SDK, como la creación de una aplicación mediante el comando .NET Core new . Sin embargo, no tendrá que hacerlo cuando use las herramientas dotnet-dump y dotnet-gcdump.

El SDK de .NET Core instala la versión más reciente de las herramientas, independientemente del SDK que haya seleccionado. Por ejemplo, si ejecutó los comandos para instalar dotnet-dump, dotnet-gcdump y dotnet-symbol tools for .NET Core SDK 3.1, se descargarán e instalarán las versiones más recientes de estas herramientas, como se muestra en la captura de pantalla siguiente (donde se instaló la versión 5 de las herramientas para dotnet-dump y dotnet-gcdump).

Captura de pantalla del comando dotnet tool.

Los siguientes artículos son excelentes recursos para obtener más información sobre las herramientas de .NET Core:

Nota:

Seleccionar la versión en tiempo de ejecución que se va a usar es diferente de seleccionar la versión del SDK. Si desea usar una versión específica del entorno de ejecución de .NET, use la opción --fx-version <VERSION> , como se explica en este artículo.

Pasos siguientes

Ya está listo para comenzar los laboratorios de solución de problemas. En los laboratorios, aprenderá a usar las herramientas que se describen aquí para solucionar problemas.

Laboratorio 1.1 Reproducir y solucionar un problema de bloqueo