Utilisation de la mémoire dans les applications générales
Important
Il s’agit de la documentation Azure Sphere (héritée). Azure Sphere (hérité) prend sa retraite le 27 septembre 2027 et les utilisateurs doivent migrer vers Azure Sphere (intégré) pour l’instant. Utilisez le sélecteur de version situé au-dessus du TOC pour afficher la documentation Azure Sphere (intégrée).
Cette rubrique fournit des détails sur l’utilisation de la mémoire dans les applications générales. 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 générales ont accès à la mémoire et au stockage suivants :
- 256 Kio de RAM sur le cœur général, réservés entièrement à l’utilisation des applications générales. Jusqu’à 1 Kio de cet espace peut être alloué pour chaque canal de mémoire tampon partagée par le biais duquel les applications générales et RTApp communiquent.
- 1 Mio de mémoire flash en lecture seule, qui est partagé entre les cœurs généraux et en temps réel.
- Le stockage (mutable) en lecture/écriture, qui persiste au redémarrage d’un appareil. Pour plus d’informations sur le stockage mutable, consultez Utilisation du stockage sur Azure Sphere.
Remarque
À plusieurs reprises, la mise à jour du flash l’a porté et la 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 l’utilisation de la mémoire flash, envisagez uniquement la taille du fichier de package d’image qui inclut les métadonnées d’image, le manifeste de l’application et l’image exécutable. Vous n’avez pas besoin de prendre en compte le 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 hub Azure IoT. De même, vous n’avez pas besoin d’inclure la taille d’une copie de sauvegarde complète de votre application ou des composants qui activent le basculement ou la restauration en cas d’altération ou de problèmes liés aux mises à jour en mode over-the-air.
Toutefois, durant le développement et le débogage, la taille du débogueur entre en compte dans la limite. Le débogueur est automatiquement ajouté par azsphere device enable-development et supprimé par azsphere device enable-cloud-test. Vous trouverez la taille du débogueur utilisé par votre KIT de développement logiciel (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 azsphere device sideload retourne une erreur si le package d’image de l’application et le débogueur (le cas échéant) dépassent la limite totale de 1 Mio. La commande azsphere image add --image qui charge une nouvelle image sur votre locataire Azure Sphere retourne également une erreur si le package d’image dépasse 1 Mio.
La limite de ram de 256 KiB s’applique uniquement à l’application ; vous n’avez pas besoin d’autoriser la RAM utilisée par le débogueur. La mémoire supplémentaire est réservée aux allocations de noyau.
Le flash disponible et la RAM peuvent augmenter (mais ne diminueront jamais) pour les applications écrites pour la puce Azure Sphere actuelle (MT3620). Les futurs processeurs Azure Sphere pourront 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 voyez s’afficher ce qui suit :
Child terminated with signal = 0x9 (SIGKILL)
Le signal SIGKILL se produit également si une application de haut niveau ne parvient pas à se quitter une fois qu’elle reçoit la requête SIGTERM. Pour plus d’informations, consultez Cycle de vie d’une application .
Pour éviter les blocages dans votre application en raison d’une condition de 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 d’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 Kib. 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ées sous forme de valeur brute (en KiB).
- Applications_GetUserModeMemoryUsageInKB : obtenez 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 toutes les bibliothèques pour son compte (également appelées allocations anon ) et de la mémoire utilisée par le serveur de débogage, retournée en tant que valeur brute (en KiB).
- 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 Kib. 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 fermeture de votre application à la limite recommandée de 256 Kib.
Pour utiliser ces fonctions dans votre application de haut niveau, 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 dans le champ. L’extrait de code Détection et nettoyage de la mémoire permet de détecter et de gérer correctement l’utilisation inattendue de la mémoire.
Remarque
Ces fonctions retournent l’utilisation de la mémoire comme indiqué par le système d’exploitation. Actuellement, la libération de la 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 signalé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. Un exemple serait l’allocation de mémoire pour un socket. Par conséquent, ces fonctions sont utiles pour comprendre les pires scénarios pour aider votre application à fonctionner de manière conservatrice pour une fiabilité maximale. Les valeurs sont approximatives et peuvent varier entre les versions du système d’exploitation.
Ajouter le suivi de l’allocation de mémoire du segment de mémoire
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, ce qui indique les allocations utilisateur et noyau effectuées par des 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 plus efficacement. Cette fonctionnalité, disponible avec le système d’exploitation Azure Sphere version 21.07 ou ultérieure et la version d’exécution d’application (ARV) 10 ou ultérieure, fonctionne uniquement sur un appareil prenant en charge le développement et uniquement lorsque l’application ne s’exécute pas sous le débogueur.
Remarque
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 leazsphere_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 prenant en charge le développement, vous devez effectuer les opérations suivantes pour la 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 leazsphere_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 Tutoriels/MemoryUsage.
Prérequis
- Un kit de développement Azure Sphere connecté à votre PC exécutant Visual Studio avec le Kit de développement logiciel (SDK) Azure Sphere installé. Consultez Installer le Kit de développement logiciel (SDK) Azure Sphere pour Windows.
- Un appareil préparé pour le développement. Consultez azsphere device enable-development. Le profileur de performances ne retourne pas de données si votre appareil n’est pas activé pour le développement.
Démarrer le profileur d’utilisation de la mémoire
Sélectionnez Déboguer>le profileur de performances ou appuyez sur Alt+F2 pour ouvrir la fenêtre de démarrage du profileur de performances.
Sous Cible d’analyse, si Azure Sphere Device Profiler n’est pas visible, sélectionnez Choisir la cible et sélectionnez Azure Sphere Device Profiler.
Sous Outils disponibles, vérifiez que l’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.
Si vous devez déployer ou redémarrer votre application, sélectionnez 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-débogage). L’exécution de votre application sous le débogueur entraîne une utilisation gonflée 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 un affichage semblable à ce qui suit :
Au centre de la vue, un graphe mémoire physique d’appareil Azure Sphere trace trois statistiques d’utilisation de RAM différentes (affichées au kib 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 de pointe : 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 Kib. La 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 utilisateur maximale. 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 :
- Total Heap : 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èques partagées : allocations à partir de bibliothèques liées dynamiquement fournies par le système d’exploitation Azure Sphere.
Au-dessus des graphiques, une vue chronologie affiche l’heure d’exécution de votre application, corrélée avec les données du graphique ci-dessous. Utilisez zoom avant et 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.
Conseil
Pour copier des données du tableau dans 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 augmente monotoniquement dans chaque graphique, fournissant des preuves visuelles pour la fuite. Lorsque la fuite est corrigée, comme dans l’étape 2 du didacticiel Utilisation de la mémoire, le graphique augmente et tombe à mesure que la mémoire est allouée et libérée.
Afficher les statistiques sur l’utilisation totale de la mémoire
La commande azsphere device app show-memory-stats retourne les statistiques d’utilisation de la mémoire sur l’utilisation totale de la mémoire, l’utilisation du mode utilisateur et l’utilisation en mode utilisateur maximale pour les applications s’exécutant sur un appareil attaché. L’appareil doit avoir la fonctionnalité d’appareil appDevelopment 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 Kib. La 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 : Bibliothèques statiques d’application : noyau et allocations utilisateur à partir de votre code et de toutes les bibliothèques qui y sont liées statiquement.
- Tas : <allocations de bibliothèques dynamiques : allocations> provenant 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 la commande azsphere device app show-memory-stats 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 batch memuse.bat avec le contenu suivant :
@echo off
:loop
call azsphere device app show-memory-stats
choice /d y /t 1 > nul
goto loop
Exécutez le script batch en tapant son nom à l’invite de commandes (ou le chemin complet du fichier, s’il n’est 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) {
azsphere device app show-memory-stats
Start-Sleep -Seconds 1
}
Utilisation de la mémoire et 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 de 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 pas à pas de lignes de code tout en observant les modifications relatives de la consommation de mémoire peuvent être une technique utile 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 tas.