Dienst frisst Speicher - ist Indy schuld?

[Thomas9o9]

Hallo,

ich habe einen Dienst für Windows entwickelt, der über TCP/Ip Kommandos entgegen nimmt und beantwortet. Der Dienst ist dafür ausgelegt, dauerhaft auf Servern zu laufen. Leider zeigt sich, dass der Dienst im Laufe der Zeit immer mehr Speicher verbraucht.
Auffällig ist, dass vor allem der virtuelle Speicher steigt.
Ich habe bereits den gesamten Quellcode geprüft, ob es irgendwo Speicherlecks gibt.
Wenn ich das Programm als EXE laufen lasse, zeigt sich das gleiche Verhalten.
Für die TCP/IP Kommunikation nutzte ich die Indy 10 Komponente TidTcpServer und genau diese habe ich im Verdacht. Ich vermute, das die Indy Komponente neue Threads erzeugt, diese aber nicht wieder beendet.

Kennt vielleicht jemand dieses Verhalten oder hat jemand eine Idee, woran es liegen könnte?

Hier noch ein paar zusätzliche Informationen:

Delphi 2006
Indy 10
Datenbankzugriff per Ibobjects auf Firebird
der Dienst wird ca. alle 10 Sekunden von ca. 10 Rechner kontaktiert.

Speicherverbrauch:
Tag,Speicher,davon ausgelagert
1,11 MB,04 MB
2,27 MB,12 MB
3,24 MB,18 MB
4,37 MB,26 MB
5,54 MB,37 MB
6,65 MB,44 MB
7,63 MB,58 MB

[Luckie]

Also ich glaube mal gehört zu haben, dass die Indianer Speicherlecks hätten - bin mir aber nicht sicher.

[nahpets]

Hallo,

schau mal bitte hier post1059703.html und/oder post974482.html ob Du damit weiterkommst.
Eventuell hilft Dir auch eine der Fundstellen von Google indy +memory +leak weiter.
Wo Du ggfls. genau suchen musst, kann ich Dir leider nicht sagen.

[Thomas9o9]

Hallo und vielen Dank für die Antworten,

ich werde nun zunächst mal noch genauer analysieren, welche Programmanweisungen wieviel Speicher verbrauchen und wann dieser wieder freigeben wird...

[Assertor]

Hi,

Zitat von Luckie:

Also ich glaube mal gehört zu haben, dass die Indianer Speicherlecks hätten - bin mir aber nicht sicher.

Nein, wir geben lediglich zwei Objekte zum Prozessende nicht automatisch frei (TIdThreadSafeInteger und TIdCriticalSection), damit falls Aufrufe vom OS/WinSock noch laufen diese korrekt bedendet werden und die Anwendung nicht unnötig "hängenbleibt".

Das ist aber seit Jahren bekannt, Dokumentiert und abschaltbar. Iirc ursächlich ältere Win Versionen, die ja immer noch von Indy supportet werden, auch wenn nicht mehr von MS. Selbst die üblichen Exception-Tracker und Leak-Detektoren kommen damit klar (angepasste FastMM in Delphi, EurekaLog, madExcept).

Aber ich würde eher das Problem im Code des Threaderstellers vermuten. Eine "Sichtprüfung" und das "Gefühl" es läge an Indy ist ja keine geeignete Methode ein Speicherleck zu finden... Also, (Remote-) Debuggen, Logs schreiben, Objekte überwachen, Testcases her und bitte auch z.B. FastMM4 im FullDebugMode und am besten mit FullDebugModeScanMemoryPoolBeforeEveryOperation := True; (oder manuell ScanMemoryPoolForCorruption, das wird sonst sehr langsam gerade bei DBs!).

AQtime oder der Win App Verifier können auch dabei helfen gerade Handle Leaks zu finden.

Das letzte Mal, wo ich mich habe überzeugen lassen, es läge an Indy, verbrachte ich 3 Tage mit Debugging und konnte es nicht reproduzieren. Ich sprach mit Pierre le Riche (der vom FastMM4) und am Ende das Ergebnis: Der Fragende hatte eine andere Include-Datei für FastMM irgendwo im Searchpath...

Für konkrete Bugreports bin ich immer offen, bitte Beispielprojekt her und wir legen los Aber bitte kein pauschales Indy Bashing

Gruß Assertor