IntraWeb - Speichernutzung

[hirnstroem]

'loha Folks,

ein relativ umfangreiches IntraWeb (Webapplikation) Projekt füllt nach und nach den Speicher. Dies ist wohl aus zur Laufzeit erstellte Komponenten, von welchen es einige gibt, zurückzuführen. Nun wollte ich mich erkundigen, was beispielsweise mit folgendem Konstrukt geschieht wenn das dazugehörige Formular geschlossen wird:

Delphi-Quellcode:

procedure TfrmFacility_Management_Door_Control_Select.grdDeviceRenderCell(
  ACell: TIWGridCell; const ARow, AColumn: Integer);
begin
{
  Title Row Sort Symbols
}
  if (ARow = 0)
    and (AColumn >= 0)
    and (AColumn < grdDevice.Columns.Count -1) then
  begin
    with ACell do
    begin
      Control := TIWImageFile.Create(Self); // hier wird ein Control kreiert, welches natürlich den Speicher nutzt
      with TIWImageFile(Control) do
      begin
        Hint := 'Sortieren';
        Tag := AColumn;
        UserSession.SetSortImage(UserSession.DataSet, TIWDBGridColumn(grdDevice.Columns.
          Items[(TIWImageFile(Control)).Tag]).DataField, TIWImageFile(Control));
        OnClick := Sort;
      end;
    end;
  end;
end;

Beim verlassen der Seite wird das Formular mit der Release Methode entfernt und sollte demnach den von ihm belegten Speicherplatz wieder freigeben. Nun meine ich, dass wenn sämtliche zur Laufzeit erzeugten Komponenten dem Formular angehören (Create(Self)), werden diese automatisch mit dem Schliessen des Formulares aus dem Speicher entfernt. Wenn ich jetzt allerdings sagen wir 100 User Sessions öffne, und in jeder dieser Sessions eine umfangreiche Seite lade (auf welcher viele solche zur Laufzeit erzeugten Komponenten verwendet werden), wird der speicher erwartungsgemäss gefüllt. Werden anschliessend sämtliche User Sessions beendet, somit alle Formulare und sonstigen Daten eines Users "zerstört", so nimmt die Speicherausnutzung nicht in dem Masse ab, wie ich das eigentlich erwarten würde.

Nun bin ich mir nicht sicher, ob denn die Eltern auch wirklich für ihre Kinder haften?!

Viel anderes wird zur Laufzeit nicht erzeugt und wenn, dann fast ausschliesslich mit dem Formular als Owner. Manche vom User unabhängig agierende Threads gibt es noch, welche ein recht dynamisches Leben führen, sich aber alle beim Terminieren selbst wieder freigeben.

Weiss jemand Rat?

Grüsse
hirnstroem

[Bernhard Geyer]

Zitat:

Zitat von hirnstroem

Nun bin ich mir nicht sicher, ob denn die Eltern auch wirklich für ihre Kinder haften?!

Teilweise.
Solange die Eltern von ihren Kinden wissen (.Create(Self)) können sie diese Auffordern aufzuräumen (.Free). Ob die Kinder nun wirklich alles aufgeräumt haben, kann man nur durch Kontrolle feststellen (z.B. FastMM).

[hirnstroem]

Dann müssten der Speicher eigentlich korrekt wieder freigegeben werden, da alles was keinen Owner hat explizit freigegeben wird und alles was einen Owner hat spätestens mit dem freigeben desselbigen auch freigegeben werden müsste.

Werde nun mit FastMM (danke für den Tipp) versuchen festzustellen was schief läuft und dies dann kund tun.

[hirnstroem]

Beim Beenden der Applikation erscheint nun folgende Meldung:

This application has leadked memory...

1 - 12 bytes: TInThreadSafeInteger x 1
21- 28 bytes: TIdCriticalSection x 2
61 - 68 bytes: TRxThread x 1, TBusScanThread x 1

Die ersten zwei Zeilen sagen mir überhaupt nichts, für letztere hingegen bin ich verantwortlich. Die zwei besagten Threads sind ständig am laufen, werden aber beim Beenden der Applikation terminiert (.Terminate) und sollten sich selber freigeben (.FreeOnTerminate := True).

Ich habe schon versucht mit ".WaitFor" darauf zu warten, bis die zwei Threads sich selber terminiert sind, da tat sich aber nichts.

Nun wage ich aber zu bezweifeln, dass dies der Grund für die übermässige Speichernutzung ist, da die Threads nichts anderes tun, als, zum einen, Pakete von Geräten welche an einem CAN-Bus angeschlossen sind zu empfangen und diese in einen Buffer abzulegen (TRxThread) und, zum anderen, den Bus in periodisch zu scannen um den daran angeschlossenen Geräten beispielsweise die Uhrzeit mitzuteilen (weil der eingesetzte Quarz-Baustein relativ schnell aus dem Takt läuft). Dabei wird aber bei beiden Threads nichts zur Laufzeit generiert, ausser die Threads selbst natürlich.