Sockets - Memoryleak?



  • Unter dem folgenden Link ist es eine Solution, die einen Socket-Server und einen Socket-Client implementiert:

    http://download.microsoft.com/download/8/1/a/81ace6b8-ee48-4aea-9ee4-b2ad50a22c5f/csharp09182003_sample.msi

    Ich habe folgendes festgestellt:
    - Werden neue Clients gestartet (und auch wieder gewchlossen), so steigt die Größe des Serverprozesses (laut Taskmanager) an, zuerst stärker, danach schwächer aber mindestens um 4-8K.

    - Wird beim Client der "Lookup"-Button betätigt, so steigt nach jedem dritten oder vierten Mal die Prozessgröße (laut Taskmanager) um 8k.

    Handelt es sich dabei um Memoryleaks? Wenn ja was ist an dem Code fehlerhaft?

    Gruß



  • weiss keiner was??



  • Das müssen nicht zwangsläufig Speicherlecks sein. MS hat beschrieben, daß - wenn genug Hauptspeicher verfügbar ist - es in kleinen .NET Programmen sein kann, daß der GarbageCollector kein einziges Mal ausgeführt wird. Der Speicher, den das Programm holt, bleibt aber trotzdem belegt, weil sich darum ja .NET kümmert. Erst dann, wenn der Speicher langsam alle geht bzw. jemand mehr Speicher anfordert, als aktuell frei ist, versucht Windows den Speicher freizumachen. Dabei könnte dann auch .NET seinen zuviel belegten Speicher freigeben.

    Außerdem mußt Du berücksichtigen, daß bei .NET (und vielen anderen Programmen auch) .DLL's eine Rolle spielen. Wie deren Speicherverwaltung gestrickt ist, läßt sich auch schwer sagen, weil ja niemand sagt, daß eine DLL ihre Ressourcen sofort freigeben muß, wenn sich ein Prozess von ihr abdockt. Sie kann die Ressourcen ja für andere Anwender weiterverwenden! Die DLL selbst bleibt ja auch noch im Speicher stehen, wenn sie niemand mehr braucht und wird erst nach einer Weile entfernt. Das macht durchaus Sinn, weil es grundsätzlich wurscht ist, ob ich 700 MB freien Speicher habe oder 750 MB, wenn niemand 800 MB braucht.
    Wird die DLL wieder angefordert, ist sie sofort präsent und man spart wertvolle I/O Zeit von Platte! "Aus dem Speicher werfen" kann man sie ja immer noch, wenn die 800 MB gefordert werden.

    Worauf Du aber achten mußt: wenn Du selber Ressourcen anforderst, die nicht von .NET protokolliert werden (z.B. Zugriffe auf DB oder DLL-Aufrufe, die ihrerseits Ressourcen anforern), dann mußt Du Dich selber drum kümmern, daß diese Ressourcen wieder korrekt freigegeben werden! Hier mußt Du die Protokolle beachten (bzw. die Dokumentation bei den Methoden / Klassen).


Anmelden zum Antworten