Utilisation de la mémoire dans les applications de haut niveau

  • Article

Cette rubrique fournit des détails sur l’utilisation de la mémoire dans les applications de haut niveau. Pour plus d’informations sur la mémoire disponible pour les applications en temps réel (RTApps), consultez Gérer la mémoire et la latence .

Les applications de haut niveau ont accès à la mémoire et au stockage suivants :

  • 256 Kio de RAM sur le cœur de haut niveau, entièrement réservés à une utilisation d’application de haut niveau. Jusqu’à 1 Kio de cet espace peut être alloué pour chaque canal de mémoire tampon partagée via lequel les applications de haut niveau et les applications en temps réel communiquent.
  • 1 Mio de mémoire flash en lecture seule, qui est partagée entre les cœurs de haut niveau et en temps réel.
  • Stockage en lecture/écriture (mutable), qui persiste lors du redémarrage d’un appareil. Pour plus d’informations sur le stockage mutable, consultez Utilisation du stockage sur Azure Sphere.

Note

La mise à jour répétée du flash finit par l’épuiser et le rend non valide. Par conséquent, vous devez concevoir votre code pour éviter les mises à jour inutiles du flash. Par exemple, si vous souhaitez enregistrer l’état de votre application avant de quitter afin de pouvoir récupérer l’état enregistré après un redémarrage, envisagez d’enregistrer l’état de l’application dans le flash uniquement si l’état a changé.

Déterminer l’utilisation de la mémoire flash

Pour déterminer votre utilisation de la mémoire Flash, tenez compte uniquement de la taille du fichier de package d’image qui inclut les métadonnées de l’image, le manifeste d’application et l’image exécutable. Vous n’avez pas besoin de tenir compte du stockage requis par les composants fournis par Microsoft, tels que le système d’exploitation Azure Sphere ou les services d’exécution et les bibliothèques partagées qui contrôlent les périphériques et activent la connexion à un Azure IoT Hub. De même, vous n’avez pas besoin d’inclure la taille d’une copie de sauvegarde complète de votre application ou les composants qui activent le basculement ou la restauration en cas d’altération ou de problèmes liés aux mises à jour ota.

Toutefois, pendant le développement et le débogage, la taille du débogueur est comptabilisée par rapport à la limite. Le débogueur est automatiquement ajouté par az sphere device enable-development et supprimé par [az sphere device enable-cloud-test](.. /reference/az sphere-device.md). Vous trouverez la taille du débogueur utilisé par votre SDK en recherchant gdbserver.imagepackage dans le dossier DebugTools du répertoire d’installation du Kit de développement logiciel (SDK) Microsoft Azure Sphere.

La commande az sphere device sideload retourne une erreur si le package d’image d’application et le débogueur (le cas échéant) dépassent la limite totale de 1 Mio. La commande az sphere image add --image qui charge une nouvelle image dans votre catalogue Azure Sphere retourne également une erreur si le package d’image dépasse 1 Mio.

La limite de 256 Kio de RAM s’applique uniquement à l’application ; vous n’avez pas besoin d’autoriser la RAM utilisée par le débogueur. Une mémoire supplémentaire est réservée aux allocations de noyau.

La mémoire flash et la RAM disponibles peuvent augmenter (mais ne diminueront jamais) pour les applications écrites pour la puce Azure Sphere actuelle (MT3620). Les futures puces Azure Sphere peuvent avoir des limites différentes.

Conditions de mémoire insuffisante

Si votre application utilise trop de RAM, le système d’exploitation Azure Sphere l’arrête avec un signal SIGKILL. Par exemple, dans le débogueur, vous verrez les éléments suivants :

Child terminated with signal = 0x9 (SIGKILL)

Le signal SIGKILL se produit également si une application de haut niveau ne parvient pas à se fermer après avoir reçu la requête SIGTERM. Pour plus d’informations, consultez Cycle de vie d’une application .

Pour éviter les incidents dans votre application en raison d’une mémoire insuffisante, consultez les meilleures pratiques pour gérer l’utilisation de la RAM dans les applications de haut niveau.

Déterminer l’utilisation de la RAM de l’application au moment de l’exécution

Azure Sphere fournit plusieurs fonctions pour obtenir des informations sur l’utilisation de la mémoire au moment de l’exécution. Vous pouvez les utiliser pour surveiller l’utilisation de la mémoire de votre application de haut niveau, ce qui vous permet de redémarrer votre application en toute sécurité si l’utilisation de la mémoire dépasse un seuil que vous spécifiez dans la limite de 256 Kio. Les fonctions disponibles sont les suivantes :

  • Applications_GetTotalMemoryUsageInKB : obtenez l’utilisation totale de la mémoire en Kibioctets. Il s’agit de l’utilisation totale de la mémoire physique de votre application sur le système, y compris les allocations de noyau (telles que les mémoires tampons pour les sockets) pour le compte de votre application ou du serveur de débogage, retournée sous forme de valeur brute (en Kio).
  • Applications_GetUserModeMemoryUsageInKB : obtenir l’utilisation de la mémoire en mode utilisateur en Kibioctets. Il s’agit de la quantité de mémoire physique utilisée directement par votre application, de la mémoire utilisée par les bibliothèques en son nom (également appelées allocations anon ) et de la mémoire utilisée par le serveur de débogage, retournée sous forme de valeur brute (en Kio).
  • Applications_GetPeakUserModeMemoryUsageInKB : obtenez l’utilisation maximale de la mémoire en mode utilisateur en Kibioctets. Il s’agit de la quantité maximale de mémoire utilisateur utilisée dans la session active. Lorsque vous testez l’utilisation de la mémoire de votre application, vous devez vous assurer que cette valeur ne dépasse jamais 256 Kio. Cette valeur est réinitialisée chaque fois que votre application redémarre ou est redéployée. Utilisez cette fonction pour obtenir un aperçu approximatif de la limite recommandée de 256 Kio pour votre application.

Pour utiliser ces fonctions dans votre application générale, incluez le fichier d’en-tête applications.h. Vous pouvez utiliser ces fonctions pendant le développement pour avoir une idée de l’utilisation globale de la mémoire de votre application, mais vous pouvez également les utiliser avec la journalisation pour capturer des informations à partir d’appareils sur le terrain. L’extrait de code Détection et nettoyage de la surutilisation de la mémoire montre comment détecter et gérer correctement l’utilisation inattendue de la mémoire.

Note

Ces fonctions retournent l’utilisation de la mémoire telle qu’elle est vue par le système d’exploitation. Actuellement, la libération de mémoire par une application pour les allocations sur le tas utilisateur n’est pas signalée par ces fonctions. La mémoire sera retournée à la bibliothèque malloc pour une utilisation ultérieure, mais les statistiques communiquées par le système d’exploitation restent inchangées, sauf si la mémoire a été allouée et libérée par le système d’exploitation lui-même. Par exemple, l’allocation de mémoire pour un socket. Par conséquent, ces fonctions sont utiles pour comprendre les pires scénarios afin d’aider votre application à fonctionner de manière prudente pour une fiabilité maximale. Les valeurs sont approximatives et peuvent varier d’une version du système d’exploitation à l’autre.

Ajouter le suivi de l’allocation de mémoire du tas

Vous pouvez obtenir des informations supplémentaires sur l’utilisation de la mémoire en ajoutant le suivi de l’allocation de mémoire du tas, qui indique les allocations d’utilisateur et de noyau effectuées par les bibliothèques statiques et liées dynamiquement. Cela fournit une image plus complète de l’endroit où la mémoire est utilisée par votre application pour vous aider à l’utiliser le plus efficacement possible. Cette fonctionnalité, disponible avec le système d’exploitation Azure Sphere version 21.07 ou ultérieure et la version du runtime d’application (ARV) 10 ou ultérieure, fonctionne uniquement sur un appareil activé pour le développement et uniquement lorsque l’application ne s’exécute pas sous le débogueur.

Note

Vous devez effectuer les deux tâches de configuration décrites dans cette section pour que le suivi de l’allocation de mémoire du tas fonctionne correctement. Si vous ne le faites pas, un avertissement est signalé pendant la compilation et les informations de mémoire du tas ne s’affichent pas.

Pour activer le suivi de l’allocation de mémoire du tas, vous devez effectuer deux opérations :

  • Ajoutez la fonctionnalité HeapMemStats au fichier app-manifest.json de votre application :

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

  • Ajoutez la bibliothèque libmalloc à votre package d’images en ajoutant DEBUG_LIB "libmalloc" à la commande dans le azsphere_target_add_image fichier CMakeLists.txt de votre application :

    azsphere_target_add_image_package(${PROJECT_NAME} DEBUG_LIB "libmalloc")

Important

Étant donné que le suivi de l’allocation de mémoire du tas fonctionne uniquement sur les appareils compatibles avec le développement, vous devez effectuer les opérations suivantes pour le supprimer de votre application avant de créer des packages d’images pour le déploiement :

  • Supprimez la ligne « HeapMemStats » : true » du fichier app-manifest.json de votre application.
  • Supprimez DEBUG_LIB "libmalloc" de la commande dans le azsphere_target_add_image_package(${PROJECT_NAME} DEBUG_LIB "libmalloc" fichier CMakeLists.txt de votre application.

Utiliser le profileur de performances Visual Studio

Si vous utilisez Visual Studio, vous pouvez utiliser sa fonctionnalité de profileur de performances pour obtenir des informations sur l’utilisation de la mémoire de l’application. Pour obtenir un didacticiel qui utilise ce profileur, consultez Tutorials/MemoryUsage.

Conditions préalables

Démarrer le profileur d’utilisation de la mémoire

  1. Sélectionnez Debug>Performance Profiler ou appuyez sur Alt+F2 pour ouvrir la fenêtre de démarrage du profileur de performances.

    Fenêtre du profileur de performances Visual Studio

  2. Sous Cible d’analyse, si Azure Sphere Device Profiler n’est pas visible, sélectionnez Choisir la cible , puis Azure Sphere Device Profiler.

  3. Sous Outils disponibles, vérifiez que l’option Utilisation de la mémoire Azure Sphere est cochée, puis sélectionnez Démarrer pour ouvrir la fenêtre de profilage de l’utilisation de la mémoire et démarrer le profileur de mémoire.

  4. Si vous devez déployer ou redémarrer votre application, sélectionnez Déboguer>Démarrer sans débogage ou appuyez sur Ctrl+F5 pour déployer votre application sur l’appareil.

    Important

    Pour obtenir des informations précises sur l’utilisation de la RAM pour votre application, il est important que vous [démarrez votre application sans débogage](buid-hl-app.md#build-and-deploy-the-application-in-visual-studio-without-debugging). L’exécution de votre application sous le débogueur entraîne une augmentation de l’utilisation de la RAM, car la mémoire consommée par le serveur de débogage sera incluse dans les statistiques d’utilisation de la RAM signalées.

Interprétation des données du profileur d’utilisation de la mémoire

La fenêtre de profilage de l’utilisation de la mémoire affiche une vue semblable à celle-ci :

Fenêtre du profileur d’utilisation de la mémoire Visual Studio

Au centre de la vue, un graphique mémoire physique d’appareil Azure Sphere trace trois statistiques d’utilisation de la RAM différentes (affichées au Kio le plus proche) sous la forme de trois lignes différentes pendant l’exécution de votre application :

  • Total: Utilisation totale de la mémoire physique de votre application sur le système, y compris les allocations de noyau (telles que les mémoires tampons pour les sockets) pour le compte de votre application ou du serveur de débogage.
  • Utilisateur: Quantité de mémoire physique utilisée directement par votre application, mémoire utilisée par toutes les bibliothèques en son nom (également appelées allocations anon ) et mémoire utilisée par le serveur de débogage.
  • Utilisateur maximal : Quantité maximale de mémoire utilisateur utilisée dans la session active. Lorsque vous testez l’utilisation de la mémoire de votre application, vous devez vous assurer que cette valeur ne dépasse jamais 256 Kio. Une mémoire supplémentaire est réservée aux allocations de noyau. Cette valeur est réinitialisée chaque fois que votre application redémarre ou est redéployée.

Le graphique trace également les occurrences de l’événement New Peak (représenté par un triangle). Cet événement se produit chaque fois qu’il existe un nouveau maximum pour l’utilisation de la mémoire de l’utilisateur maximal. L’événement est activé pour l’accessibilité du lecteur d’écran.

Si vous avez activé le suivi de l’allocation de mémoire du tas et que votre application ne s’exécute pas sous le débogueur, vous verrez un graphique supplémentaire montrant les statistiques de mémoire du tas :

  • Tas total : mémoire de tas totale allouée par ou pour le compte de votre application, y compris à partir de bibliothèques statiques et dynamiques.
  • Tas de bibliothèque partagée : allocations à partir de bibliothèques liées dynamiquement fournies par le système d’exploitation Azure Sphere.

Utilisation de la mémoire du tas Visual Studio

Au-dessus des graphiques, une vue chronologie affiche le temps d’exécution de votre application, corrélé aux données du graphique ci-dessous. Utilisez Zoom avant et Zoom arrière pour vous concentrer sur des périodes spécifiques.

Sous les graphiques, une vue de tableau affiche les mêmes statistiques et événements de mémoire.

Pointe

Pour copier des données de la table vers le Presse-papiers, appuyez sur Ctrl+A pour sélectionner toutes les lignes, puis appuyez sur Ctrl+C.

Les deux premiers graphiques présentés dans cette section ont été pris lors de l’exécution de l’étape 1 du didacticiel Utilisation de la mémoire, qui contient une fuite de mémoire. L’utilisation de la mémoire grimpe de manière monotone dans chaque graphique, fournissant une preuve visuelle de la fuite. Lorsque la fuite est corrigée, comme à l’étape 2 du didacticiel Utilisation de la mémoire, le graphique augmente et diminue à mesure que la mémoire est allouée et libérée.

Utilisation de la mémoire du tas Visual Studio sans fuite de mémoire

Afficher les statistiques sur l’utilisation totale de la mémoire

La commande az sphere device app show-memory-stats retourne des statistiques d’utilisation de la mémoire sur l’utilisation totale de la mémoire, l’utilisation du mode utilisateur et l’utilisation maximale du mode utilisateur pour les applications s’exécutant sur un appareil attaché. La fonctionnalité d’appareil appDevelopment doit être configurée pour exécuter cette commande.

Les statistiques d’utilisation de la RAM affichées pendant l’exécution de votre application sont les suivantes :

  • Total (noyau + mode utilisateur) : utilisation totale de la mémoire physique de votre application sur le système, y compris les allocations de noyau (telles que les mémoires tampons pour les sockets) pour le compte de votre application ou du serveur de débogage.
  • Mode utilisateur : quantité de mémoire physique utilisée directement par votre application, mémoire utilisée par toutes les bibliothèques en son nom (également appelées allocations anon ) et mémoire utilisée par le serveur de débogage.
  • Mode utilisateur maximal : quantité maximale de mémoire utilisateur utilisée dans la session active. Lorsque vous testez l’utilisation de la mémoire de votre application, vous devez vous assurer que cette valeur ne dépasse jamais 256 Kio. Une mémoire supplémentaire est réservée aux allocations de noyau. Cette valeur est réinitialisée chaque fois que votre application redémarre ou est redéployée.

Si vous avez activé le suivi de l’allocation de mémoire du tas et que votre application ne s’exécute pas sous le débogueur, vous verrez des lignes supplémentaires de statistiques de mémoire du tas :

  • Tas : Applications + Bibliothèques statiques : allocations de noyau et d’utilisateurs à partir de votre code et toutes les bibliothèques qui y sont liées statiquement.
  • Tas : <allocations de bibliothèque dynamiques : allocations> à partir de bibliothèques liées dynamiquement individuelles fournies par le système d’exploitation Azure Sphere.

Surveillance continue de l’utilisation de la mémoire

Pour surveiller l’utilisation de la mémoire au fil du temps, vous pouvez utiliser des scripts pour exécuter [az sphere device app show-memory-stats](.. Commande /reference/az sphere-device.md) dans une boucle, comme décrit dans les exemples suivants :

Invite de commandes Windows

À l’aide du Bloc-notes ou d’un autre éditeur de texte, créez un fichier de script par lots memuse.bat avec le contenu suivant :

@echo off

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

Exécutez le script de traitement par lots en tapant son nom à l’invite de commandes (ou le chemin d’accès complet au fichier, s’il ne se trouve pas dans le répertoire actif) :

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
 -------------------------- -------------

Pour quitter le script, tapez Ctrl+C dans la fenêtre d’invite de commandes , puis répondez Y à l’invite « Terminer le travail par lot ? ».

Windows PowerShell

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

Utilisation de la mémoire et du débogueur

Lors de l’exécution de votre application sous le débogueur, les statistiques de mémoire signalées incluent également l’utilisation de la mémoire du processus serveur de débogage et d’autres utilisations supplémentaires de la mémoire provoquées par le débogage, telles que la définition de points d’arrêt. Pour cette raison, vous devez toujours exécuter votre application sans débogage lorsque vous essayez de collecter des statistiques de mémoire précises.

Toutefois, l’utilisation du profileur d’utilisation de la mémoire peut être utile si vous exécutez votre application avec le débogueur. La définition de points d’arrêt et l’exécution de lignes de code tout en observant les modifications relatives de la consommation de mémoire peuvent être utiles pour identifier les causes des pics d’utilisation de la mémoire ou des fuites de mémoire.

Lors du débogage dans Visual Studio, le profileur de performances s’ouvre automatiquement, mais n’affiche pas le suivi de l’allocation de mémoire du segment de mémoire.