Wie kann man ein "halbes" Memory-Leak finden?

[Sherlock]

Dann wirst du wohl den harten Weg des realistischen gehen und regelmäßig neu starten müssen.



Sherlock

[alzaimar]

Oh, das ist kniffelig:

1. Du hast den Code geschrieben, also: Schuld eigene, wenn Du nachsitzen musst.
2. Dann wird er eben umorganisiert. Du sollst ja nicht gleich den ganzen Code reviewen (obwohl das ne gute idee wäre, weil du dich verhaspelt hast).

Kannst Du denn entscheiden, ob ein Objekt 'dort' hingehört bzw. unberechtigterweise noch lebt? Wenn ja, nimm meinen Trick und suche halt immer wieder in der Objektliste (in der sich die Objekte bei der Instantiierung ja eingetragen haben) Objekten, die es nicht geben sollte. Von mir aus mit einem Timer, oder durch einen 'SCAN' Button oder sonstwas.

[Phoenix]

Es ist ja nichtmal raus ob das wirklich meine Schuld ist. Das ist ja das ganze Problem. Das kann auch irgendwo am Framework oder an was anderem liegen. Ich kann halt nur nicht ausschliessen, dass es bei mir liegt. Deswegen muss ich jetzt mit möglichst wenig Aufwand eine Aussage treffen können ob es an meinem Code liegt oder nicht.

Wenn nicht, bin ich nämlich fein raus und dann wissen wir, dass sich die Kollegen nochmal über ihre Sachen Gedanken machen müssen. Wenn es an mir liegt, dann ist der Aufwand eines Code-Reviews durchaus berechtigt und dann werden wir den auch machen. Nur jetzt eben nicht, weil es gut sein kann dass wir dann über ne Woche da dran sitzen, mit Bleistiftcompiler nochmal alles Nachrechnen und hinterher sagen: "Ne, ist alles okay hier. Das Problem liegt woanders." Und das darf eben nicht passieren.

Und nein. Den Baum einmal komplett zu traversieren ist aus Performancegründen nicht möglich, zudem ich dabei Jeden einzelnen Node mit jedem anderen vergleichen müsste, ob ich tatsächlich Duplikate habe die nicht mehr angegriffen werden. Der würde bei der Knotenanzahl Jahre rechnen..

Die Objektliste habe ich jetzt mal implementiert, und ich werde die jetzt regelmässig in ein File schreiben (Timestamp der Erzeugung, eine eindeutige Objekt-ID, der Klassenname und zusätzliche Identity-Informationen).

So kann ich durch die Änderungen in dem File hoffentlich mindestens sehen, ob später neue Objekte hinzukommen, die eigentlich andere Objekte ersetzen würden obwohl diese noch da bleiben.

[DGL-luke]

dem kunden stellt sich dann eben die wahl, dich das ganze prüfen zu lassen, oder alle 3?6?12? Stunden alles komplett neu zu initialisieren.

Oder kannst du das ohne Neustart machen? EInfach selber mal alles neu initialisieren, sobald der speicher knapp wird (du 100.000 objekte in der db hast)?

Bei fragmentierung hilft das eventuell auch wenig; da musst du dir dann was einfallen lassen, wie du das vermeidest; wenn du einfach mal einen string mit 500MB größe anforderst und dann wieder nilst, sollte sich der Delphi-Speichermanager (ach ja richtig, ==fastmm ab delphi 2006) da am Ende des RAMs (oder des Pagefiles, das wär dann evtl. leicht kontraproduktiv) 500MB zusammengehörigen virtuellen speicher reservieren und nicht so schnell wieder (an windows) zurückgeben. da kann er dann ganz gemütlich deine objekte eins nach dem anderen reinlegen.

eine neuorganisation (komplette reinitialisierung deiner objekte) sollte dann dazu führen, dass erstmal der komplette 500MB speicherbereich bei delphi wieder als "frei, aber noch meins" interpretiert wird und die wieder neu erstellten objekte schön eins nach dem anderen wieder reingelegt werden.
EDIT: das führt aber dann zwischenzeitlich zu doppelter buchhaltung, d.h. du musst alle deine daten woanders hin wegschreiben, auf die festplatte o.ä..... denn du musst natürlich erst ALLES freigeben, bevor du dann ALLES wieder neu erstellst.

Aber das sind hier alles Sachen, die eigentlich ein Speichermanager von sich aus machen sollte. Ohne Low-Level-Sachen versuchen, den Speichermanager zu einem bestimmten Verhalten zu überreden, kann ordentlich in die Hose gehen.

[alzaimar]

Ich werde mal kurz drastisch. Nicht hauen.

Du lamentierst und drückst Dich um die Lösung

Zitat von Phoenix:

Es ist ja nichtmal raus ob das wirklich meine Schuld ist...Ich kann halt nur nicht ausschliessen, dass es bei mir liegt.

Dann sorge dafür, das es sicher ist, das es nicht deine Schuld ist. Entweder Du findest KEINEN Fehler, oder du FINDEST einen und REPARIERST ihn.

Zitat von Phoenix:

Den Baum einmal komplett zu traversieren ist aus Performancegründen nicht möglich

Wieso? Du schreibst ein TEST-TOOL UM DEN FEHLER ZU FINDEN, da ist die Performance egal. Du willst schließlich den Fehler finden. Und Jahre rechnen würde der auch nicht. Wozu gibt es Hashmaps? Und selbst wenn Du für einen Scan 10 Stunden benötigst. Na und? Hinterher hast Du den/die Übeltäter!

Wie gesagt. Nicht hauen

[Phoenix]

Neee, ich haue nicht. Scheint wohl auch nicht nötig zu sein.

Dank Deiner Idee mit der zentralen Objekt-Liste konnte ich zumindest schonmal nachvollziehen, dass bei allen getesteten Konstellationen die Anzahl der instanzierten Objekte konstant bleibt. Die ID's erhöhen sich ständig, aber die Gesamtanzahl ist Konstant. Ergo bleibt beim umräumen und wegwerfen und neu Erzeugen nichts 'über'.

Allerdings wird da öfter umgeräumt, also kann es tatsächlich durch das ständige verkürzen und verlängern von den dynamischen Arrays die diese Objekte vorhalten zu einer Fragmentierung kommen. Wenn das das Problem ist muss ich halt auf TList umstellen. Das ist aber um längen einfacher.

[himitsu]

Zitat:

Oha.
Davon wird (in diesem Fall leider) an manchen Stellen exzessiver Gebrauch gemacht.

dann laß dir doch mal die MemoryMap anzeigen ... da sollte man doch erkennen können, wie die fragmentierung aussieht.

Zitat:

Würde sich das Fragmentierungs-Problem mit dem FastMM lösen?

es kommt auf die Größe und Art der Speicheranfragen an.

allgemein kommt es bei kleinen änderungen z.B. eines dynamischen Arrays zu einer geringeren Defragmentierung, da dieser bei einem Realloc nich direkt die gewünschte Größe sofort ändert, sondern versucht es in größeren Schritten anzupassen.

[generic]

nutzt du Com-Objekte?
z.B. MSHTML, ADO, MSXML?

[Matze]

Zitat von generic:

nutzt du Com-Objekte?

Zitat von Phoenix:

Nein, ich benutze kein Com (zum Glück).

[Phoenix]

Hehe Generic, das hattest Du doch schonmal gefragt *g*

Also, stand zum WE:
Wie schon gesagt: Die Anzahl der Objekte bleibt immer Konstant.

Was ich interessant fand: Die Anwendung holt sich initial beim Starten ca. 40 MB Speicher. Wird sie minimiert fällt dieser Speicherverbraucht drastisch ab: unter 1 MB! Maximiere ich sie wieder, holt sie sich dann wieder ca. 20 MB und wächst langsam aber stetig wieder an.
Ich find diesen Unterschied leicht krass. So ein Verhalten beobachte ich bei vielen Anwendungen, aber von 40 auf unter 1 MB hat es noch keine andere Applikation geschafft.

Sind das einmal angezeigte, aber dann nicht mehr verwendete Gui-Elemente wie z.B. Grafiken die dann ggf. von Windows weggeschmissen werden?

Naja.. am Montag geht die Suche weiter.