Freigeben über

Arbeitsspeichernutzung in allgemeinen Anwendungen

  • Artikel

Wichtig

Dies ist die Dokumentation zu Azure Sphere (Legacy). Azure Sphere (Legacy) wird am 27. September 2027 eingestellt, und Benutzer müssen bis zu diesem Zeitpunkt zu Azure Sphere (integriert) migrieren. Verwenden Sie die Versionsauswahl oberhalb des Inhaltsverzeichniss, um die Dokumentation zu Azure Sphere (Integriert) anzuzeigen.

Dieses Thema enthält Details zur Arbeitsspeichernutzung in allgemeinen Anwendungen. Informationen zu dem für Echtzeitanwendungen (RTApps) verfügbaren Arbeitsspeicher finden Sie unter Verwalten der Überlegungen zu Arbeitsspeicher und Wartezeit.

Allgemeine Anwendungen haben Zugriff auf den folgenden Arbeitsspeicher und Speicher:

  • 256 KiB RAM im allgemeinen Kern, ausschließlich für die Verwendung durch die allgemeine Anwendung reserviert. Bis zu 1 KiB dieses Speicherplatzes kann den einzelnen Kanälen mit gemeinsam genutztem Puffer zugeordnet werden, über die allgemeine Anwendungen und RTApps kommunizieren.
  • 1 MiB an schreibgeschütztem Flashspeicher, aufgeteilt zwischen den allgemeinen Kernen und den Echtzeitkernen
  • Lese-/Schreibspeicher (veränderlich), der bei einem Neustart des Geräts beibehalten wird. Informationen zu veränderlichem Speicher finden Sie unter Verwenden von Speicher unter Azure Sphere.

Hinweis

Die Aktualisierung des Blitzes trägt es schließlich ab und macht ihn ungültig. Daher sollten Sie Ihren Code entwerfen, um unnötige Updates des Flash zu vermeiden. Wenn Sie z. B. den Anwendungszustand vor dem Beenden speichern möchten, damit Sie den gespeicherten Zustand nach einem Neustart wiederherstellen können, sollten Sie den Zustand der Anwendung nur dann im Flash speichern, wenn sich der Zustand geändert hat.

Ermitteln der Flashspeichernutzung

Um die Speicherauslastung im Flash-Speicher zu ermitteln, sollten Sie nur die Größe der Bildpaketdatei berücksichtigen, die die Bildmetadaten, das Anwendungsmanifest und das ausführbare Bild enthält. Sie müssen nicht den von Microsoft bereitgestellten Speicher berücksichtigen, z. B. das Azure Sphere-Betriebssystem oder die Laufzeitdienste und freigegebenen Bibliotheken, die Peripheriegeräte steuern und die Verbindung mit einem Azure IoT Hub ermöglichen. Ebenso müssen Sie nicht die Größe einer vollständigen Sicherungskopie Ihrer Anwendung oder die Komponenten einschließen, die Failover oder Rollback bei Beschädigungen oder Problemen mit Überluftupdates aktivieren.

Während der Entwicklung und beim Debuggen wird die Größe des Debuggers aber für den Grenzwert angerechnet. Der Debugger wird mit azsphere device enable-development automatisch hinzugefügt und mit azsphere device enable-cloud-test entfernt. Sie finden die Größe des Debuggers, der von Ihrem SDK verwendet wird, indem Sie im Ordner "DebugTools" des Installationsverzeichnisses von Microsoft Azure Sphere SDK nach gdbserver.imagepackage suchen.

Der Befehl "Querladen des Azsphere-Geräts" gibt einen Fehler zurück, wenn das Anwendungsimagepaket und der Debugger (sofern vorhanden) den Gesamtgrenzwert von 1 MiB überschreiten. Der Azsphere Image-Add --Image-Befehl , der ein neues Image in Ihren Azure Sphere-Mandanten hochlädt, gibt auch einen Fehler zurück, wenn das Bildpaket 1 MiB überschreitet.

Der 256 KiB-RAM-Grenzwert gilt allein für die Anwendung; Sie müssen keinen RAM zulassen, der vom Debugger verwendet wird. Zusätzlicher Speicher ist für Kernelzuordnungen reserviert.

Der verfügbare Flash und RAM können für Anwendungen, die für den aktuellen Azure Sphere-Chip (MT3620) geschrieben wurden, erhöhen (aber nie abnehmen). Für zukünftige Azure Sphere-Chips gelten möglicherweise andere Grenzwerte.

Nicht genügend Arbeitsspeicher

Wenn Ihre Anwendung zu viel RAM verwendet, beendet das Azure Sphere OS sie mit einem SIGKILL-Signal. Im Debugger wird beispielsweise Folgendes angezeigt:

Child terminated with signal = 0x9 (SIGKILL)

Das SIGKILL-Signal tritt auch auf, wenn eine anwendung auf hoher Ebene nicht beendet werden kann, nachdem sie die SIGTERM-Anforderung erhalten hat. Details finden Sie im Lebenszyklus einer Anwendung .

Informationen zum Vermeiden von Abstürzen in Ihrer Anwendung aufgrund eines Zustands außerhalb des Arbeitsspeichers finden Sie unter bewährten Methoden zum Verwalten der RAM-Verwendung in anwendungen auf hoher Ebene.

Ermitteln der Laufzeitanwendungs-RAM-Verwendung

Azure Sphere bietet mehrere Funktionen zum Abrufen von Speicherauslastungsinformationen zur Laufzeit. Sie können diese verwenden, um die Speicherauslastung Ihrer allgemeinen Anwendung zu überwachen, sodass Sie Ihre Anwendung sicher neu starten können, wenn die Speicherauslastung einen Schwellenwert überschreitet, den Sie innerhalb des 256 KiB-Grenzwerts angeben. Die verfügbaren Funktionen sind:

  • Applications_GetTotalMemoryUsageInKB: Abrufen der Gesamtspeicherauslastung in Kibibytes. Dies ist die gesamt physische Speicherauslastung Ihrer App im System, einschließlich Kernelzuweisungen (z. B. Puffer für Sockets) im Auftrag Ihrer App oder des Debuggingservers, die als Rohwert (in KiB) zurückgegeben werden.
  • Applications_GetUserModeMemoryUsageInKB: Abrufen der Speicherauslastung des Benutzermodus in Kibibytes. Dies ist die Menge des physischen Arbeitsspeichers, der direkt von Ihrer App, dem von bibliotheken in seinem Auftrag verwendeten Speicher (auch als Anon-Zuordnungen bezeichnet) und dem vom Debuggingserver verwendeten Arbeitsspeicher, der als Rohwert (in KiB) zurückgegeben wird.
  • Applications_GetPeakUserModeMemoryUsageInKB: Abrufen der Speicherauslastung im Spitzenbenutzermodus in Kibibytes. Dies ist die maximale Anzahl von Benutzerspeichern, die in der aktuellen Sitzung verwendet werden. Beim Testen der Speicherauslastung Ihrer Anwendung sollten Sie sicherstellen, dass dieser Wert niemals 256 KiB überschreitet. Dieser Wert wird bei jedem Neustart der App oder erneuten Bereitstellung zurückgesetzt. Verwenden Sie diese Funktion, um einen ungefähren Überblick darüber zu erhalten, wie nah Ihre Anwendung dem empfohlenen Grenzwert von 256 KiB entspricht.

Wenn Sie diese Funktionen in Ihrer allgemeinen Anwendung verwenden möchten, schließen Sie die Headerdatei "applications.h" ein. Sie können diese Funktionen während der Entwicklung verwenden, um eine Vorstellung von der allgemeinen Speichernutzung Ihrer Anwendung zu erhalten, aber Sie können sie auch zusammen mit der Protokollierung verwenden, um Informationen von Geräten im Feld zu erfassen. Der Codeausschnitt "Speicherübernutzungserkennung und Bereinigung" veranschaulicht, wie unerwartete Speicherauslastung erkannt und ordnungsgemäß behandelt wird.

Hinweis

Diese Funktionen geben die Speicherauslastung zurück, wie vom Betriebssystem gesehen. Derzeit wird die Freisetzung des Arbeitsspeichers durch eine Anwendung für die Zuordnung des Benutzerhaps von diesen Funktionen nicht gemeldet. Der Speicher wird zur zukünftigen Verwendung an die malloc-Bibliothek zurückgegeben, aber die vom Betriebssystem gemeldeten Statistiken bleiben unverändert, es sei denn, der Speicher wurde vom Betriebssystem selbst zugewiesen und freigegeben. Ein Beispiel wäre das Zuweisen des Speichers für einen Socket. Daher sind diese Funktionen nützlich, um Szenarios im ungünstigsten Fall zu verstehen, damit Ihre Anwendung konservativer arbeiten kann, um maximale Zuverlässigkeit zu gewährleisten. Die Werte sind ungefähre Werte und können je nach Betriebssystemversion variieren.

Hinzufügen der Nachverfolgung für die Heapspeicherbelegung

Sie können zusätzliche Informationen zur Speicherauslastung abrufen, indem Sie die Heap-Speicherzuweisungsnachverfolgung hinzufügen, die zeigt, welche Benutzer- und Kernelzuordnungen von statischen und dynamisch verknüpften Bibliotheken vorgenommen werden. Dies bietet ein umfassenderes Bild davon, wo Arbeitsspeicher von Ihrer Anwendung verwendet wird, um sie am effektivsten zu nutzen. Dieses Feature, das mit der Azure Sphere OS Version 21.07 oder höher und der Anwendungslaufzeitversion (ARV) 10 oder höher verfügbar ist, funktioniert nur auf einem entwicklungsfähigen Gerät und nur, wenn die Anwendung nicht unter dem Debugger ausgeführt wird.

Hinweis

Sie müssen beide konfigurationsaufgaben ausführen, die in diesem Abschnitt beschrieben werden, damit die Speicherzuweisungsnachverfolgung ordnungsgemäß funktioniert. Wenn Sie dies nicht tun, wird während der Kompilierung eine Warnung gemeldet, und Heap-Speicherinformationen werden nicht angezeigt.

Um die Speicherzuweisungsnachverfolgung zu aktivieren, müssen Sie zwei Dinge ausführen:

  • Fügen Sie die HeapMemStats-Funktion zur app-manifest.json Datei Ihrer Anwendung hinzu:

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

  • Fügen Sie die libmalloc-Bibliothek zu Ihrem Bildpaket hinzu, indem Sie dem Befehl in der azsphere_target_add_image CMakeLists.txt Datei Ihrer Anwendung hinzufügenDEBUG_LIB "libmalloc":

    azsphere_target_add_image_package(${PROJECT_NAME} DEBUG_LIB "libmalloc")

Wichtig

Da die Speicherzuweisungsnachverfolgung nur auf entwicklungsfähigen Geräten funktioniert, sollten Sie folgendes tun, um sie aus Ihrer Anwendung zu entfernen, bevor Sie Imagepakete für die Bereitstellung erstellen:

  • Löschen Sie die Zeile "HeapMemStats": true" aus der app-manifest.json-Datei Ihrer Anwendung.
  • Entfernen Sie DEBUG_LIB "libmalloc" den Befehl in der azsphere_target_add_image_package(${PROJECT_NAME} DEBUG_LIB "libmalloc" CMakeLists.txt Datei Ihrer Anwendung.

Verwenden des Visual Studio-Leistungsprofilrs

Wenn Sie Visual Studio verwenden, können Sie dessen Performance Profiler-Feature verwenden, um Informationen zur Anwendungsspeicherauslastung abzurufen. Ein Lernprogramm, das diesen Profiler verwendet, finden Sie unter Lernprogramme/MemoryUsage.

Voraussetzungen

Starten des Speicherverwendungsprofilrs

  1. Wählen Sie "Leistungsprofil debuggen">aus, oder drücken Sie ALT+F2, um das Startfenster des Performance Profilers zu öffnen.

    Visual Studio-Leistungsprofilfenster

  2. Wenn der Azure Sphere Device Profiler nicht sichtbar ist, wählen Sie unter "Analyseziel" die Option "Ziel" und dann "Azure Sphere Device Profiler" aus.

  3. Stellen Sie unter "Verfügbare Tools" sicher, dass azure Sphere Memory Usage aktiviert ist, und wählen Sie dann "Start " aus, um das Profilerstellungsfenster für die Speichernutzung zu öffnen und den Speicherprofiler zu starten.

  4. Wenn Sie Die Anwendung bereitstellen oder neu starten müssen, wählen Sie "Debuggen>starten" aus, oder drücken Sie STRG+F5, um Die Anwendung auf dem Gerät bereitzustellen.

    Wichtig

    Um genaue RAM-Verwendungsinformationen für Ihre Anwendung zu erhalten, ist es wichtig, dass Sie [Ihre App ohne Debugging starten](buid-hl-app.md#build-and-deploy-the-application-in- visual-studio-without-debugging). Das Ausführen Ihrer App unter dem Debugger führt zu einer überhöhten RAM-Auslastung, da der vom Debuggingserver verbrauchte Arbeitsspeicher in die gemeldeten RAM-Nutzungsstatistiken einbezogen wird.

Interpretieren der Speicherauslastungsprofildaten

Im Profilerstellungsfenster für die Speicherauslastung wird eine Ansicht wie folgt angezeigt:

Visual Studio-Speicherverwendungsprofilfenster

In der Mitte der Ansicht zeichnet ein Azure Sphere Device Physical Memory Graph drei verschiedene RAM-Nutzungsstatistiken (die dem nächstgelegenen KiB angezeigt werden) als drei verschiedene Linien während der Ausführung Der App:

  • Gesamt: Die Gesamtauslastung des physischen Arbeitsspeichers Ihrer App im System, einschließlich Kernelzuweisungen (z. B. Puffer für Sockets) im Auftrag Ihrer App oder des Debuggingservers.
  • Benutzer: Die Menge des physischen Arbeitsspeichers, der von Ihrer App direkt verwendete Arbeitsspeicher, der von allen Bibliotheken in seinem Namen verwendet wird (auch als Anon-Zuordnungen bezeichnet) und vom Debuggingserver verwendeter Arbeitsspeicher.
  • Spitzenbenutzer: Die maximale Menge des in der aktuellen Sitzung verwendeten Benutzerspeichers. Beim Testen der Speicherauslastung Ihrer Anwendung sollten Sie sicherstellen, dass dieser Wert niemals 256 KiB überschreitet. Zusätzlicher Speicher ist für Kernelzuordnungen reserviert. Dieser Wert wird bei jedem Neustart der App oder erneuten Bereitstellung zurückgesetzt.

Das Diagramm zeichnet auch Vorkommen des New Peak-Ereignisses (dargestellt durch ein Dreieck). Dieses Ereignis tritt auf, wenn es ein neues Maximum für die Maximale Benutzerspeicherauslastung gibt. Das Ereignis ist für die Barrierefreiheit der Sprachausgabe aktiviert.

Wenn Sie die Nachverfolgung der Heap-Speicherzuweisung aktiviert haben und Ihre Anwendung nicht unter dem Debugger ausgeführt wird, wird ein zusätzliches Diagramm mit Heap-Speicherstatistiken angezeigt:

  • Gesamthap: Der gesamte Heap-Speicher, der von oder im Auftrag Ihrer Anwendung zugewiesen wurde, einschließlich aus statischen und dynamischen Bibliotheken.
  • Heap der freigegebenen Bibliothek: Zuordnungen aus dynamisch verknüpften Bibliotheken, die vom Azure Sphere OS bereitgestellt werden.

Visual Studio-Heap-Speicherauslastung

Über den Diagrammen zeigt eine Zeitachsenansicht die Laufzeit Ihrer App an, die mit den Daten im folgenden Diagramm korreliert ist. Verwenden Sie "Vergrößern" und "Verkleineren ", um sich auf bestimmte Zeiträume zu konzentrieren.

Unter den Diagrammen zeigt eine Tabellenansicht die gleichen Arbeitsspeicherstatistiken und -ereignisse an.

Tipp

Um Daten aus der Tabelle in die Zwischenablage zu kopieren, drücken Sie STRG+A , um alle Zeilen auszuwählen, und drücken Sie dann STRG+C.

Die ersten beiden In diesem Abschnitt gezeigten Diagramme wurden während der Ausführung von Phase 1 des Lernprogramms zur Speicherauslastung aufgenommen, das einen Speicherverlust enthält. Die Speicherauslastung steigt monoton in jedem Diagramm und liefert visuelle Nachweise für das Leck. Wenn das Leck behoben ist, wie in Phase 2 des Lernprogramms zur Speicherauslastung, steigt das Diagramm und fällt, wenn Speicher zugewiesen und zugeordnet wird.

Speicherauslastung im Heap von Visual Studio ohne Speicherverlust

Anzeigen von Statistiken zur Gesamtspeicherauslastung

Der Befehl "azsphere device app show-memory-stats" gibt Statistiken zur Speicherauslastung, zur Nutzung des Benutzermodus und zur Spitzennutzung des Benutzermodus für Anwendungen zurück, die auf einem angeschlossenen Gerät ausgeführt werden. Das Gerät muss über die AppDevelopment-Gerätefunktion verfügen, um diesen Befehl auszuführen.

Die RAM-Nutzungsstatistiken, die angezeigt werden, während Ihre App ausgeführt wird:

  • Gesamtanzahl (Kernel + Benutzermodus): Die Gesamtauslastung des physischen Speichers Ihrer App im System, einschließlich Kernelzuweisungen (z. B. Puffer für Sockets) im Auftrag Ihrer App oder des Debugservers.
  • Benutzermodus: Die Menge des physischen Arbeitsspeichers, der direkt von Ihrer App verwendete Arbeitsspeicher, der von allen Bibliotheken in seinem Namen verwendet wird (auch als Anon-Zuordnungen bezeichnet) und arbeitsspeicher, der vom Debuggingserver verwendet wird.
  • Spitzenbenutzermodus: Die maximale Menge des in der aktuellen Sitzung verwendeten Benutzerspeichers. Beim Testen der Speicherauslastung Ihrer Anwendung sollten Sie sicherstellen, dass dieser Wert niemals 256 KiB überschreitet. Zusätzlicher Speicher ist für Kernelzuordnungen reserviert. Dieser Wert wird bei jedem Neustart der App oder erneuten Bereitstellung zurückgesetzt.

Wenn Sie die Heap-Speicherzuweisungsnachverfolgung aktiviert haben und Ihre Anwendung nicht unter dem Debugger ausgeführt wird, werden zusätzliche Zeilen mit Heap-Speicherstatistiken angezeigt:

  • Heap: App + Static Libraries: Der Kernel und die Benutzerzuweisungen aus Ihrem Code und alle Bibliotheken, die statisch damit verknüpft sind.
  • Heap: dynamische Bibliothekszuweisungen: <Zuordnungen> aus einzelnen dynamisch verknüpften Bibliotheken, die vom Azure Sphere OS bereitgestellt werden.

Kontinuierliche Überwachung der Speicherauslastung

Um die Speicherauslastung im Laufe der Zeit zu überwachen, können Sie Skripts verwenden, um den Befehl "azsphere device show-memory-stats" in einer Schleife auszuführen, wie in den folgenden Beispielen beschrieben:

Windows-Eingabeaufforderung

Erstellen Sie mithilfe von Editor oder einem anderen Texteditor eine Batchskriptdatei memuse.bat mit folgendem Inhalt:

@echo off

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

Führen Sie das Batchskript aus, indem Sie seinen Namen an der Eingabeaufforderung eingeben (oder den vollständigen Pfad zur Datei, wenn es sich nicht im aktuellen Verzeichnis befindet):

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

Wenn Sie das Skript beenden möchten, geben Sie STRG+C in das Eingabeaufforderungsfenster ein, und antworten Sie dann Y auf die Eingabeaufforderung "Batchauftrag beenden?".

Windows PowerShell

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

Arbeitsspeicherauslastung und Der Debugger

Wenn Sie Ihre App unter dem Debugger ausführen, umfassen die gemeldeten Speicherstatistiken auch die Speicherauslastung des Debugserverprozesses und andere zusätzliche Speicherauslastungen, die durch das Debuggen verursacht werden, z. B. festlegen von Haltepunkten. Aus diesem Grund sollten Sie Ihre App immer ohne Debugging ausführen, wenn Sie versuchen, genaue Speicherstatistiken zu sammeln.

Die Verwendung des Speichernutzungsprofilrs kann jedoch hilfreich sein, wenn Sie Ihre App mit dem Debugger ausführen. Das Festlegen von Haltepunkten und das Durchlaufen von Codezeilen bei gleichzeitiger Beobachtung relativer Änderungen der Arbeitsspeichernutzung kann eine nützliche Technik zur Identifizierung der Ursachen von Speicherauslastungsspitzen oder Speicherverlusten sein.

Beim Debuggen in Visual Studio wird der Performance Profiler automatisch geöffnet, zeigt jedoch keine Heap-Speicherzuweisungsnachverfolgung an.