AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Fragen zu Delphi Delphi Wie kann man ein "halbes" Memory-Leak finden?

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

Ein Thema von Phoenix · begonnen am 28. Mai 2008 · letzter Beitrag vom 31. Mai 2008
Antwort Antwort
Seite 4 von 4   « Erste     234
Benutzerbild von Sherlock
Sherlock

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.753 Beiträge
 
Delphi 11 Alexandria
 
#31

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

  Alt 29. Mai 2008, 11:39
Dann wirst du wohl den harten Weg des realistischen gehen und regelmäßig neu starten müssen.



Sherlock
Oliver
  Mit Zitat antworten Zitat
alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#32

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

  Alt 29. Mai 2008, 11:43
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.
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.604 Beiträge
 
#33

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

  Alt 29. Mai 2008, 11:52
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.
Sebastian Gingter
Phoenix - 不死鳥
Mein Blog: http://gingter.org
  Mit Zitat antworten Zitat
Benutzerbild von DGL-luke
DGL-luke

Registriert seit: 1. Apr 2005
Ort: Bad Tölz
4.149 Beiträge
 
Delphi 2006 Professional
 
#34

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

  Alt 29. Mai 2008, 11:53
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.
Lukas Erlacher
Suche Grafiktablett. Spenden/Gebrauchtangebote willkommen.
Gotteskrieger gesucht!
For it is the chief characteristic of the religion of science that it works. - Isaac Asimov, Foundation I, Buch 1
  Mit Zitat antworten Zitat
alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#35

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

  Alt 29. Mai 2008, 16:53
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
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.604 Beiträge
 
#36

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

  Alt 29. Mai 2008, 17:14
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.
Sebastian Gingter
Phoenix - 不死鳥
Mein Blog: http://gingter.org
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.016 Beiträge
 
Delphi 12 Athens
 
#37

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

  Alt 29. Mai 2008, 23:24
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
generic

Registriert seit: 24. Mär 2004
Ort: bei Hannover
2.415 Beiträge
 
Delphi XE5 Professional
 
#38

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

  Alt 31. Mai 2008, 00:58
nutzt du Com-Objekte?
z.B. MSHTML, ADO, MSXML?
Coding BOTT - Video Tutorials rund um das Programmieren - https://www.youtube.com/@codingbott
  Mit Zitat antworten Zitat
Benutzerbild von Matze
Matze
(Co-Admin)

Registriert seit: 7. Jul 2003
Ort: Schwabenländle
14.929 Beiträge
 
Turbo Delphi für Win32
 
#39

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

  Alt 31. Mai 2008, 10:32
Zitat von generic:
nutzt du Com-Objekte?
Zitat von Phoenix:
Nein, ich benutze kein Com (zum Glück).
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.604 Beiträge
 
#40

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

  Alt 31. Mai 2008, 10:44
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.
Sebastian Gingter
Phoenix - 不死鳥
Mein Blog: http://gingter.org
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:44 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz