Eigener Dienst -> Speicherauslastung wächst und wächst...

[cherry]

Hi

bin grad drann mein erster eigener Dienst zu proggen. Eigentlich funktioniert alles so wie es soll. Nur eines nicht. Die Speicherauslastung des Services vergrössert sich um ca. 4 KByte pro sekunde... Proportional zu E/A andere, beides im Taskmgr gesehen... Irgendwo hab ich wohl vergessen speicher freizugeben oder so... aber wo???

so sieht mein ServiceExecute aus:

Delphi-Quellcode:

procedure TSisterWatch.ServiceExecute(Sender: TService);
begin
  //ShowMessage('OnExecute - begin');
  while not Terminated do
  begin
    TRY
      // try to catch a user
      if Username <> '' then
      begin
        // AUTOSCAN
        // THIS SECTION IS FOR USER WHO JUST LOGGED IN
        if (Username <> GetSession) or (Welcome = False) then
        begin
          Username := GetSession;
          // If the logged in user is not on the blacklist it will autoscan now
          if not IgnoreUser then
          begin
            Welcome := True;
            Log('logged in with IPAddress: '+GetIPAddress);
            // get about the users logontime
            logontime := Now;
            // check if the user already exists in the database
            CheckDBforUser(ADOQuery1,ADOStoredProc1);
            // Save to database that the user is logged in
            UpdateUserInfo(Username, 1);
            // get all info from User Table "t_bb_user"
            ADOQuery3.Close;
            ADOQuery3.Parameters.ParamValues['@username'] := username;
            ADOQuery3.Open;
            if ADOQuery3autostart.AsBoolean then
              ScanAndWriteToDB;
            // Activate TCP Server
            ActivateTCPServer;
          end;
        end
        else if StartManScan then
        begin
          try
            // check if the user already exists in the database
            CheckDBforUser(ADOQuery1,ADOStoredProc1);
            ScanAndWriteToDB;
          finally
            // its very important to reset the variable StartManScan
            StartManScan := False;
          end;
        end;
      end
      else
        Username := GetSession;
    EXCEPT
      on e:Exception do
        LOG('FATAL ERROR#@: '+e.Message);
    END;
      ServiceThread.ProcessRequests(False);
      Sleep(1000);
  end;
  //ShowMessage('OnExecute - end');
end;

Der ganze Quellcode im Anhang...

[RavenIV]

Da wird vermutlich bei jedem Durchlauf ein Objekt angelegt aber nie wieder freigegeben.
Also wird jedes mal ein neues Objekt erzeugt.
Somit wächst der Speicherbedarf kontinuierlich.

[SirThornberry]

Was macht GetSession?

[cherry]

Zitat von RavenIV:

Da wird vermutlich bei jedem Durchlauf ein Objekt angelegt aber nie wieder freigegeben.
Also wird jedes mal ein neues Objekt erzeugt.
Somit wächst der Speicherbedarf kontinuierlich.

Ja, darauf bin ich auch schon gekommen... nur weiss ich eben nicht wo!

Zitat von SirThornberry:

Was macht GetSession?

Diese Funktion holt mir den Benutzernamen des angemeldeten Benutzers mit der Hilfe von JWSCL!

Delphi-Quellcode:

function TSisterWatch.GetSession: String;
//var 
//  TS : TJwTerminalServer; --> wurde testhalber als public var von TSisterWatch deklariert
begin
  try
    TS := TJwTerminalServer.Create;
    TS.Connect;
    TS.EnumerateSessions;
    Result := TS.Sessions[0].Username;
    // every second before the first login it raise an exception!
    FreeAndNil(TS); {its very important to free TS memory!}
  except
    FreeAndNil(TS); {its very important to free TS memory!}
  end;
end;

// Ergänzung:

Eigentlich hab ich zuerst gedacht, dass es an eben dieser Funktion liegen muss, da dies die einzige ist, die immer wieder aufgerufen wird... aber TS wird ja immer wieder freigegeben oder nicht?

[SirThornberry]

anstelle von except kannst du mit finally arbeiten dann sparst du dir die doppelte ausführung von freeandnil

[Union]

Warum arbeitest Du zum Merken der Dateiinformationen mit 7 Stringlisten anstelle von Array of TSearchRec ? Der Speicherverbrauch kann auch daran liegen, dass die Datensätze gecached werden. Im Zweifelsfall verwendest Du FastMM oder ähnliche um zu ermitteln, wo das evtl. leckt.

[cherry]

Zitat von SirThornberry:

anstelle von except kannst du mit finally arbeiten dann sparst du dir die doppelte ausführung von freeandnil

Hatte ich anfangs auch so, ich verdächtige aber immernoch stark die Funktion "GetSession" für das Problem... da dies die einzige Funktion ist die alle Sekunde einmal aufgerufen wird! -Und da war ich mir nicht ganz sicher ob TS auch freigegeben wird...?! habs jetzt wieder auf try finally...

Zitat von Union:

Warum arbeitest Du zum Merken der Dateiinformationen mit 7 Stringlisten anstelle von Array of TSearchRec ? Der Speicherverbrauch kann auch daran liegen, dass die Datensätze gecached werden. Im Zweifelsfall verwendest Du FastMM oder ähnliche um zu ermitteln, wo das evtl. leckt.

Die StringListen kann ich am einfachsten und unkompliziertesten behandeln... Array of TSearchRec? was soll mir dass denn bringen?!... --> Jedenfalls kanns zu 99.9% nicht an dem liegen, da das Speicherproblem auch auftritt wenn ScanAndWriteToDB nicht aufgerufen und somit die Listen NICHT erstellt werden...

kann noch mal jmd einen Blick drauf werfen? Gesammte Sourcecode steht als "main.pas" im ersten Beitrag zum DOWNLOAD bereit.

[hoika]

Hallo,

warum nimmst du nicht MemCheck oder FastMM4
und überlässt denen die Suche nach dem Leck ?


Heiko

[Union]

Du verwendest dort die TIndyBaseClientData. Ist da vielleicht der Fehler, denn das wird bei jedem Connect created?
[edit]Und lesen hilft

Zitat:

- Wichtig ! Im OnDisconnect müssen die Daten des Clients auch wieder freigegeben werden

Das findest Du in diesem Beitrag Deines eigenen Threads!
[/edit]

[cherry]

Zitat von Union:

Du verwendest dort die TIndyBaseClientData. Ist da vielleicht der Fehler, denn das wird bei jedem Connect created
[edit]Und lesen hilft

Zitat:

- Wichtig ! Im OnDisconnect müssen die Daten des Clients auch wieder freigegeben werden

Das findest Du in diesem Beitrag Deines eigenen Threads!
[/edit]

oops das habe ich wirklich vergessen freizugeben... bis jetzt bin ich allerdings noch nichtmal dazu gekommen dieses feature meines Dienstes zu testen. Es wurde noch nie eine Verbindung hergestellt und somit wurde noch keine Instanz von TIndyBaseClientData erstellt. (Auch nachdem ich das korrigiert und in OnDisconnect freigegeben habe, besteht mein Problem weiterhin.) Also leider ist das auch NICHT das Problem gewesen!

Zitat von hoika:

warum nimmst du nicht MemCheck oder FastMM4
und überlässt denen die Suche nach dem Leck ?

Hmm.. versuche gerade FastMM einzubinden... aber habs noch nicht zustande gebracht... hab bei den Uses mal als erstes diese Unit "FastMM4" angegeben... was muss ich jetzt noch weiter tun um wo? eine Logdatei? zu erhalten? oder wie funktioniert das jetzt? -Wenn ich das mal einfach so compilliere und den Dienst starte passiert nichts mit FastMM, jedenfalls konnte ich nichts bemerken...

Hab mal irgendwo gelesen, dass wenn ich mein Programm (in meinem fall ein Dienst) beende, sollte ich eine MsgBox von FastMM sehen, auch diese sehe ich NICHT...