Dela via

Minnesanvändning i högnivåprogram

  • Artikel

Viktigt!

Det här är dokumentationen om Azure Sphere (Legacy). Azure Sphere (Legacy) upphör den 27 september 2027 och användarna måste migrera till Azure Sphere (integrerad) vid den här tiden. Använd versionsväljaren ovanför TOC för att visa dokumentationen om Azure Sphere (integrerad).

Det här avsnittet innehåller information om minnesanvändning i högnivåprogram. Se Hantera överväganden för minne och svarstider för information om det minne som är tillgängligt för realtidskompatibla program (RTApps).

Program på hög nivå har åtkomst till följande minne och lagring:

  • 256 KiB RAM på högnivåkärnan, helt reserverad för högnivåprogramanvändning. Upp till 1 KiB av det här utrymmet kan allokeras för varje delad buffertkanal genom vilken högnivåprogram och RTApps kommunicerar.
  • 1 MiB skrivskyddat flashminne, som delas mellan kärnorna på hög nivå och realtid.
  • Läs-/skrivlagring (föränderlig) som bevaras när en enhet startas om. Information om föränderlig lagring finns i Använda lagring på Azure Sphere.

Kommentar

Om du uppdaterar blixten upprepade gånger slits den så småningom ut och gör den ogiltig. Därför bör du utforma koden för att undvika onödiga uppdateringar av blixten. Om du till exempel vill spara programtillståndet innan du avslutar så att du kan återställa det sparade tillståndet efter en omstart kan du spara programmets tillstånd till blixten endast om tillståndet har ändrats.

Fastställa användning av flashminne

Ta bara hänsyn till storleken på bildpaketfilen som innehåller bildmetadata, programmanifest och den körbara avbildningen för att fastställa användningen av flashminnet. Du behöver inte ta hänsyn till den lagring som krävs av Microsoft-tillhandahållna komponenter, till exempel Azure Sphere OS eller körningstjänster och delade bibliotek som styr kringutrustning och aktiverar anslutning till en Azure IoT Hub. På samma sätt behöver du inte ta med storleken på en fullständig säkerhetskopia av ditt program eller de komponenter som aktiverar redundans eller återställning om det uppstår fel eller problem med trådlösa uppdateringar.

Under utveckling och felsökning räknas dock storleken på felsökningsprogrammet mot gränsen. Felsökningsprogrammet läggs automatiskt till av azsphere device enable-development och tas bort av azsphere device enable-cloud-test. Du hittar storleken på det felsökningsprogram som används av SDK:t genom att söka efter gdbserver.imagepackage i mappen DebugTools i installationskatalogen för Microsoft Azure Sphere SDK.

Kommandot azsphere device sideload returnerar ett fel om programbildpaketet och felsökningsprogrammet (om det finns) överskrider den totala gränsen på 1 MiB. Kommandot azsphere image add --image som laddar upp en ny avbildning till din Azure Sphere-klientorganisation returnerar också ett fel om avbildningspaketet överskrider 1 MiB.

Gränsen på 256 KiB RAM gäller enbart för programmet. du behöver inte tillåta RAM-minne som används av felsökningsprogrammet. Ytterligare minne är reserverat för kernelallokeringar.

Den tillgängliga blixten och RAM-minnet kan öka (men kommer aldrig att minska) för program som skrivits för det aktuella Azure Sphere-chipet (MT3620). Framtida Azure Sphere-chips kan ha olika gränser.

Minnesbrist

Om programmet använder för mycket RAM avslutar Azure Sphere-operativsystemet det med en SIGKILL-signal. I felsökningsprogrammet ser du till exempel följande:

Child terminated with signal = 0x9 (SIGKILL)

SIGKILL-signalen inträffar också om ett högnivåprogram inte kan avslutas efter att SIGTERM-begäran har fåtts. Mer information finns i Livscykel för ett program .

Information om hur du undviker krascher i programmet på grund av minnesbrist finns i metodtips för att hantera RAM-användning i program på hög nivå.

Fastställa RAM-användning för körningsprogram

Azure Sphere tillhandahåller flera funktioner för att hämta information om minnesanvändning vid körning. Du kan använda dessa för att övervaka programmets minnesanvändning på hög nivå, så att du kan starta om programmet på ett säkert sätt om minnesanvändningen överskrider ett tröskelvärde som du anger inom gränsen på 256 KiB. De tillgängliga funktionerna är:

  • Applications_GetTotalMemoryUsageInKB: Hämta den totala minnesanvändningen i kibibyte. Det här är den totala fysiska minnesanvändningen för din app i systemet, inklusive kernelallokeringar (till exempel buffertar för socketar) för din app eller felsökningsservern, som returneras som ett raw-värde (i KiB).
  • Applications_GetUserModeMemoryUsageInKB: Hämta minnesanvändningen i användarläge i kibibyte. Det här är mängden fysiskt minne som används direkt av din app, det minne som används av bibliotek för dess räkning (kallas även anon-allokeringar) och minne som används av felsökningsservern, som returneras som ett raw-värde (i KiB).
  • Applications_GetPeakUserModeMemoryUsageInKB: Hämta den högsta minnesanvändningen i användarläge i kibibyte. Det här är den maximala mängden användarminne som används i den aktuella sessionen. När du testar minnesanvändningen för ditt program bör du se till att det här värdet aldrig överskrider 256 KiB. Det här värdet återställs när din app startas om eller distribueras om. Använd den här funktionen för att få en ungefärlig titt på hur nära programmet når den rekommenderade gränsen på 256 KiB.

Om du vill använda dessa funktioner i ditt högnivåprogram inkluderar du header-filen applications.h. Du kan använda dessa funktioner under utvecklingen för att få en uppfattning om programmets totala minnesanvändning, men du kan också använda dem tillsammans med loggning för att samla in information från enheter i fältet. Kodfragmentet För överanvändning av minne visar hur du identifierar och hanterar oväntad minnesanvändning på ett korrekt sätt.

Kommentar

Dessa funktioner returnerar minnesanvändningen enligt operativsystemet. För närvarande rapporteras inte frigöring av minne av ett program för allokeringar på användarhögen av dessa funktioner. Minnet kommer att returneras till malloc-biblioteket för framtida användning, men den statistik som rapporteras av operativsystemet förblir oförändrad om inte minnet allokerades och frigörs av själva operativsystemet. Ett exempel skulle vara att allokera minne för en socket. Därför är dessa funktioner användbara för att förstå värsta scenarier som hjälper ditt program att fungera konservativt för maximal tillförlitlighet. Värdena är ungefärliga och kan variera mellan operativsystemversioner.

Lägga till spårning av heapminnesallokering

Du kan hämta ytterligare information om minnesanvändning genom att lägga till spårning av heapminnesallokering, som visar vilka användar- och kernelallokeringar som görs av statiska och dynamiskt länkade bibliotek. Detta ger en mer fullständig bild av var minnet används av ditt program för att hjälpa dig att använda det mest effektivt. Den här funktionen, som är tillgänglig med Azure Sphere OS version 21.07 eller senare och programkörningsversion (ARV) 10 eller senare, fungerar endast på en utvecklingsaktiverad enhet och endast när programmet inte körs under felsökningsprogrammet.

Kommentar

Du måste slutföra båda konfigurationsuppgifterna som beskrivs i det här avsnittet för att spårning av heapminnesallokering ska fungera korrekt. Om du inte gör det rapporteras en varning under kompilering och information om heapminnet visas inte.

För att aktivera spårning av heapminnesallokering måste du göra två saker:

  • Lägg till funktionen HeapMemStats i programmets app-manifest.json-fil:

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

  • Lägg till biblioteket libmalloc i avbildningspaketet genom att lägga DEBUG_LIB "libmalloc" till kommandot azsphere_target_add_image i programmets CMakeLists.txt-fil:

    azsphere_target_add_image_package(${PROJECT_NAME} DEBUG_LIB "libmalloc")

Viktigt!

Eftersom spårning av heapminnesallokering endast fungerar på utvecklingsaktiverade enheter bör du göra följande för att ta bort det från programmet innan du skapar avbildningspaket för distribution:

  • Ta bort raden "HeapMemStats": true från programmets app-manifest.json-fil.
  • Ta bort DEBUG_LIB "libmalloc" från azsphere_target_add_image_package(${PROJECT_NAME} DEBUG_LIB "libmalloc" kommandot i programmets CMakeLists.txt-fil.

Använda Prestandaprofilering för Visual Studio

Om du använder Visual Studio kan du använda dess prestandaprofileringsfunktion för att få information om programminnesanvändning. En självstudiekurs som använder den här profileraren finns i Självstudier/Minnesanvändning.

Förutsättningar

Starta profileraren för minnesanvändning

  1. Välj Felsök>Prestandaprofiler eller tryck på Alt+F2 för att öppna startfönstret för prestandaprofiler.

    Visual Studio-prestandaprofileringsfönster

  2. Om Azure Sphere Device Profiler inte visas under Analysis Target väljer du Välj mål och sedan Azure Sphere Device Profiler.

  3. Under Tillgängliga verktyg kontrollerar du att Azure Sphere-minnesanvändningen är markerad och väljer sedan Starta för att öppna fönstret för minnesanvändningsprofilering och starta minnesprofileraren.

  4. Om du behöver distribuera eller starta om programmet väljer du Felsöka>Starta utan felsökning eller trycker på Ctrl+F5 för att distribuera programmet till enheten.

    Viktigt!

    För att få korrekt RAM-användningsinformation för ditt program är det viktigt att du [startar appen utan felsökning](buid-hl-app.md#build-and-deploy-the-application-in- visual-studio-without-debugging). Om du kör din app under felsökningsprogrammet resulterar det i uppblåst RAM-användning, eftersom minne som förbrukas av felsökningsservern inkluderas i den rapporterade RAM-användningsstatistiken.

Tolka data för minnesanvändningsprofilering

Fönstret för minnesanvändningsprofilering visar en vy som liknar följande:

Fönstret Profilerare för minnesanvändning i Visual Studio

I mitten av vyn ritar ett fysiskt minnesdiagram för Azure Sphere-enheter tre olika RAM-användningsstatistik (visas för närmaste KiB) som tre olika rader medan appen körs:

  • Totalt: Den totala fysiska minnesanvändningen för din app i systemet, inklusive kernelallokeringar (till exempel buffertar för sockets) för din app eller felsökningsservern.
  • Användare: Mängden fysiskt minne som används direkt av din app, det minne som används av bibliotek för dess räkning (kallas även för anon-allokeringar) och minne som används av felsökningsservern.
  • Högsta användare: Den maximala mängden användarminne som används i den aktuella sessionen. När du testar minnesanvändningen för ditt program bör du se till att det här värdet aldrig överskrider 256 KiB. Ytterligare minne är reserverat för kernelallokeringar. Det här värdet återställs när din app startas om eller distribueras om.

Diagrammet ritar också förekomster av händelsen Ny topp (representeras av en triangel). Den här händelsen inträffar när det finns ett nytt maxvärde för maximal minnesanvändning för användare. Händelsen är aktiverad för skärmläsartillgänglighet.

Om du har aktiverat spårning av heapminnesallokering och programmet inte körs under felsökningsprogrammet visas ytterligare ett diagram som visar heapminnesstatistik:

  • Total heap: Det totala heapminnet som allokerats av eller för ditt program, inklusive från statiska och dynamiska bibliotek.
  • Heap för delat bibliotek: Allokeringar från dynamiskt länkade bibliotek som tillhandahålls av Azure Sphere OS.

Minnesanvändning för Visual Studio-heap

Ovanför graferna visar en tidslinjevy appens körningstid, korrelerad med data i diagrammet nedan. Använd Zooma in och zooma ut för att fokusera på specifika tidsperioder.

Under graferna visar en tabellvy samma minnesstatistik och händelser.

Dricks

Om du vill kopiera data från tabellen till Urklipp trycker du på Ctrl+A för att markera alla rader och trycker sedan på Ctrl+C.

De första två diagram som visas i det här avsnittet togs när steg 1 kördes i självstudiekursen minnesanvändning, som innehåller en minnesläcka. Minnesanvändningen ökar monotont i varje graf, vilket ger visuella bevis för läckan. När läckan har åtgärdats, som i steg 2 i självstudiekursen om minnesanvändning, stiger och faller diagrammet när minnet allokeras och frigörs.

Minnesanvändning för Visual Studio-heap utan minnesläcka

Visa statistik över total minnesanvändning

Kommandot azsphere device app show-memory-stats returnerar minnesanvändningsstatistik för total minnesanvändning, användning av användarläge och högsta användning i användarläge för program som körs på en ansluten enhet. Enheten måste ha funktionen appUtvecklingsenhet konfigurerad för att köra det här kommandot.

Den RAM-användningsstatistik som visas när appen körs är:

  • Totalt (Kernel + användarläge): Den totala fysiska minnesanvändningen för din app i systemet, inklusive kernelallokeringar (till exempel buffertar för socketar) för din app eller felsökningsservern.
  • Användarläge: Mängden fysiskt minne som används direkt av din app, det minne som används av bibliotek för dess räkning (kallas även anon-allokeringar) och minne som används av felsökningsservern.
  • Högsta användarläge: Den maximala mängden användarminne som används i den aktuella sessionen. När du testar minnesanvändningen för ditt program bör du se till att det här värdet aldrig överskrider 256 KiB. Ytterligare minne är reserverat för kernelallokeringar. Det här värdet återställs när din app startas om eller distribueras om.

Om du har aktiverat spårning av heapminnesallokering och programmet inte körs under felsökningsprogrammet visas ytterligare rader med heapminnesstatistik:

  • Heap: App + Static Libraries: Kernel- och användarallokeringar från din kod och alla bibliotek som är statiskt länkade till den.
  • Heap: <dynamisk biblioteksallokering>: Allokeringar från enskilda dynamiskt länkade bibliotek som tillhandahålls av Azure Sphere OS.

Kontinuerlig övervakning av minnesanvändning

Om du vill övervaka minnesanvändning över tid kan du använda skript för att köra kommandot azsphere device app show-memory-stats i en loop enligt beskrivningen i följande exempel:

Kommandotolken i Windows

Använd Anteckningar eller en annan textredigerare och skapa en batchskriptfil memuse.bat med följande innehåll:

@echo off

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

Kör batchskriptet genom att skriva dess namn i kommandotolken (eller den fullständiga sökvägen till filen, om den inte finns i den aktuella katalogen):

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

Om du vill avsluta skriptet skriver du Ctrl+C i kommandotolkens fönster och svarar sedan Y på uppmaningen "Avsluta batchjobb?".

Windows PowerShell

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

Minnesanvändning och felsökningsprogrammet

När du kör appen under felsökningsprogrammet innehåller den rapporterade minnesstatistiken även minnesanvändningen för felsökningsprocessen och annan ytterligare minnesanvändning som orsakas av felsökning, till exempel att ange brytpunkter. Därför bör du alltid köra appen utan att felsöka när du försöker samla in korrekt minnesstatistik.

Det kan dock vara användbart att använda profileraren för minnesanvändning om du kör appen med felsökningsprogrammet. Att ange brytpunkter och stega igenom kodrader samtidigt som relativa ändringar i minnesförbrukningen observeras kan vara en användbar teknik för att identifiera orsakerna till minnesanvändningstoppar eller minnesläckor.

Vid felsökning i Visual Studio öppnas Prestandaprofiler automatiskt, men visar inte spårning av heapminnesallokering.