Wir haben ein Speicherleck! (oder doch nicht?) Konkreter Fall: Der Kunde meldet sich und beschwert sich über den exorbitanten Speicherverbrauch der Anwendung. Beigelegt hat er einen Screenshot vom Task Manager.

Was wird eigentlich im Task Manager angezeigt?

Der Task Manager zeigt die sog. "Working size" des Prozesses an. Dies bezeichnet den derzeit real (physikalisch) allokierten Speicher der Anwendung. Dieser "Speicherverbrauch" ist aber aus folgenden Gründen irreführend und sollte nicht (oder nur als grober Anhaltspunkt) für die Performance der Anwendung herangezogen werden:

• Der Speicher wird von Windows gemäß der Priorisierung allokiert. Minimiert man die Anwendung, kann man sofort sehen wie der Speicherverbrauch zurückgeht.
• .NET Anwendungen laufen in einer sog. "Sandbox", der .NET Runtime Umgebung. Diese ist auch in der angegebenen Speichermenge enthalten. Die eigentliche Anwendung macht also nur einen Teil dieses Speicherverbrauchs aus.
• Laufen mehrere .NET Anwendungen gleichzeitig, können diese Teile der .NET Runtime Umgebung gemeinsam nutzen.

Ein besserer Anhaltspunkt für den Speicherverbrauch sind die sog. "private bytes". Dies bezeichnet die Menge an Speicher, die von der Anwendung nicht mit anderen Anwendungen geteilt werden kann. Der Task Manager kann diese jedoch nicht anzeigen. (Das gelingt jedoch mit dem ProcessExplorer oder perfmon (Start -> Ausführen -> Perfmon). Diese Zahl ist jedoch auch mit Vorsicht zu genießen: Sie bezeichnet sowohl aktiven als auch ausgelagerten (paged) Speicher, d.h. Hauptspeicheranteile, die aufgrund von Inaktivität auf die Festplatte ausgelagert wurden. Steigen die "private bytes" im Laufe der Zeit immer weiter an, ist ein Speicherleck vorhanden. Dies muß jedoch über einen langen Zeitraum beobachtet werden, da die Speicherverwaltung von der .NET Runtime durchgeführt wird und es teilweise recht lange dauert, bis Objekte wieder freigegeben werden (besonders wenn sie ausgelagert sind).