Arbeitsspeichernutzung in allgemeinen Anwendungen

Dieses Thema enthält Details zur Speichernutzung in allgemeinen Anwendungen. Informationen zum verfügbaren Arbeitsspeicher für Echtzeitanwendungen (RTApps) finden Sie unter Verwalten von Arbeitsspeicher- und Latenzaspekten .

Allgemeine Anwendungen haben Zugriff auf den folgenden Arbeitsspeicher und Speicher:

• 256 KiB RAM auf dem hauptstufigen Kern, der ausschließlich für die Allgemeine Anwendungsnutzung reserviert ist. Bis zu 1 KiB dieses Speicherplatzes können für jeden freigegebenen Pufferkanal zugeordnet werden, über den allgemeine Anwendungen und RTApps kommunizieren.
• 1 MiB schreibgeschützter Flashspeicher, der zwischen den Kernen der allgemeinen Ebene und den Echtzeitkernen gemeinsam genutzt wird.
• Lese-/Schreibzugriff (änderbarer) Speicher, der beibehalten wird, wenn ein Gerät neu gestartet wird. Informationen zum veränderlichen Speicher finden Sie unter Verwenden von Speicher in Azure Sphere.

Hinweis

Das wiederholte Aktualisieren des Flashs trägt ihn schließlich ab und macht ihn ungültig. Daher sollten Sie Ihren Code so entwerfen, dass unnötige Updates des Flashs vermieden werden. Wenn Sie z. B. den Anwendungsstatus vor dem Beenden speichern möchten, damit Sie den gespeicherten Zustand nach einem Neustart wiederherstellen können, sollten Sie den Status der Anwendung nur dann im Flashmodus speichern, wenn sich der Zustand geändert hat.

Ermitteln der Flashspeicherauslastung

Um die Flashspeicherauslastung zu bestimmen, berücksichtigen Sie nur die Größe der Imagepaketdatei, die die Bildmetadaten, das Anwendungsmanifest und das ausführbare Image enthält. Sie müssen nicht den Speicher berücksichtigen, der für von Microsoft bereitgestellte Komponenten erforderlich ist, 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 der Komponenten einschließen, die ein Failover oder Rollback im Falle von Beschädigungen oder Problemen mit Over-the-Air-Updates ermöglichen.

Während der Entwicklung und beim Debuggen wird jedoch die Größe des Debuggers auf den Grenzwert angerechnet. Der Debugger wird automatisch von az sphere device enable-development hinzugefügt und von [az sphere device enable-cloud-test](.) entfernt. /reference/az sphere-device.md). Sie können die Größe des Debuggers ermitteln, der von Ihrem SDK verwendet wird, indem Sie im Ordner DebugTools des Microsoft Azure Sphere SDK-Installationsverzeichnisses nach gdbserver.imagepackage suchen.

Der Befehl az sphere device sideload gibt einen Fehler zurück, wenn das Anwendungsimagepaket und der Debugger (falls vorhanden) den Gesamtgrenzwert von 1 MiB überschreiten. Der Befehl az sphere image add --image , der ein neues Image in Ihren Azure Sphere-Katalog hochlädt, gibt ebenfalls einen Fehler zurück, wenn das Imagepaket 1 MiB überschreitet.

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

Der verfügbare Flash- und RAM-Speicher kann für Anwendungen, die für den aktuellen Azure Sphere-Chip (MT3620) geschrieben wurden, zunehmen (aber nie abnehmen). Zukünftige Azure Sphere-Chips können unterschiedliche Grenzwerte aufweisen.

Bedingungen für nicht genügend Arbeitsspeicher

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

Child terminated with signal = 0x9 (SIGKILL)

Das SIGKILL-Signal tritt auch auf, wenn eine allgemeine Anwendung nicht beendet werden kann, nachdem sie die SIGTERM-Anforderung empfangen hat. Weitere Informationen finden Sie unter Lebenszyklus einer Anwendung .

Informationen zur Vermeidung von Abstürzen in Ihrer Anwendung aufgrund von nicht genügend Arbeitsspeicher finden Sie unter Bewährte Methoden für die Verwaltung der RAM-Nutzung in allgemeinen Anwendungen.

Ermitteln der Ram-Nutzung der Anwendung zur Laufzeit

Azure Sphere bietet mehrere Funktionen zum Abrufen von Informationen zur Speicherauslastung 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 von Ihnen angegebenen Schwellenwert innerhalb des Grenzwerts von 256 KiB überschreitet. Folgende Funktionen sind verfügbar:

• Applications_GetTotalMemoryUsageInKB: Ruft die Gesamtspeicherauslastung in Kibibytes ab. Dies ist die Gesamtauslastung des physischen Speichers Ihrer App auf dem System, einschließlich Kernelzuordnungen (z. B. Puffer für Sockets) im Namen Ihrer App oder des Debugservers, die als Rohwert (in KiB) zurückgegeben wird.
• Applications_GetUserModeMemoryUsageInKB: Abrufen der Speicherauslastung im Benutzermodus in Kibibytes. Dies ist die Menge an physischem Arbeitsspeicher, die direkt von Ihrer App verwendet wird, der von allen Bibliotheken in ihrem Namen verwendete Arbeitsspeicher (auch als Anon-Zuordnungen bezeichnet) und der vom Debugserver verwendete Arbeitsspeicher, der als Rohwert (in KiB) zurückgegeben wird.
• Applications_GetPeakUserModeMemoryUsageInKB: Abrufen der maximalen Arbeitsspeicherauslastung im Benutzermodus in Kibibytes. Dies ist die maximale Menge an Benutzerarbeitsspeicher, die in der aktuellen Sitzung verwendet wird. Wenn Sie die Speicherauslastung Ihrer Anwendung testen, sollten Sie sicherstellen, dass dieser Wert niemals 256 KiB überschreitet. Dieser Wert wird immer dann zurückgesetzt, wenn Ihre App neu gestartet oder erneut bereitgestellt wird. Verwenden Sie diese Funktion, um einen ungefähren Überblick darüber zu erhalten, wie nah Ihre Anwendung dem empfohlenen Grenzwert von 256 KiB kommt.

Um diese Funktionen in Ihrer allgemeinen Anwendung zu verwenden, schließen Sie die Headerdatei applications.h ein. Sie können diese Funktionen während der Entwicklung verwenden, um sich einen Überblick über die allgemeine Speichernutzung Ihrer Anwendung zu verschaffen, aber Sie können sie auch zusammen mit der Protokollierung verwenden, um Informationen von Geräten im Feld zu erfassen. Der Codeausschnitt zur Erkennung und Bereinigung von Speicherüberlastung veranschaulicht, wie unerwartete Speicherauslastung erkannt und ordnungsgemäß behandelt wird.

Hinweis

Diese Funktionen geben die Speicherauslastung zurück, wie sie vom Betriebssystem gesehen wird. Derzeit wird die Freigabe von Arbeitsspeicher durch eine Anwendung für Zuordnungen auf dem Benutzerheap von diesen Funktionen nicht gemeldet. Der Arbeitsspeicher wird zur zukünftigen Verwendung an die malloc-Bibliothek zurückgegeben, aber die vom Betriebssystem gemeldeten Statistiken bleiben unverändert, es sei denn, der Arbeitsspeicher wurde vom Betriebssystem selbst zugewiesen und freigegeben. Ein Beispiel wäre die Zuweisung von Arbeitsspeicher für einen Socket. Daher sind diese Funktionen nützlich, um Worst-Case-Szenarien zu verstehen, um Ihre Anwendung bei einem konservativen Betrieb für maximale Zuverlässigkeit zu unterstützen. Die Werte sind ungefähre Werte und können je nach Betriebssystemversion variieren.

Hinzufügen der Speicherbelegungsnachverfolgung für den Heap

Sie können zusätzliche Informationen zur Speicherauslastung erhalten, indem Sie die Nachverfolgung der Heapspeicherbelegung hinzufügen, die anzeigt, welche Benutzer- und Kernelzuordnungen von statischen und dynamisch verknüpften Bibliotheken vorgenommen werden. Dies bietet ein vollständiges Bild davon, wo Speicher von Ihrer Anwendung verwendet wird, um sie am effektivsten zu verwenden. Dieses Feature, das mit der Azure Sphere-Betriebssystemversion 21.07 oder höher und der Application Runtime-Version (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 in diesem Abschnitt beschriebenen Konfigurationsaufgaben ausführen, damit die Nachverfolgung der Heapspeicherbelegung ordnungsgemäß funktioniert. Wenn Sie dies nicht tun, wird während der Kompilierung eine Warnung gemeldet, und Heapspeicherinformationen werden nicht angezeigt.

Um die Nachverfolgung der Heap-Speicherbelegung zu aktivieren, müssen Sie zwei Schritte ausführen:

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

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

• Fügen Sie ihrem Imagepaket die bibliothek libmalloc 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 Nachverfolgung der Heapspeicherbelegung nur auf entwicklungsfähigen Geräten funktioniert, sollten Sie sie wie folgt aus Ihrer Anwendung entfernen, bevor Sie Imagepakete für die Bereitstellung erstellen:

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

Verwenden des Visual Studio-Leistungsprofilers

Wenn Sie Visual Studio verwenden, können Sie das Leistungsprofilerfeature verwenden, um Informationen zur Speicherauslastung der Anwendung abzurufen. Ein Tutorial, in dem dieser Profiler verwendet wird, finden Sie unter Tutorials/MemoryUsage.

Voraussetzungen

• Ein Azure Sphere Development Kit, das mit Ihrem PC verbunden ist, auf dem Visual Studio ausgeführt wird und das Azure Sphere SDK installiert ist. Weitere Informationen finden Sie unter Installieren des Azure Sphere SDK für Windows.
• Ein für die Entwicklung vorbereitetes Gerät. Weitere Informationen finden Sie unter az sphere device enable-development. Der Leistungsprofiler gibt keine Daten zurück, wenn Ihr Gerät nicht für die Entwicklung aktiviert ist.

Starten des Speicherauslastungsprofilers

1. Wählen SieDebug Performance Profiler (Leistungsprofilerdebuggen>) aus, oder drücken Sie ALT+F2, um das Startfenster des Leistungsprofilers zu öffnen.

   

2. Wenn der Azure Sphere-Geräteprofiler nicht sichtbar ist, wählen Sie unter Analyseziel die Option Ziel auswählen und dann Azure Sphere-Geräteprofiler aus.

3. Stellen Sie unter Verfügbare Tools sicher, dass Azure Sphere-Speicherauslastung 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 Ihre Anwendung bereitstellen oder neu starten müssen, wählen Sie Debuggen>Starten ohne Debuggen aus, oder drücken Sie STRG+F5 , um Die Anwendung auf dem Gerät bereitzustellen.

   Wichtig

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

Interpretieren der Profilerdaten für die Speicherauslastung

Das Profilerstellungsfenster für die Speicherauslastung zeigt eine Ansicht wie die folgende an:

In der Mitte der Ansicht zeichnet ein Azure Sphere Device Physical Memory Graph drei verschiedene RAM-Nutzungsstatistiken (dem nächstgelegenen KiB angezeigt) als drei verschiedene Linien, während Ihre App ausgeführt wird:

• Gesamt: Die gesamte physische Speicherauslastung Ihrer App auf dem System, einschließlich Kernelzuordnungen (z. B. Puffer für Sockets) im Namen Ihrer App oder des Debugservers.
• Benutzer: Die Menge des physischen Arbeitsspeichers, die direkt von Ihrer App verwendet wird, der Von allen Bibliotheken in ihrem Namen genutzte Arbeitsspeicher (auch als Anon-Zuordnungen bezeichnet) und der vom Debugserver verwendete Arbeitsspeicher.
• Peak User: Die maximale Menge an Benutzerarbeitsspeicher, die in der aktuellen Sitzung verwendet wird. Wenn Sie die Speicherauslastung Ihrer Anwendung testen, sollten Sie sicherstellen, dass dieser Wert niemals 256 KiB überschreitet. Zusätzlicher Arbeitsspeicher ist für Kernelzuordnungen reserviert. Dieser Wert wird immer dann zurückgesetzt, wenn Ihre App neu gestartet oder erneut bereitgestellt wird.

Das Diagramm zeichnet auch Vorkommen des New Peak-Ereignisses (dargestellt durch ein Dreieck). Dieses Ereignis tritt auf, wenn ein neuer Höchstwert für die Arbeitsspeicherauslastung "Peak User" (Maximale Benutzerarbeitsauslastung) vorhanden ist. Das Ereignis ist für die Barrierefreiheit der Sprachausgabe aktiviert.

Wenn Sie die Nachverfolgung des Heapspeichers aktiviert haben und Ihre Anwendung nicht unter dem Debugger ausgeführt wird, wird ein zusätzliches Diagramm mit Heapspeicherstatistiken angezeigt:

• Gesamtheap: Der gesamte Heapspeicher, der von oder im Auftrag Ihrer Anwendung zugeordnet wird, einschließlich statischer und dynamischer Bibliotheken.
• Heap für freigegebene Bibliotheken: Zuordnungen aus dynamisch verknüpften Bibliotheken, die vom Azure Sphere-Betriebssystem bereitgestellt werden.

Oberhalb der Diagramme zeigt eine Zeitleiste Ansicht 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.

Unterhalb der Diagramme werden in einer Tabellenansicht dieselben Speicherstatistiken und Ereignisse angezeigt.

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 Diagramme in diesem Abschnitt wurden während der Ausführung von Phase 1 des Tutorials zur Speicherauslastung erstellt, die einen Speicherverlust enthält. Die Speicherauslastung steigt in jedem Diagramm monoton an, was einen visuellen Beweis für das Leck liefert. Wenn der Verlust behoben ist, wie in Phase 2 des Tutorials zur Speicherauslastung, steigt und fällt das Diagramm, wenn Arbeitsspeicher zugeordnet und die Zuordnung aufgehoben wird.

Anzeigen von Statistiken zur Gesamtspeicherauslastung

Der Befehl az sphere device app show-memory-stats gibt Statistiken zur Speicherauslastung zurück, die die Gesamtspeicherauslastung, die Nutzung im Benutzermodus und die Spitzennutzung im Benutzermodus für Anwendungen, die auf einem angeschlossenen Gerät ausgeführt werden, enthalten. Auf dem Gerät muss die AppDevelopment-Gerätefunktion konfiguriert sein, um diesen Befehl auszuführen.

Die RAM-Nutzungsstatistiken, die während der Ausführung Ihrer App angezeigt werden, sind:

• Total (Kernel + User Mode): Die gesamte physische Speicherauslastung Ihrer App auf dem System, einschließlich Kernelzuordnungen (z. B. Puffer für Sockets) im Namen Ihrer App oder des Debugservers.
• Benutzermodus: Die Menge des physischen Speichers, die direkt von Ihrer App verwendet wird, der von allen Bibliotheken in ihrem Namen genutzte Arbeitsspeicher (auch als Anon-Zuweisungen bezeichnet) und der vom Debugserver verwendete Arbeitsspeicher.
• Spitzenbenutzermodus: Die maximale Menge an Benutzerarbeitsspeicher, die in der aktuellen Sitzung verwendet wird. Wenn Sie die Speicherauslastung Ihrer Anwendung testen, sollten Sie sicherstellen, dass dieser Wert niemals 256 KiB überschreitet. Zusätzlicher Arbeitsspeicher ist für Kernelzuordnungen reserviert. Dieser Wert wird immer dann zurückgesetzt, wenn Ihre App neu gestartet oder erneut bereitgestellt wird.

Wenn Sie die Speicherbelegungsnachverfolgung für den Heap aktiviert haben und Ihre Anwendung nicht unter dem Debugger ausgeführt wird, werden zusätzliche Zeilen mit Heapspeicherstatistiken angezeigt:

• Heap: App + statische Bibliotheken: Die Kernel- und Benutzerzuordnungen aus Ihrem Code und alle statisch damit verknüpften Bibliotheken.
• Heap: <dynamische Bibliothekszuordnungen>: Zuordnungen aus einzelnen dynamisch verknüpften Bibliotheken, die vom Azure Sphere-Betriebssystem bereitgestellt werden.

Kontinuierliche Überwachung der Speicherauslastung

Um die Speicherauslastung im Laufe der Zeit zu überwachen, können Sie Skripts verwenden, um [az sphere device app show-memory-stats](.) auszuführen. Befehl /reference/az sphere-device.md) in einer Schleife, wie in den folgenden Beispielen beschrieben:

Fenster

Windows-Eingabeaufforderung

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

@echo off

:loop
call az sphere 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, falls sie 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
 -------------------------- -------------

Um das Skript zu beenden, geben Sie STRG+C im Eingabeaufforderungsfenster ein, und antworten Sie dann Y an die Eingabeaufforderung "Batchauftrag beenden?".

Windows PowerShell

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

Linux

#!/bin/sh

while true; do
  az sphere device app show-memory-stats
  sleep 1
done

Arbeitsspeicherauslastung und debugger

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

Die Verwendung des Speicherauslastungsprofilers kann jedoch nützlich sein, wenn Sie Ihre App mit dem Debugger ausführen. Das Festlegen von Haltepunkten und das Durchlaufen von Codezeilen bei gleichzeitiger Beobachtung relativer Änderungen beim Arbeitsspeicherverbrauch kann eine nützliche Technik sein, um die Ursachen von Speicherauslastungsspitzen oder Speicherverlusten zu identifizieren.

Beim Debuggen in Visual Studio wird der Leistungsprofiler automatisch geöffnet, zeigt aber keine Nachverfolgung der Heapspeicherbelegung an.