Uso de memoria en aplicaciones de alto nivel

  • Artículo

En este tema se proporcionan detalles sobre el uso de memoria en aplicaciones de alto nivel. Consulte Administrar consideraciones de memoria y latencia para obtener información sobre la memoria disponible para aplicaciones en tiempo real (RTApps).

Las aplicaciones de alto nivel tienen acceso a la siguiente memoria y almacenamiento:

  • 256 KiB RAM en el núcleo de alto nivel, reservado completamente para uso de aplicaciones de alto nivel. Hasta 1 KiB de este espacio se puede asignar para cada canal de búfer compartido a través del cual las aplicaciones de alto nivel y RTApps se comunican.
  • 1 memoria flash de solo lectura miB, que se comparte entre los núcleos de alto nivel y en tiempo real.
  • Almacenamiento de lectura y escritura (mutable), que persiste cuando se reinicia un dispositivo. Para obtener información sobre el almacenamiento mutable, consulte Uso del almacenamiento en Azure Sphere.

Nota

La actualización repetida del flash eventualmente lo desgasta y lo hace inválido. Por lo tanto, debes diseñar el código para evitar actualizaciones innecesarias del flash. Por ejemplo, si desea guardar el estado de la aplicación antes de salir para poder recuperar el estado guardado después de reiniciar, considere la posibilidad de guardar el estado de la aplicación en flash solo si el estado ha cambiado.

Determinar el uso de memoria flash

Para determinar el uso de memoria flash, tenga en cuenta solo el tamaño del archivo de paquete de imagen, que incluye los metadatos de imagen, el manifiesto de la aplicación y la imagen ejecutable. No es necesario tener en cuenta el almacenamiento necesario para los componentes proporcionados por Microsoft, como el SO Azure Sphere o los servicios en tiempo de ejecución y bibliotecas compartidas que controlan periféricos y habilitan la conexión a un Azure IoT Hub. Del mismo modo, no es necesario incluir el tamaño de una copia de seguridad completa de la aplicación o los componentes que habilitan la conmutación por error o reversión en caso de daños o problemas con actualizaciones sobre el aire.

Sin embargo, durante el desarrollo y la depuración, el tamaño del depurador no cuenta para el límite. El depurador se agrega automáticamente mediante az sphere device enable-development y se elimina mediante [az sphere device enable-cloud-test](.. /reference/az sphere-device.md). Para encontrar el tamaño del depurador usado por el SDK, busca gdbserver.imagepackage en la carpeta DebugTools del directorio de instalación del SDK de Esfera de Microsoft Azure.

El comando az sphere device sideload devuelve un error si el paquete de imagen de la aplicación y el depurador (si están presentes) superan el límite total de 1 MiB. El comando az sphere image add --image , que carga una nueva imagen en el catálogo de Azure Sphere, también devuelve un error si el paquete de imagen supera 1 MiB.

El límite de ram de 256 kiB se aplica únicamente a la aplicación; no es necesario permitir la MEMORIA RAM que usa el depurador. La memoria adicional está reservada para las asignaciones de kernel.

El flash disponible y la MEMORIA RAM pueden aumentar (pero nunca disminuir) para las aplicaciones escritas para el chip azure sphere actual (MT3620). Los futuros chips de Azure Sphere pueden tener límites diferentes.

Condiciones de memoria insuficiente

Si la aplicación usa demasiada RAM, Azure Sphere OS termina con una señal SIGKILL. Por ejemplo, en el depurador verá lo siguiente:

Child terminated with signal = 0x9 (SIGKILL)

La señal SIGKILL también ocurre si una aplicación de alto nivel no puede salir después de que reciba la petición SIGTERM. Consulta Ciclo de vida de una aplicación para obtener más información.

Para ayudar a evitar bloqueos en la aplicación debido a condiciones de memoria insuficiente, vea los procedimientos recomendados para administrar el uso de RAM en aplicaciones de alto nivel.

Determinar el uso de RAM de la aplicación en tiempo de ejecución

Azure Sphere ofrece varias funciones para obtener información de uso de memoria en tiempo de ejecución. Puede usarlos para supervisar el uso de memoria de su aplicación de alto nivel, lo que le permite reiniciar la aplicación de forma segura si el uso de memoria supera un umbral que especifique dentro del límite de 256 KiB. Las funciones disponibles son:

  • Applications_GetTotalMemoryUsageInKB: Consigue el uso total de la memoria en los pagos. Este es el uso total de memoria física de la aplicación en el sistema, incluidas las asignaciones de kernel (como búferes para sockets) en nombre de la aplicación o el servidor de depuración, devuelto como un valor sin procesar (en KiB).
  • Applications_GetUserModeMemoryUsageInKB: Consigue el uso de memoria en modo usuario en el modo de análisis. Esta es la cantidad de memoria física usada directamente por la aplicación, la memoria que usan las bibliotecas en su nombre (también denominadas asignaciones anon ) y la memoria usada por el servidor de depuración, devuelta como un valor sin procesar (en KiB).
  • Applications_GetPeakUserModeMemoryUsageInKB: Consigue el máximo uso de memoria del modo de usuario en los mossos. Esta es la cantidad máxima de memoria de usuario usada en la sesión actual. Al probar el uso de memoria de la aplicación, debes asegurarte de que este valor nunca supere los 256 KiB. Este valor se restablece siempre que la aplicación se reinicia o se vuelve a implementar. Use esta función para obtener una mirada aproximada sobre lo cerca que su aplicación está llegando al límite recomendado de 256 KiB.

Para usar estas funciones en su aplicación de alto nivel, incluya el archivo de encabezado applications.h. Puede usar estas funciones durante el desarrollo para hacerse una idea del uso general de la memoria de la aplicación, pero también puede usarlas junto con el registro para capturar información de dispositivos en el campo. El fragmento de detección de uso excesivo de memoria y limpieza muestra cómo detectar y controlar correctamente el uso inesperado de memoria.

Nota

Estas funciones devuelven el uso de memoria como se ve en el sistema operativo. Actualmente, la liberación de memoria por una aplicación para las asignaciones en el montón de usuarios no es notificado por estas funciones. La memoria se devolverá a la biblioteca malloc para su uso futuro, pero las estadísticas informadas por el sistema operativo permanecen inalteradas a menos que la memoria haya sido asignada y liberada por el propio sistema operativo. Un ejemplo sería asignar memoria para un socket. Por lo tanto, estas funciones son útiles para comprender los peores escenarios para ayudar a su aplicación a funcionar de forma conservadora y obtener la máxima confiabilidad. Los valores son aproximados y pueden variar según las versiones del sistema operativo.

Agregar seguimiento de asignación de memoria de pila

Puede obtener información adicional de uso de memoria agregando un seguimiento de asignación de memoria de montón, que muestra qué asignaciones de usuario y kernel realizan las bibliotecas estáticas y vinculadas dinámicamente. Esto proporciona una imagen más completa de dónde la aplicación está usando la memoria para ayudarle a usarla de la manera más eficaz. Esta característica, disponible con la versión 21.07 o posterior del SO Azure Sphere y con la versión en tiempo de ejecución de la aplicación (ARV) 10 o posterior, solo funciona en un dispositivo habilitado para desarrollo y solo cuando la aplicación no se está ejecutando en el depurador.

Nota

Debe completar ambas tareas de configuración descritas en esta sección para que el seguimiento de asignación de memoria del montón funcione correctamente. Si no lo hace, se notificará una advertencia durante la compilación y no se mostrará información de memoria de montón.

Para habilitar el seguimiento de asignación de memoria de la pila, debe hacer dos cosas:

  • Agregue la funcionalidad HeapMemStats al archivo app-manifest.json de la aplicación:

      "Capabilities": {
    "HeapMemStats": true
  },

  • Agregue la biblioteca libmalloc al paquete de imagen agregando DEBUG_LIB "libmalloc" al comando en el azsphere_target_add_image archivo de CMakeLists.txt de la aplicación:

    azsphere_target_add_image_package(${PROJECT_NAME} DEBUG_LIB "libmalloc")

Importante

Dado que el seguimiento de asignación de memoria de montón solo funciona en dispositivos habilitados para desarrollo, debes hacer lo siguiente para quitarlo de la aplicación antes de crear paquetes de imagen para su implementación:

  • Elimine la línea '"HeapMemStats": true' del archivo app-manifest.json de la aplicación.
  • Quitar DEBUG_LIB "libmalloc" del azsphere_target_add_image_package(${PROJECT_NAME} DEBUG_LIB "libmalloc" comando del archivo de CMakeLists.txt de la aplicación.

Usar el generador de perfiles de rendimiento de Visual Studio

Si usa Visual Studio, puede usar su característica de perfilador de rendimiento para obtener información sobre el uso de memoria de la aplicación. Para obtener un tutorial que usa este generador de perfiles, consulte Tutoriales/MemoryUsage.

Requisitos previos

  • Un kit de desarrollo de Azure Sphere conectado a tu EQUIPO que ejecuta Visual Studio con el SDK de Azure Sphere instalado. Consulte Instalar Azure Sphere SDK para Windows.
  • Un dispositivo preparado para su desarrollo. Consulte az sphere device enable-development. El generador de perfiles de rendimiento no devolverá datos si el dispositivo no está habilitado para desarrollo.

Iniciar el generador de perfiles de uso de memoria

  1. Seleccione Depurar>perfil de rendimiento o presione Alt+F2 para abrir la ventana de inicio del generador de perfiles de rendimiento.

    Ventana de perfil de rendimiento de Visual Studio

  2. En Destino de análisis, si Azure Sphere Device Profiler no está visible, seleccione Elegir destino y seleccione Azure Sphere Device Profiler.

  3. En Herramientas disponibles, asegúrate de que la opción Uso de memoria de Azure Sphere esté activada y, a continuación, selecciona Iniciar para abrir la ventana de generación de perfiles de uso de memoria e iniciar el generador de perfiles de memoria.

  4. Si necesita implementar o reiniciar la aplicación, seleccione Depurar>inicio sin depuración o presione Ctrl+F5 para implementar la aplicación en el dispositivo.

    Importante

    Para obtener información de uso de RAM precisa para tu aplicación, es importante que [inicies la aplicación sin depuración](buid-hl-app.md#build-and-deploy-the-application-in-visual-studio-without-debugging). La ejecución de la aplicación en el depurador provocará un uso de RAM inflado, ya que la memoria consumida por el servidor de depuración se incluirá en las estadísticas de uso de RAM notificadas.

Interpretar los datos del generador de perfiles de uso de memoria

La ventana de generación de perfiles de uso de memoria muestra una vista similar a la siguiente:

Ventana del generador de perfiles de uso de memoria de Visual Studio

En el centro de la vista, un gráfico de memoria física de Azure Sphere Device traza tres estadísticas diferentes de uso de RAM (que se muestran al KiB más cercano) como tres líneas diferentes mientras se ejecuta la aplicación:

  • Total: El uso total de memoria física de la aplicación en el sistema, incluidas las asignaciones de kernel (como búferes para sockets) en nombre de la aplicación o el servidor de depuración.
  • Usuario: La cantidad de memoria física que usa directamente la aplicación, la memoria que usan las bibliotecas en su nombre (también denominadas asignaciones anon ) y la memoria que usa el servidor de depuración.
  • Usuario máximo: La cantidad máxima de memoria de usuario usada en la sesión actual. Al probar el uso de memoria de la aplicación, debes asegurarte de que este valor nunca supere los 256 KiB. La memoria adicional está reservada para las asignaciones de kernel. Este valor se restablece siempre que la aplicación se reinicia o se vuelve a implementar.

El gráfico también traza las repeticiones del evento New Peak (representado por un triángulo). Este evento se produce siempre que haya un nuevo máximo de uso de memoria de usuario máximo. El evento está habilitado para la accesibilidad del lector de pantalla.

Si ha habilitado el seguimiento de asignación de memoria de montón y la aplicación no se está ejecutando bajo el depurador, verá un gráfico adicional que muestra estadísticas de memoria de montón:

  • Total Heap: la memoria total de montón asignada por o en nombre de la aplicación, incluyendo de bibliotecas estáticas y dinámicas.
  • Shared Library Heap: Asignaciones de bibliotecas vinculadas dinámicamente proporcionadas por el sistema operativo Azure Sphere.

Uso de memoria de almacenamiento de Visual Studio

Encima de los gráficos, una vista de escala de tiempo muestra el tiempo de ejecución de la aplicación, correlacionado con los datos del siguiente gráfico. Use Acercar y Alejar para centrarse en períodos de tiempo específicos.

Debajo de los gráficos, una vista de tabla muestra las mismas estadísticas de memoria y eventos.

Propina

Para copiar datos de la tabla al Portapapeles, presione Ctrl+E para seleccionar todas las filas y, después, presione Ctrl+C.

Los dos primeros gráficos mostrados en esta sección se tomaron mientras se ejecutaba la fase 1 del tutorial uso de memoria, que contiene una pérdida de memoria. El uso de memoria aumenta monotónicamente en cada gráfico, lo que proporciona evidencia visual de la fuga. Cuando se corrige la fuga, como en la fase 2 del tutorial uso de memoria, el gráfico sube y cae a medida que se asigna la memoria y se desasigna.

Uso de memoria de almacenamiento de Visual Studio sin pérdida de memoria

Ver estadísticas sobre el uso total de memoria

El comando show-memory-stats de la aplicación az sphere device devuelve estadísticas de uso de memoria sobre el uso total de memoria, el uso del modo de usuario y el uso máximo del modo de usuario para las aplicaciones que se ejecutan en un dispositivo conectado. El dispositivo debe tener la funcionalidad appDevelopment device configurada para ejecutar este comando.

Las estadísticas de uso de RAM que se muestran mientras se ejecuta la aplicación son las siguientes:

  • Total (Kernel + Modo de usuario): el uso total de memoria física de la aplicación en el sistema, incluidas las asignaciones de kernel (como búferes para sockets) en nombre de la aplicación o del servidor de depuración.
  • Modo de usuario: la cantidad de memoria física usada directamente por la aplicación, la memoria que usan las bibliotecas en su nombre (también denominadas asignaciones anon ) y la memoria que usa el servidor de depuración.
  • Máximo de modo de usuario: la cantidad máxima de memoria de usuario usada en la sesión actual. Al probar el uso de memoria de la aplicación, debes asegurarte de que este valor nunca supere los 256 KiB. La memoria adicional está reservada para las asignaciones de kernel. Este valor se restablece siempre que la aplicación se reinicia o se vuelve a implementar.

Si ha habilitado el seguimiento de asignación de memoria de montón y la aplicación no se está ejecutando bajo el depurador, verá líneas adicionales de estadísticas de memoria de montón:

  • Heap: Aplicación + Bibliotecas estáticas: el kernel y las asignaciones de usuario del código y las bibliotecas vinculadas estáticamente a él.
  • Montón: <asignaciones dinámicas de bibliotecas>: asignaciones de bibliotecas individuales vinculadas dinámicamente proporcionadas por Azure Sphere OS.

Supervisión continua del uso de memoria

Para supervisar el uso de memoria con el tiempo, puedes usar scripts para ejecutar la aplicación [az sphere device show-memory-stats](.. Comando /reference/az sphere-device.md) en un bucle como se describe en los ejemplos siguientes:

Símbolo del sistema de Windows

Con el Bloc de notas u otro editor de texto, cree un archivo de script por lotes memuse.bat con el siguiente contenido:

@echo off

:loop
call az sphere device app show-memory-stats
choice /d y /t 1 > nul
goto loop

Ejecute el script por lotes escribiendo su nombre en el símbolo del sistema (o la ruta de acceso completa al archivo, si no está en el directorio actual):

C:\Users\username> memuse.bat
 -------------------------- -------------
 Name                       Usage (bytes)
 ========================================
 Total (Kernel + User Mode) 65536
 -------------------------- -------------
 User Mode                  36864
 -------------------------- -------------
 Peak User Mode             36864
 -------------------------- -------------
 -------------------------- -------------
 Name                       Usage (bytes)
 ========================================
 Total (Kernel + User Mode) 65536
 -------------------------- -------------
 User Mode                  36864
 -------------------------- -------------
 Peak User Mode             36864
 -------------------------- -------------

Para salir del script, escriba Ctrl+C en la ventana del símbolo del sistema y, a continuación, responda Y al mensaje "¿Finalizar trabajo por lotes?".

Windows PowerShell

while ($true) {
    az sphere device app show-memory-stats
    Start-Sleep -Seconds 1
}

Uso de memoria y el depurador

Al ejecutar la aplicación en el depurador, las estadísticas de memoria notificadas también incluyen el uso de memoria del proceso del servidor de depuración y otro uso adicional de memoria causado por la depuración, como la configuración de puntos de interrupción. Por este motivo, siempre debes ejecutar la aplicación sin depurar al intentar recopilar estadísticas de memoria precisas.

Sin embargo, usar el generador de perfiles de uso de memoria puede ser útil si ejecutas la aplicación con el depurador. Establecer puntos de interrupción y recorrer las líneas de código mientras observa cambios relativos en el consumo de memoria puede ser una técnica útil para identificar las causas de los picos de uso de memoria o pérdidas de memoria.

Al depurar en Visual Studio, el generador de perfiles de rendimiento se abre automáticamente, pero no muestra el seguimiento de asignación de memoria del montón.