NancyG

VS2010 Pro, Net 4.0 Bin eben bei 80k offenen Handles, 60Mb. (1h) Und der GC tut nix 20% CPU!?

IDisposable ist überall drin. Ich setze sogar skalare Variable auf Nothing. Welchen Vor/Nachteil hat vsHostProzess?

Und auch laufen lassen. Nein, natürlich nicht! Denn sonst hättest du gesehen, dass dein Speicher von ca. 13000Kb innerhalb von einer Minute auf 18000kb anwächst - siehe Bild. Im Bild ist grün eingekreist die offenen Handles - die eben nicht mehr geschlossen werden..... Und wenn ich das den ganzen Tag mache - sehe ich sehr wohl, dass der Speicher zur Neige geht. Sub Main() Dim i As UInt32 = 1 While True Dim t As New Threading.Thread(AddressOf doSomething) t.Start() Threading.Thread.Sleep(50) Console.WriteLine("{0}", i) i += 1 End While End Sub Private Sub doSomething() Threading.Thread.Sleep(100) End Sub Und zumindest ist es bei mir so - und wenn du an dem Code nichts falsches siehst - dann bleibt für mich nur die Erkenntnis: Bei jedem Thread geht Speicher verloren. Wo und wie weiss ich nicht - deswgen farge ich ja hier.

Wieso soll es nicht stimmen. Ich habe die Aussage an Hand von einer Test-App nachvollzogen. Du unterstellst hier einfach Sachen - ohne wahrscheinlich selber den Test gemacht zu haben. Deine Aussage: "Der Speicher wird beim Beenden der App freigegeben", stimmt zwar - aber bringt mir nichts. Und: Was das Programm sonst noch so macht: Genau das, was es soll! Ohne die Threads zu erzeugen - wird kein Speicher verbraten. Aller 250ms bekomme ich ein Callback mit den Daten, die ich dann eben nicht verarbeite. Ja: ich habe auch schon die Threads erstellt, ohne die Daten zu verarbeiten. Selbiges Problem. Sorry, aber ich habe die Frage ja nicht aus langer Weile gestellt, ob jemanden das Phänomen bekannt ist: Das durch erstellen von Threads Speicher verloren geht. vG Nancy

Das *richtige* Programm. Was erhoffst du dir davon, wenn ich beide parallel laufen lasse? vG Nancy

Bei 1,8GB RAM hat sich das Programm (ohne DEV-Umgebung) mit der Fehlermeldung "APPCRASH" verabschiedet. Lief bis vorgestern. Ich werde es nochmal im Debugger laufen lassen.

Das Erstellen des Threads selbst verursacht das Speicher-Leck. Mutex! Das Verbindungsobjekt, bzw der Stream ist immer offen und wird nur im Thread beschrieben. Mutex WaitOne/ReleaseMutex verhindern dass eben 2 Threads gleichzeitig drauf schreiben. Wie ich oben aber schon sagte - das Problem ist nicht die Geschwindigkeit, die Daten wegzuschreiben. Sondern, dass eben jeder neu erstellte Thread Speicher verbraucht und diesen nicht wieder frei gibt. vG Nancy

Ich möchte auch was sehen, wenn ich es im VS-Debugger laufen habe. Sonst soll eben aller 50ms ein Thread erstellt werden.. und im Thread eben aller 100ms i iteriert werden. Das ist ein Test - um das verhalten nach zuschauen. Hat nichts mit der eigentlichen Anwendung zu tun. Sorry, wenn das eben nicht so herüber kam. vG Nancy

Das Problem ist doch nicht die Leistung, sondern die Ressource (Speicher). Die 3 Threads werden schon in den 250ms abgearbeitet. Es ist sehr selten, dass mal eine Queue von 1 (aber nie höher) entsteht (Mutex WaitOne/ReleaseMutex). Ich habe es mit ThreadPoll versucht - und es bleibt das selbe Phänomen. Es starten x Threads, Handels werden erstellt, Speicher wird alloziert. Nach beenden der Threads bleiben die Handles einfach offen - und damit auch der Speicher belegt. Private Sub th() Dim i As Int32 = 0 While i < 100 i += 1 Threading.Thread.Sleep(100) End While End Sub Private Sub StartTH_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles StartTH.Click For i As Int32 = 0 To 20 Step 1 Threading.ThreadPool.QueueUserWorkItem(New Threading.WaitCallback(AddressOf th)) Threading.Thread.Sleep(50) Next End Sub Kann ich - und habe ich auch gemacht. Nur leider bringt mich das eben nicht weiter. (s.o.)

Ok, kannst du mir ein kleines Beispiel dafür geben, wie es aussehen könnte? vG Nancy

Eben nicht, weil die weitere Verarbeitung der Variablen eben nicht nur so aussieht: Variablen werden in der Anwendung aktualisiert: Sondern - aller 250ms die aktuellen Variablen zBsp.: - über TCP/IP wo anders hin sollen - in ein Textfile geschrieben werden - in eine Datenbank geschrieben werden - usw. Und für jede Aktion: TCP/IP, Textfile, DB wird ein eigener Thread erzeugt. Aber das steht auch nicht zur Debatte: Fakt - nach jedem Thread der erstellt wurde, wird der Speicher nicht freigegeben. Es geht hier also nicht um die Frage: Ob das Design der AW richtig/falsch ist! Die Frage lautet, warum wird der Speicher nicht freigegeben. Und es hat auch nichts mit Echtzeit zu tun (Definition Echtzeit lesen.)! Bitte Leute!: Nehmt doch Bezug auf die Fragestellung - und sagt mir nicht, dass ich es mit C++ machen soll (was ich persönlich sowieso möchte). Oder: Dass sich um den Speicher der GC kümmert, denn dies tut er nicht. Ich habe es auch ohne die GC-Aufrufe probiert. Es bleiben Handles offen - und demzufolge auch Speicher hängen - und das bei jedem Threadaufruf! vG Nancy

@Klotzkopp Es ist kein Designfehler: Schon mal von WinCC/ODK gehört? Es werden aller 250ms Tags (Variablen) in meiner Anwendung aktualisiert. @lbm1305 Weil es nichts bringt? vG Nancy ps. Probiert es doch selber aus. C: Thread erstellen -> beenden -> Handles schliessen -> Speicher ist wieder frei! .Net:Thread erstellen -> beenden -> Handles bleiben offen -> Speicher ist nicht wieder frei! -Und der GC räumt den Dreck auch nicht weg. @lbm1305 Dein "Gefällt mir": Wofür?

Ok, mal abgesehen davon, dass GC aufgerufen wird - soll an dem Code alles richtig sein! Das nehme ich erst einmal so hin. Aber!: Ich habe nach jedem Aufruf, der einen Thread erzeugt, Handles - die nicht geschlossen werden und auch Speicher, der nicht mehr freigegeben wird. Und das ist nicht richtig! @Guybrush Threepwood Auch wenn du mir jetzt wieder mit: Der GC kümmert sich darum, kommst. Es ist nicht normal - und er kümmert sich auch nicht darum. Fakt: In meiner Anwendung wird aller 250ms ein Thread erzeugt. Mittlerweile habe ich eine EXE im Taskmgr, die >1GB RAM belegt (virt: >1GB, phys: < 300MB) und der GC tut gar nichts. Ich werde das Programm so lange laufen lassen, bis der Speicher alle ist - und ich vermute, dass der GC nichts wegräumt - und es zu einer OutOfMemoryException kommt. vG Nancy

Hallo, danke für die Antworten. Ich habe jetzt weiter getestet. Aber es funktioniert auch nicht, wenn ich den Thread normal beenden lasse (über Flag). Die geöffneten Handles bleiben offen. Demzufolge wird auch der Speicher nicht freigegeben. Ich habe das ganze nochmal unter c++ getestet, dort wird der Thread beendet - und der Speicher ist wieder FREI. CloseHandle( CreateThread(....)); //handle gleich schliessen Aber wie kann man im .Net die Handles wieder schließen? Bei der Testanwendung sind nach dem Starten 104 Handles offen. Wird der Thread gestartet - sind es 109. Nach dem Beenden des Threads gehen die Handles nach Ewigkeiten wieder runter - auf 108! Was aber nicht die Ausgangssituation war. Es müssten doch wieder 104 werden. Wie oben schon geschrieben. Das ganze im C++ - macht genau - was man erwartet. Was muss ich an dem Code noch verändern, um das gewünschte Ergebnis zu erzielen - den Speicher wieder frei zu bekommen. vG Nancy

Hallo Leute, ich habe eine Anwendung die immer laufen soll! Nun ist es aber so, dass dort der Speicher *gefressen* wird. Also habe ich ich mal eine kleine Testanwendung geschrieben - und das Szenario vereinfacht nachgestellt. Es wird auf Kommando ein Thread gestartet - und auf Kommando auch wieder gestoppt (gelöscht). Leider wird bei diesem Vorgang der Speicher nicht wieder vollends freigegeben. Konsolenanwendung: Dim thTest As Threading.Thread Dim lineRead As String Sub Main() Do lineRead = Console.ReadLine() If Not commandParse(lineRead) Then Console.WriteLine("command not found: " & lineRead) End If If lineRead = "exit" Then Exit Do GC.Collect() GC.WaitForPendingFinalizers() GC.Collect() GC.WaitForPendingFinalizers() Loop End Sub Function commandParse(ByVal input As String) As Boolean Select Case input Case "exit" dis() Case "dmexit" dis() Case "dmcon" con() Case Else Return False End Select Return True End Function Sub myThread() While thTest.IsAlive Threading.Thread.Sleep(10) End While End Sub Sub con() If thTest Is Nothing Then thTest = New Threading.Thread(AddressOf myThread) thTest.Start() End If End Sub Sub dis() If Not thTest Is Nothing Then thTest.Abort() thTest = Nothing End If End Sub Ich habe mir das Tool .Net Memory Profiler installiert und mal geschaut, wo es denn klemmt. Was ich festgestellt habe, dass im .Net der Speicher wieder frei wird, nur der vMem und der heapMem vom System nicht mehr. Vorm Starten: Beim laufenden Thread: Nach beenden des Threads: Wo liegt das Problem - und wie kann ich es lösen? vG Nancy