Audit de la mémoire du Jetson

Instantané axé sur la mémoire morte (ROM) pour un Jetson, ainsi que l'utilitaire « drop_caches » de la boucle de vérification qui confirme que la mémoire libérée apparaît bien comme libre et non comme mise en cache.

Objectif

Mesurer les consommateurs actuels de mémoire sur le Jetson, capturer des valeurs de référence avant/après, et vérifier si les modifications approuvées par l’utilisateur ont effectivement libéré de la DRAM. Utiliser les données en temps réel de l’appareil plutôt que des estimations basées sur la taille des conteneurs, la taille des modèles ou la mémoire générique des processus.

CRITIQUE : la mémoire semble bloquée après l'arrêt de vLLM / sglang (JetPack inférieur à la version 7.2 / L4T inférieur à la version r39.0)

Il s’agit de la confusion la plus courante concernant la mémoire sur les versions de Jetson antérieures à JetPack 7.2 ou à L4T r39.0.

Après avoir arrêté un serveur vLLM, sglang ou Ollama (ou toute charge de travail CUDA), la mémoire affichée comme libre par la commande `free -h` ou par `tegrastats` peut ne pas être libérée — même si le processus a cessé d’exister. La commande `nvidia-smi` peut également afficher un niveau de mémoire GPU libre trompeusement bas.

Cause première : le gestionnaire de ressources (RM) Thor conserve les pages de mémoire système libérées dans son propre pool après la fermeture d’un contexte CUDA. Sur les appareils dotés d’une architecture à mémoire unifiée (UMA) comme le Jetson, la commande `cudaMemGetInfo` lit l’état du pool du RM et indique une quantité de mémoire libre bien inférieure à celle réellement disponible pour un nouveau processus.

Solution de contournement (pour JetPack antérieur à la version 7.2 ou L4T antérieur à la version r39.0) :

sudo sync && sudo sysctl -w vm.drop_caches=3

Exécutez cette commande sur l’hôte, et non à l’intérieur d’un conteneur. L’opération importante est sudo sysctl -w vm.drop_caches=3; veillez à exécuter sudo sync immédiatement avant celle-ci afin que les données non validées soient vidées avant que les caches de pages, de dentry et d’inode récupérables ne soient supprimés. Une fois cette commande exécutée, les commandes ` free -h ` et ` tegrastats ` afficheront la mémoire réellement disponible.

Pour les versions concernées, il est recommandé d’utiliser cette commande lorsqu’un utilisateur signale :

• « La mémoire n’a pas été libérée après l’arrêt de vLLM/sglang »
• « Pourquoi tegrastats affiche-t-il toujours une utilisation élevée après la fermeture de mon conteneur ? »
• « Erreur OOM alors que rien ne s’exécute »
• « La mémoire fonctionnait bien hier, mais elle est désormais pleine »

Sur JetPack antérieur à la version 7.2 ou L4T antérieur à la version r39.0, la commande `drop_caches` constitue une solution de contournement fiable lorsque la mémoire semble bloquée après la fin d’une charge de travail CUDA ; sur les versions plus récentes, n’utilisez-la que si le même symptôme est observé et que l’utilisateur donne son accord.

Quand l’utiliser

• « Quelle quantité de mémoire est utilisée sur ce Jetson ? Qu'est-ce qui l'occupe ? »
• « J’ai désactivé l’interface graphique / arrêté vLLM / quitté mon conteneur — la mémoire a-t-elle réellement été libérée ? »
• « Pourquoi la commande free -h indique-t-elle toujours un faible niveau de mémoire libre après l’arrêt de ma charge de travail ? »
• Comme référence avant d’appliquer jetson-headless-mode ou d’autres modifications liées à la mémoire, puis à nouveau après pour calculer le delta réel.

Prérequis

• Exécutez cette commande sur l’hôte Jetson, ou dans un bac à sable/conteneur où l’hôte a accès aux répertoires /proc, /etc/nv_tegra_release, tegrastats et aux données des processus.
• La lecture de NvMap debugfs peut nécessiter les droits root. Si cela n’est pas possible, signalez que l’attribution de mémoire GPU est limitée plutôt que de faire des suppositions.
• Le script `drop_caches.sh` nécessite les droits root ou l’utilisation de `sudo -n` sans mot de passe ; ne l’exécutez qu’après que l’utilisateur a explicitement autorisé la suppression des caches.

Scripts disponibles

Si votre environnement d'exécution d'agent prend en charge la commande run_script, utilisez-la pour exécuter scripts/audit.sh ou scripts/drop_caches.sh et résumez la sortie renvoyée. Sinon, exécutez les scripts avec bash depuis la racine du référentiel.

Instructions

Pour répondre à la question « Quelle quantité de mémoire est actuellement utilisée ? », exécutez scripts/audit.sh et ne rapportez que les valeurs issues de l’instantané JSON.

Consignes de rapport

Ne vous contentez pas d’afficher ou de mentionner le chemin d’accès à un utilitaire. Lancez l’utilitaire, puis résumez les données renvoyées.

• Pour les demandes du type « Quelle quantité de mémoire est utilisée ? », exécutez scripts/audit.sh et indiquez les valeurs de mem_total_gb, memory_kb.available, ainsi que le processus procrank_top en tête ou le consommateur nvmap.top_clients.
• Pour les demandes concernant la mémoire de l’interface graphique/du bureau, exécutez scripts/audit.sh et indiquez default_systemd_target ainsi que tout gestionnaire d’affichage présent dans candidate_services (gdm3, gdm, lightdm, sddm ou display-manager). Ne désactivez rien ; remettez la question à jetson-headless-mode pour qu’il propose une solution.
• Pour les invites autorisant explicitement la suppression du cache après l’arrêt d’une charge de travail, exécutez scripts/drop_caches.sh (équivalent à sudo sync && sudo sysctl -w vm.drop_caches=3 par défaut) et signalez les écarts avant/après en termes de mémoire libre, de mémoire disponible et de mémoire mise en cache. Si l’utilisateur root n’est pas disponible, précisez que la commande doit être exécutée sur l’hôte à l’aide de sudo.

Si le runtime de votre agent n’exécute pas les scripts d’assistance relatifs à ce répertoire de compétences, résolvez les chemins d’accès aux scripts à l’aide de l’espace réservé AgentSkills {baseDir}:

{baseDir}/scripts/audit.sh
{baseDir}/scripts/drop_caches.sh

N’utilisez pas jetson-memory-audit comme nom d’outil, sauf si le runtime enregistre explicitement les compétences en tant qu’outils appelables ; les compétences d’agent sont normalement des instructions associées à des fichiers, et non des fonctions d’outils directes.

Remarque concernant le bac à sable pour les agents : le fait de voir ce fichier de compétence ne garantit pas l’accès aux données de la mémoire de l’hôte Jetson. Si /proc/device-tree/model, /etc/nv_tegra_release, tegrastats, /sys/kernel/debug/nvmap ou les données des processus de l’hôte sont absentes au sein d’un bac à sable NemoClaw/OpenClaw, indiquez que le bac à sable ne dispose pas de visibilité sur l’hôte Jetson et demandez à l’utilisateur d’exécuter le script sur l’hôte Jetson ou de relancer l’opération avec un profil de bac à sable offrant une visibilité sur l’hôte. Ne fabriquez pas de chiffres concernant la mémoire totale, la mémoire disponible, le PSS, le NvMap ou les deltas de récupération de mémoire.

Pour répondre aux questions du type « Quelle quantité de mémoire cette modification a-t-elle libérée ? », utilisez un delta avant/après. N’estimez pas la mémoire libérée à partir de la taille du conteneur, de la taille de l’image, du RSS ou d’un simple instantané postérieur à la modification.

1. Avant la modification, exécutez le script audit.sh et enregistrez la référence JSON.
2. Effectuez la modification approuvée par l’utilisateur (arrêtez le conteneur, changez de mode, appliquez une recommandation d’optimisation, etc.).
3. Sur JetPack antérieur à la version 7.2 / L4T antérieur à la version r39.0, ou lorsque le même symptôme de mémoire bloquée est observé sur une version plus récente, videz le cache de pages récupérables sur l’hôte (et non à l’intérieur d’un conteneur) afin que les pages libérées apparaissent comme libres plutôt que mises en cache :

   sudo sync && sudo sysctl -w vm.drop_caches=3
   
   

4. Relancez le script scripts/audit.sh et comparez la valeur de memory_kb.available avant et après — cet écart correspond à la quantité de mémoire réellement récupérée.

Si l’utilisateur a déjà effectué la modification et qu’aucune référence n’existe, indiquez que la quantité exacte de mémoire libérée ne peut pas être déterminée à partir du seul instantané actuel. Enregistrez une nouvelle référence dès maintenant afin de pouvoir mesurer la prochaine modification.

Utilisez les données d’audit en temps réel comme source de référence. Les totaux de mémoire, la mémoire disponible, les totaux NvMap, les valeurs PSS, l'état du gestionnaire d'affichage et les écarts d'économies doivent provenir de scripts/audit.sh, de la commande free -h ou de tegrastats sur l'appareil concerné. Si une valeur n'apparaît pas dans ces résultats, ne la devinez pas.

Exemple de sortie pour audit.sh

{
  "sku" : "orin-nano",
  "variant" : "orin-nano-8gb",
  "mem_total_gb" : 8,
  "l4t_version" : "36.4.0",
  "product_model": "nvidia jetson orin nano developer kit",
  "memory_kb": { "total": 8123456, "available": 4123456, "free": 1023456, "cached": 1234567, "swap_total" : 0, "swap_free" : 0 },
  "default_systemd_target" : "graphical.target",
  "candidate_services" : { "gdm3" : { "active" : "active", "enabled" : "enabled" } },
  "tegrastats_sample" : "RAM 4011/8138 Mo (lfb 8x4 Mo) ...",
  "nvmap" : { "readable" : false, "total_kb" : 0, "top_clients" : [] },
  "procrank_top" : [ { "pid" : 4321, "pss_kb" : 4000000, "cmd" : "vllm" } ]
}

Limites

• Pour obtenir des deltas précis de mémoire libérée, il faut disposer d’un instantané « avant », de la modification approuvée par l’utilisateur, d’un vidage du cache le cas échéant, et d’un instantané « après ».
• L’attribution NvMap dépend de l’accès au debugfs visible par l’hôte ; s’il n’est pas disponible, signalez une attribution limitée de la mémoire GPU plutôt que de faire des estimations.
• Les exécutions en sandbox ou en conteneur peuvent ne pas avoir accès aux données /proc, tegrastats, systemd ou NvMap de l’hôte, à moins que l’environnement d’exécution ne les expose.

Gestion des erreurs

• Si le script `scripts/audit.sh` ne parvient pas à accéder aux données du Jetson hôte, signalez l’absence de visibilité et demandez de relancer le script sur le Jetson hôte ou dans un bac à sable accessible depuis l’hôte.
• Si le script scripts/drop_caches.sh ne dispose pas des droits root ou d’un sudo -n sans mot de passe, signalez que la suppression du cache doit être effectuée sur l’hôte avec l’autorisation sudo.
• S’il n’existe aucun instantané antérieur, indiquez que le volume exact récupéré ne peut être déterminé à partir de l’état actuel seul et enregistrez une nouvelle référence pour la prochaine modification.

Sécurité

En lecture seule. La commande `drop_caches` est non destructive (le noyau ne libère de toute façon que les pages qu’il pourrait récupérer en cas de pression ; la commande `sync` s’exécute en premier pour préserver les données modifiées).

Transfert vers

• jetson-headless-mode — le plus grand gain en espace utilisateur sur les systèmes démarrant encore avec graphical.target.
• jetson-inference-mem-tune — lorsqu’un serveur de modèles est le principal consommateur de NvMap / PSS.
• Si les modifications en cours d’exécution ne permettent pas d’atteindre l’objectif, signalez qu’une récupération supplémentaire dépasse le champ d’application de cette compétence, plutôt que de suggérer des modifications non sécurisées au démarrage.