Analysieren des physischen Speicherbedarfs Ihrer Anwendung mit Memory Profiler

Wenn es darum geht, Speicherprobleme effizient zu erkennen und die Leistung zu optimieren, sind die im Memory Profiler angezeigten Informationen sowie deren Genauigkeit von entscheidender Bedeutung. Wir unternehmen erhebliche Anstrengungen in diesem Bereich. In zwei aktuellen Blogs haben Mitglieder meines Teams Memory Profiler 1.0.0 vorgestellt und fünf wichtige Arbeitsabläufe zur Diagnose und Untersuchung speicherbezogener Probleme in Ihrem Spiel geteilt.

In Kürze werden wir Memory Profiler 1.1 veröffentlichen (eine experimentelle Version ist derzeit verfügbar). Er enthält aktualisierte Bezeichnungen und Beschreibungen, die erklären, wie der Speicher funktioniert und wie der Speicherbedarf von Anwendungen berechnet wird.

Da der Speicherbedarf in unseren Gesprächen mit Entwicklern weiterhin ein heißes Thema ist, bin ich hier, um Ihre häufig gestellten Fragen zu beantworten – und zwar insbesondere zu diesen drei Themen:

• Was ist Resident Memory
• So wird der Anwendungsspeicherbedarf berechnet
• So analysieren Sie den Speicherbedarf

Lassen Sie uns die Speicherzuweisung in Unity genauer untersuchen. Wenn die Engine Speicher zuweist, reserviert sie zunächst mehrere Speicherseiten im virtuellen Adressraum, die für die angeforderte Zuweisung geeignet sind. Seiten sind die kleinsten Einheiten der Speicherverwaltung. Virtueller Adressraum und physischer Speicher sind jeweils in Seiten organisiert und die Seitengröße hängt von der verwendeten Plattform ab. Auf x86-Computern beträgt die Seitengröße beispielsweise 4 KB.

Nachdem die Engine genügend Seiten reserviert hat, fordert sie das Betriebssystem (OS) auf, physischen Speicherplatz dem Speicher zu „übergeben“. Aus diesem Grund wird zugewiesener Speicher häufig als „festgelegt“ bezeichnet. Als Nächstes registriert das Betriebssystem, dass den Seiten jetzt physischer Speicher zugewiesen ist und auf sie zugegriffen werden kann. Der von Ihrer Anwendung gemeldete „gesamte zugewiesene Speicher“ erhöht sich dann. Der physische Speicherbedarf Ihrer Anwendung bleibt jedoch gleich.

Der Platzbedarf bleibt gleich, denn obwohl Sie Ihre Region auf physischen Speicher festgelegt haben, sind die meisten Betriebssysteme langsam und sparsam und es gibt daher keine Zuweisung eines bestimmten physischen Speicherorts. Nehmen wir beispielsweise an, Sie entscheiden sich, etwas in die festgelegte Region zu schreiben. Unterhalb der Region befindet sich noch kein physischer Speicher. Daher tritt beim Zugriff darauf ein Seitenfehler auf. Als Reaktion darauf weist der Speichermanager des Betriebssystems eine zuvor verfügbare physische Seite zu, um Ihren Vorgang abzuschließen. Da alle Vorgänge mit Seitengrößengranularität ausgeführt werden, bleiben nicht aufgerufene Seiten der Region leer und ohne zugewiesenen physischen Speicher. Ebenso erhöht sich die Größe des residenten Speichers Ihrer Anwendung um die Gesamtgröße aller physischen Speicherseiten, die zum Abschließen Ihres Vorgangs zugewiesen werden.

Wenn auf eine Seite eine Zeit lang nicht zugegriffen wurde oder der Bedarf an physischem Speicher hoch ist, kann ein Betriebssystem einige Seiten aus Ihrem zugewiesenen Bereich entweder in einen komprimierten Speicher oder eine Seitenauslagerungsdatei auslagern, je nachdem, was auf Ihrer Plattform unterstützt wird.

In diesem Fall bleibt der Ihrer Anwendung zugewiesene Speicher gleich, aber die Größe des residenten Speichers verringert sich.

Wie Sie vielleicht schon bemerkt haben, kann es sein, dass Sie, wenn Sie nur den zugewiesenen Speicher betrachten, durch die Betrachtung der Zuweisung, die Ihren physischen Speicher verbraucht, in die Irre geführt werden. Dies kann dazu verleiten, etwas zu optimieren, das kein Problem darstellt. Dadurch verschwenden Sie nicht nur wertvolle Zeit, sondern sehen auch keinen Unterschied in der Leistung und Stabilität Ihrer Anwendung.

Insgesamt kann der Zustand Ihres Anwendungsspeichers durch dieses Diagramm beschrieben werden:

Zusammenfassend wird der Speicherbedarf wie folgt berechnet:

Physischer Speicherbedarf = Anwendungsresidenter Speicher + komprimierte Anwendungsspeicherseiten

In Memory Profiler 1.1 zeigen die Ansichten „Zusammenfassung“, „Unity-Objekte“ und „Gesamtspeicher“ nicht nur die Größe des zugewiesenen Speichers , sondern bieten auch Informationen zum residenten Speicher. Diese Informationen werden jedoch nur angezeigt, wenn der Memory Profiler-Snapshot mit Unity 2023.1 oder neuer erstellt wurde. Bei älteren Snapshots werden zwar noch aktualisierte Benutzeroberflächen- und Aufschlüsselungsansichten angezeigt, jedoch ohne Informationen zum residenten Speicher.

Die Zusammenfassungsansicht bietet einen allgemeinen Überblick und eine wichtige Messgröße: Gesamtzahl der auf dem Gerät vorhandenen Bewohner. Wenn Ihre Anwendung auf einer Plattform mit begrenztem Speicher ausgeführt werden muss, ist „Total Resident on Device“ von entscheidender Bedeutung für die Überprüfung von Speicherwarnungen und Speicherauslagerungen. Als Faustregel gilt, dass Sie 70 % des gesamten auf einem Gerät verfügbaren physischen Speichers nicht überschreiten sollten.

Für eine detaillierte Analyse können Sie die Ansichten „Unity Objects“ und „All of Memory“ verwenden. Sie müssen „Resident auf dem Gerät“ oder „ Zugewiesen und resident auf dem Gerät“ aus dem Dropdown-Menü auswählen und nach Resident-Größe sortieren, um die Objekte anzuzeigen, die am meisten zum insgesamt verwendeten physischen Speicher beitragen.

Beachten Sie bei der Analyse der residenten Speichernutzung Folgendes:

• Der verwaltete Speicher wird überwiegend resident sein. Mono Heap und Boehm Garbage Collector greifen regelmäßig auf Objekte zu und machen sie resident.
• Der Grafikspeicher (geschätzt) wird als geschätzt angezeigt. Auf den meisten Plattformen haben wir keinen Zugriff auf Informationen zum genauen Standort der Grafikressourcen. Daher schätzen wir die Größe anhand verfügbarer Informationen wie Breite, Höhe, Tiefe, Pixelformat usw. Dies bedeutet auch, dass wir keine Informationen über den Aufenthaltsstatus der Grafikressourcen haben. Aus Gründen der Benutzerfreundlichkeit werden alle Grafikobjekte nur im zugeordneten Ansichtsmodus angezeigt.
• Nicht verfolgt wird der gesamte Speicher, der vom Betriebssystem als von der Anwendung zugewiesen gemeldet wird, für den jedoch keine verlässlichen Informationen zur Quelle der Zuweisung vorliegen. Es könnten native Plug-Ins, Betriebssystembibliotheken, Thread-Stacks usw. sein. Auf einigen Plattformen bieten wir in der Gruppenaufschlüsselung zusätzliche Einblicke darüber, wer diesen Speicher möglicherweise zugewiesen hat.

Bei der Analyse des nativen Speichers, der alle von Objekten verwendeten, nicht von Unity verwalteten Zuweisungen enthält, wird das Element „Reservierter Speicher“ angezeigt. Dies ist der vom Unity Memory Manager zugewiesene Speicher, der jedoch während der Erfassung von keinem Unity-Objekt verwendet wird. Hier einige hilfreiche Informationen:

• Reservierter Speicher kann resident sein, was bedeutet, dass möglicherweise ein Objekt vorhanden war, das vor Kurzem gelöscht wurde.
• Sie können auf zusätzliche Informationen zur Aufschlüsselung des reservierten Speichers zugreifen, indem Sie zu den Speicherprofiler-Einstellungen gehen und das Kontrollkästchen „Aufschlüsselung des reservierten Speichers anzeigen“ aktivieren. Dies ist standardmäßig deaktiviert, da die Aufschlüsselung der reservierten Elemente nicht immer genügend verwertbare Informationen enthält und ein tiefes Verständnis der Funktionsweise von Unity Memory Manager erfordert.
• Weitere Informationen zu Unity Memory Manager und Zuweisungsstrategien finden Sie in der Dokumentation zur Einrichtung der Allocatoren .

Auf einigen Plattformen zeigen wir zusätzliche plattformspezifische Gruppen an, wenn sie eine erhebliche Größe aufweisen, wie z. B. Android Runtime unter Android. Hier einige Hinweise zur Android Runtime:

• Bei einigen Versionen neigt die Android Runtime dazu, eine erhebliche Menge an Speicher vorab zu reservieren, diesen aber nie zu verwenden. In diesem Fall trägt der zugewiesene Speicher nicht zum Speicherbedarf der Anwendung bei und nur der residente Teil davon muss berücksichtigt werden.
• Wenn der in der Android Runtime residente Teil einen erheblichen Teil des Anwendungsspeicherbedarfs beansprucht, verwenden Sie den Android Studio-Profiler, um die in Java vorgenommenen Zuweisungen zu analysieren.
• Obwohl Android standardmäßig weder über eine Auslagerungsdatei noch über eine Speicherkomprimierung verfügt, gestattet der Linux-Kernel Anwendungen, mehr Speicher zu überbelegen und zuzuweisen, als physisch verfügbar ist.
• Stellen Sie beim Aufnehmen sicher, dass Sie das von Ihnen verwendete Gerät verstehen. Einige Anbieter statten den Android-Linux-Kernel mit Speicherkomprimierung (zRAM) oder anbieterspezifischen Tools für Seitenauslagerungsdateien aus.

Wir hoffen, dass dieser Überblick darüber, was Sie in Memory Profiler 1.1 erwartet (experimentelle Version jetzt verfügbar) und die Erkundung verschiedener Themen rund um den Speicherbedarf hilfreich waren.

Mein Team und ich planen, den Memory Profiler weiter zu verbessern, um präzisere und gezieltere Informationen bereitzustellen. Außerdem möchten wir Sie vor möglichen Speicherproblemen warnen und Ihnen mitteilen, wie nahe diese sein könnten. Verfolgen Sie den Fortschritt unserer Produkt-Roadmap und sagen Sie uns, was Sie denken.

Teilen Sie uns in den ForenIhr Feedback mit. Achten Sie auf neue technische Blogs von anderen Unity-Entwicklern im Rahmen der laufenden Technik aus der Trenches- Reihe.