2012-12-11 4 views
8

Ich habe eine WCF-Anwendung in IIS gehostet (geschrieben in C#/.Net 4). Mit der Zeit nimmt die Anzahl der Handle des Prozesses mehr oder weniger linear zu (bis zu 30.000, bevor der Prozess recycelt wird). Nach SysInternals Process Explorer ist der Großteil der Handles, die der Prozess hat, vom Typ Thread. Laut Systemmonitor bleibt die Anzahl der Threads jedoch mehr oder weniger konstant (etwa 40)."Leaking" Thread Handles

Klar mache ich etwas falsch und lecke Thread Handles. Allerdings ist mir unklar, was genau ein Thread Handle in diesem Zusammenhang ist. Ich hätte angenommen, dass es ein Handle zu einem Thread ist, aber da die Anzahl der Threads konsistent bleibt, sehe ich nicht, wie die Anzahl der Handle immer zunimmt. Und ich kann mir keinen Weg vorstellen, um einen Thread im Griff zu behalten, während der Thread selbst verschwindet. Außerdem erstelle ich nicht explizit neue Threads (ich verwende den ThreadPool an Orten).

Offensichtlich fehlt mir etwas. Aber was?

+0

Haben Sie den WCF-Dienst als SingleInstance, PerCall oder Session? Verwenden Sie dort einen IoC-Container? – Jordi

+0

Verwalten Sie die Threads selbst oder verwenden Sie den Thread-Pool? Welche Art von Threads verwenden Ihre Anwendung (reden wir über die Threads, die IIS ausführt -> begrenzt durch den IIS selbst oder Ihre eigenen Threads)? – Rafa

+0

Der WCF-Dienst ist Einzelinstanz und mehrere Nebenläufigkeit. Kein IOC-Behälter. –

Antwort

0

According documentation:

Wenn ein neuer Faden vom CreateThread oder CreateRemoteThread Funktion erstellt wird, wird ein Handgriff auf den Faden zurückgeführt.

Also wenn Sie so viele Griffe haben, produziert Ihre Anwendung die neuen Threads ständig. Auf der anderen Seite besagt die nahezu konstante Anzahl von Threads im Systemmonitor, dass Threads anstelle von recycelten Threads erstellt werden.

ThreadPool Klasse Dokumentation:

Beginnend mit dem .NET Framework 4, der Thread-Pool schafft und Arbeiter zerstört Fäden, um den Durchsatz zu optimieren, die als die Anzahl von Aufgaben definiert ist, dass eine vollständige pro Einheit von Zeit. Zu wenige Threads können die verfügbaren Ressourcen möglicherweise nicht optimal nutzen, während zu viele Threads die Ressourcenkonkurrenz erhöhen könnten.

Also ich denke, Ihr Anwendungsverhalten ist wegen der ThreadPool.

+0

@Brian Rasmussen Danke – VMAtm

1

Man kann Griffe zu terminierten Threads haben. So werden die Threads erstellt, terminiert, aber der Griff bleibt.

Starten Sie den Prozessmonitor (procmon.exe) und stellen Sie ihn so ein, dass er auf "Prozess- und Threadaktivität" hört (Dateien, Registrierung und Netzwerk deaktivieren). Ermitteln Sie, wer Threads erstellt, indem Sie auf Thread-Create-Ereignisse doppelklicken und den Stack betrachten.

Das sollte die Frage beantworten, wer die Threads erstellt. Er ist verantwortlich für das Schließen der Griffe.