Hallo zusammen,

ich habe vor 2 Jahren ein ziemlich grosses Delphi-Projekt übernommen, ein Riesenframework mit ziemlich grosser Oberfläche und ziemlich vielen Bugs.

Mein größtes Problem ist im Moment ein Speicherproblem, d.h. der Arbeitsspeicher läuft voll und ich weiss nicht wieso. Speicherlecks gibt es auch (FastMM sei Dank), allerdings tritt das Speicherproblem schon beim Laden des Projekts auf, ist also höchstwahrscheinlich auf die Datenstruktur/Datenhaltung im Speicher zurückzuführen.

Das Projekt ist gar nicht so gross, serialisiert (XML) etwa 20-30 MB, also weit entfernt von 2GB, selbst wenn man den Delphi-Overhead einrechnet.

Ich würde jetzt gerne mal eine Übersicht der im Speicher befindlichen Objekte sehen, und zwar als Übersicht Klassenname/Anzahl/Speicherbedarf, damit ich weiss welche Objekte (wir haben über 1000) Amok laufen und wo ich beim Debuggen ansetzen muss.

Kennt jemand ein Programm das das kann? Kann ich FastMM dazu bringen, mir nicht die Memory-Leaks, sondern *alle* im Speicher befindlichen Objekte auszuspucken?

Ach ja, ich nutze Rad Studio 2009.

Danke und viele Grüße
Eike

How Much Memory Is Your Delphi Program Occupying? ... and more...
The TProcessMemoryCounters record wraps up the Windows API PROCESS_MEMORY_COUNTERS structure. Here's the meaning of the other fields:

PageFaultCount - the number of page faults.
PeakWorkingSetSize - the peak working set size, in bytes.
WorkingSetSize - the current working set size, in bytes.
QuotaPeakPagedPoolUsage - The peak paged pool usage, in bytes.
QuotaPagedPoolUsage - The current paged pool usage, in bytes.
QuotaPeakNonPagedPoolUsage - The peak nonpaged pool usage, in bytes.
QuotaNonPagedPoolUsage - The current nonpaged pool usage, in bytes.
PagefileUsage - The current space allocated for the pagefile, in bytes.
Those pages may or may not be in memory.
PeakPagefileUsage - The peak space allocated for the pagefile, in bytes.

http://delphi.about.com/od/delphitip...mory_usage.htm

zusammenfalten · markieren

Delphi-Quellcode:

uses PsAPI

function CurrentMemoryUsage: Cardinal;
 var
   pmc: TProcessMemoryCounters;
 begin Result:=0;
   pmc.cb := SizeOf(pmc) ;
   if GetProcessMemoryInfo(GetCurrentProcess, @pmc, SizeOf(pmc)) then
     Result := pmc.WorkingSetSize
   else
     RaiseLastOSError;
 end;

 function PageFaultCount: Cardinal;
 var
   pmc: TProcessMemoryCounters;
 begin Result:=0;
   pmc.cb := SizeOf(pmc) ;
   if GetProcessMemoryInfo(GetCurrentProcess, @pmc, SizeOf(pmc)) then
     Result := pmc.PageFaultCount
   else
     RaiseLastOSError;
 end;

 function PeakWorkingSetSize: Cardinal;
 var
   pmc: TProcessMemoryCounters;
 begin Result:=0;
   pmc.cb := SizeOf(pmc) ;
   if GetProcessMemoryInfo(GetCurrentProcess, @pmc, SizeOf(pmc)) then
     Result := pmc.PeakWorkingSetSize
   else
     RaiseLastOSError;
 end;

 function WorkingSetSize: Cardinal;
 var
   pmc: TProcessMemoryCounters;
 begin Result:=0;
   pmc.cb := SizeOf(pmc) ;
   if GetProcessMemoryInfo(GetCurrentProcess, @pmc, SizeOf(pmc)) then
     Result := pmc.WorkingSetSize
   else
     RaiseLastOSError;
 end;

 function QuotaPeakPagedPoolUsage: Cardinal;
 var
   pmc: TProcessMemoryCounters;
 begin Result:=0;
   pmc.cb := SizeOf(pmc) ;
   if GetProcessMemoryInfo(GetCurrentProcess, @pmc, SizeOf(pmc)) then
     Result := pmc.QuotaPeakPagedPoolUsage
   else
     RaiseLastOSError;
 end;

 function QuotaPagedPoolUsage: Cardinal;
 var
   pmc: TProcessMemoryCounters;
 begin Result:=0;
   pmc.cb := SizeOf(pmc) ;
   if GetProcessMemoryInfo(GetCurrentProcess, @pmc, SizeOf(pmc)) then
     Result := pmc.QuotaPagedPoolUsage
   else
     RaiseLastOSError;
 end;

 function QuotaPeakNonPagedPoolUsage: Cardinal;
 var
   pmc: TProcessMemoryCounters;
 begin Result:=0;
   pmc.cb := SizeOf(pmc) ;
   if GetProcessMemoryInfo(GetCurrentProcess, @pmc, SizeOf(pmc)) then
     Result := pmc.QuotaPeakNonPagedPoolUsage
   else
     RaiseLastOSError;
 end;

 function QuotaNonPagedPoolUsage: Cardinal;
 var
   pmc: TProcessMemoryCounters;
 begin Result:=0;
   pmc.cb := SizeOf(pmc) ;
   if GetProcessMemoryInfo(GetCurrentProcess, @pmc, SizeOf(pmc)) then
     Result := pmc.QuotaNonPagedPoolUsage
   else
     RaiseLastOSError;
 end;

 function PagefileUsage: Cardinal;
 var
   pmc: TProcessMemoryCounters;
 begin Result:=0;
   pmc.cb := SizeOf(pmc) ;
   if GetProcessMemoryInfo(GetCurrentProcess, @pmc, SizeOf(pmc)) then
     Result := pmc.PagefileUsage
   else
     RaiseLastOSError;
 end;

 function PeakPagefileUsage: Cardinal;
 var
   pmc: TProcessMemoryCounters;
 begin Result:=0;
   pmc.cb := SizeOf(pmc) ;
   if GetProcessMemoryInfo(GetCurrentProcess, @pmc, SizeOf(pmc)) then
     Result := pmc.PeakPagefileUsage
   else
     RaiseLastOSError;
 end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
Memo1.Clear;
Memo1.Lines.add(FormatFloat('Memory used: ,.# KB', CurrentMemoryUsage / 1024));
Memo1.Lines.add('PageFaultCount: '+ IntToStr(PageFaultCount));
Memo1.Lines.add(FormatFloat('PeakWorkingSetSize: ,.# KB', PeakWorkingSetSize / 1024));
Memo1.Lines.add(FormatFloat('WorkingSetSize: ,.# KB', WorkingSetSize / 1024));
Memo1.Lines.add(FormatFloat('QuotaPeakPagedPoolUsage: ,.# KB', QuotaPeakPagedPoolUsage / 1024));
Memo1.Lines.add(FormatFloat('QuotaPagedPoolUsage: ,.# KB', QuotaPagedPoolUsage / 1024));
Memo1.Lines.add(FormatFloat('QuotaPeakNonPagedPoolUsage: ,.# KB', QuotaPeakNonPagedPoolUsage / 1024));
Memo1.Lines.add(FormatFloat('QuotaNonPagedPoolUsage: ,.# KB', QuotaNonPagedPoolUsage / 1024));
Memo1.Lines.add(FormatFloat('PagefileUsage: ,.# KB', PagefileUsage / 1024));
Memo1.Lines.add(FormatFloat('PeakPagefileUsage: ,.# KB', PeakPagefileUsage / 1024));
end;

Praktisch gesehn und da es in Delphi (eigentlich) keine zentrale Stelle gibt, wo reservierter Speicher "registriert" wird, kann man im Nachhinein garnicht feststellen was sich in welchem Speicherbereich befindet.

Nimm dir einfach mal sowas wie Integer, Records oder ein Array[x..y] of Char. Da hast du nur den Daten-Inhalt im RAM rumliegen, aber nirgendwo ist die RTTI direkt damit verknüpft.
(z.B. 4 Byte im Speicher können also ganz gut ein Integer, 4 Bytes, 2 Words, ein Array[0..3] of AnsiChar oder auch garnichts sein, da diese 4 Bytes grade nicht benutzt werden)

Man kann höchstens über windige und nicht immer zuverlässige Tests versuchen rauszufinden, ob es sich z.B. um ein Objekt handet. Seit D2009 könnte man eventuell auch noch AnsiStrings und UnicodeStrings erkennen. (alles immer schön mit der Chance auf viele False-Positives)

Man könnte den FastMM in den FullDebug-Modus versetzen, oder sich selbst dazwischenhängen, dann jeweils beim reservieren von Speicher sich den Stacktrace, bzw. die Rücksprungadresse ansehn, und bekommt so mit wer und von wo die Anfrage kommt, worüber man besser erkennen kann, um was es sich handelt, da der Speicher von Strings und Objekten ja standardmäßig in ganz bestimmten Prozeduren/Methoden reserviert wird.
Wenn man sich diese infos dann alle merkt, dann könnte man auch später oftmals noch gut erkennen was von wo kam.
Es gibt da auch schon ein irgendwelche Frameworks, welche einem dabei helfen. (Ich glaub vor Kurzem war auch was zum Speicheranalysieren hier in der DP zu finden)

Als Tool könnte ich, wenn es was kosten darf, AutomatedQA/SmartBear AQTime empfehlen. Das kann auch "profilen" wo/wann genau und wie viel Speicher angefordert / freigegeben wurde.
PMM

Du könntest hier mal schauen: http://ddobjects.de/ddserver.
Im Gegensatz zum FastMM zeigt Dir das Tool die Verwendung live an, was gerade dann vorteilhaft ist wenn es sich nicht um Leaks handelt sondern um wachsenden Speicherbedarf welcher bei Programmende sauber abgeräumt wird. Das Tool kann Objekte, Records, Arrays und Strings tracen, zeigt Dir die Callstacks an, unterstützt mehrere Threads als auch die Verwendung von Packages. Das eine oder andere Utility in dem Paket ermöglich auch bspw. die zu frühe Freigabe von Speicher zu erkennen (eine Exception im Destructor welche darauf beruht, dass ein Objekt "irgendwo" frühzeitig freigegeben worden ist kann mitunter ziemlich schwer zu beheben sein...), enthält einen (noch nicht sehr ausgereiften) Exceptionhandler sowie einen Threadviewer welcher Dir den Status (incl. Callstacks) der einzelnen Threads der Applikation anzeigt.

ACHTUNG! Die Version auf der Webseite ist veraltet! Ich überarbeite das Tool derzeit. Bei Interesse schickst Du mir bitte eine PN und ich kann es Dir in den nächsten Tagen zukommen lassen. Bin derzeit im Umzugsstress, kann also nicht sofort reagieren.

Grüße,
S.

Hi, schon mal danke für die Antworten.

@sahimba, ich werde später auf dich zurückkommen. Bin im Moment noch mit anderen Dingen beschäftigt und muss erstmal Zeit für so eine Analyse freiräumen.

Zitat von himitsu:

Praktisch gesehn und da es in Delphi (eigentlich) keine zentrale Stelle gibt, wo reservierter Speicher "registriert" wird, kann man im Nachhinein garnicht feststellen was sich in welchem Speicherbereich befindet.

Genau deshalb hatte ich gehofft dass es einen Profiler gibt, der schon bei der Erstellung der Objekte "mitzählt". Ggf. müsste ich das über unsere ObjectFactory(s) machen, dann weiss ich allerdings nicht wieviele "direkt" erstellte Objekte mir entgehen. Wie gesagt, es geht hier um über 1000 verschiedene Klassen, und deshalb hilft mir eigentlich nur der Klassenname weiter.

Zitat von eike42:

Genau deshalb hatte ich gehofft dass es einen Profiler gibt, der schon bei der Erstellung der Objekte "mitzählt".

Genau das tut mein Profiler inkl. einer weiteren Übersicht, welche die aktuelle Anzahl der Objekte einer jeden Klasse anzeigt, wie viele maximal zu gleicher Zeit erzeugt waren sowie die Gesamtanzahl aller erzeugten/freigegebenen Objekte. Auch auf dem Wege lässt sich relativ einfach ein wachsender Speicherbedarf zur Laufzeit erkennen und gezielt beheben.

Melde Dich dann, sobald Du Zeit freigeräumt hast.

Grüße,
S.

Zitat von sahimba:

Zitat von eike42:

Genau deshalb hatte ich gehofft dass es einen Profiler gibt, der schon bei der Erstellung der Objekte "mitzählt".

Genau das tut mein Profiler inkl. einer weiteren Übersicht, welche die aktuelle Anzahl der Objekte einer jeden Klasse anzeigt, wie viele maximal zu gleicher Zeit erzeugt waren sowie die Gesamtanzahl aller erzeugten/freigegebenen Objekte. Auch auf dem Wege lässt sich relativ einfach ein wachsender Speicherbedarf zur Laufzeit erkennen und gezielt beheben.

Melde Dich dann, sobald Du Zeit freigeräumt hast.

Grüße,
S.

Wow, das habe ich aus deiner Webseite (sorry) nicht herauslesen können.

Danke und Gruss
Eike

Also, daran hätte ich auch Interesse.

P.S.: Ist das das Tool, das Du in Berlin auf den DT erwähnt hast?

Zitat von DeddyH:

P.S.: Ist das das Tool, das Du in Berlin auf den DT erwähnt hast?

Yup, das ist es. Schon eine ganze Weile her, das war 2011...