Wie sieht eine fragmentierte Erinnerung aus?

Question

Ich habe eine mobile Anwendung, die mit der Zeit immer langsamer wird. Meine Vermutung (zum Teil genährt durch dieser Artikel Ich vermute, dass dies auf die Fragmentierung des Speichers zurückzuführen ist, die die Anwendung verlangsamt, aber ich bin mir nicht sicher. Hier ist ein hübsches Diagramm des Speicherverbrauchs der App im Laufe der Zeit:

fraggle rock http://kupio.com/image-dump/fragmented.png

Die 4 Spitzen im Diagramm sind 4 Ausführungen der exakt gleichen Aufgabe in der App. Ich starte die Aufgabe, es ordnet ein Bündel von Speicher, es sitzt für ein bisschen (die flache Linie oben) und dann stoppe ich die Aufgabe. An diesem Punkt ruft es System.gc(); und der Speicher wird bereinigt.

Wie man sieht, dauert jeder der 4 Durchläufe der exakt gleichen Aufgabe länger. Die Tiefpunkte im Graphen kehren alle auf die gleiche Ebene zurück, so dass es zwischen den Aufgabenläufen keine Speicherlecks zu geben scheint.

Was ich wissen möchte, ist, ob die Speicherfragmentierung eine mögliche Erklärung ist, oder sollte ich zuerst woanders suchen, da ich bereits viel gesucht habe? Die Tiefpunkte im Diagramm sind relativ niedrig, so dass ich davon ausgehe, dass der Speicher in diesem Zustand nicht sehr fragmentiert ist, da es nicht viele kleine Speicherlöcher geben kann, die Probleme verursachen.

Ich weiß allerdings nicht, wie der j2me memory allocator funktioniert, also weiß ich es wirklich nicht. Kann jemand einen Rat geben? Hat jemand anderes Probleme damit und erkennt das Speicherprofil der App?

Answer 1

Wenn Sie etwas Zeit haben, können Sie Ihre Theorie testen, indem Sie den Speicher mit Hilfe von Speicherpooltechniken wiederverwenden: Jeder Durchlauf der Aufgabe verwendet die "gleichen" Speicherabschnitte, indem er sie aus dem Pool abruft und zur Freigabezeit zurückgibt.

Wenn Sie nach dieser Untersuchung immer noch Leistungseinbußen feststellen, liegt das Problem nicht an der Speicherfragmentierung. Teilen Sie uns Ihre Ergebnisse mit, damit wir Ihnen bei der weiteren Fehlersuche helfen können.

Answer 2

Speicherfragmentierung würde dafür verantwortlich sein... was nicht klar ist, ist, ob die Nutzung des Speichers durch die Apps Paging verursacht? dies würde auch die Dinge verlangsamen.... und könnte die gleichen Probleme verursachen.

Answer 3

Wenn das Problem wirklich eine Speicherfragmentierung ist, können Sie nicht viel dagegen tun.

Bevor Sie jedoch verzweifelt aufgeben, sollten Sie Ihre Anwendung mit einem Ausführungsprofiler laufen lassen, um zu sehen, ob sie viel Zeit mit der Ausführung an einer unerwarteten Stelle verbringt. Es ist möglich, dass die Verlangsamung tatsächlich auf ein Problem in Ihren Algorithmen zurückzuführen ist und nichts mit der Speicherfragmentierung zu tun hat. Wie bereits gesagt wurde, sollten J2ME Garbage Collectors nicht unter Fragmentierungsproblemen leiden.

Answer 4

Schauen Sie sich die Müllabfuhrstatistiken an. Wenn Ihre Theorie zutrifft, sollten Sie beim letzten Durchlauf viel mehr Speicher haben als beim ersten. Ein anderer Gedanke könnte sein, dass etwas anderes Ihren Speicher auffrisst, so dass Ihre Anwendung weniger hat.

Mit anderen Worten: Zeit für den Profiler :)

Answer 5

Auf welchem Betriebssystem läuft das Programm? Ich habe einige Erfahrung mit Windows CE5 (oder Windows Mobile) Geräten. Die Speicherarchitektur auf Betriebssystemebene von CE5 ist ziemlich kaputt und wird bei speicherintensiven Anwendungen bald versagen. Ihr Diagramm weist keine Skalen auf, aber jeder Prozess erhält unter CE5 nur 32 MB Adressraum. Die VM und die gemeinsam genutzten Bibliotheken beanspruchen ihren Teil davon, so dass nur noch sehr wenig übrig bleibt. Die einzige Möglichkeit, dies zu umgehen, besteht darin, den zugewiesenen Speicher wieder zu verwenden, anstatt ihn an den Collector zurückzugeben und später neu zuzuweisen. Das ist natürlich viel mehr Low-Level-Programmierung, als Sie normalerweise in Java machen wollen, aber auf dieser Plattform haben Sie vielleicht kein Glück.