I have a MRP application written in .NET 3.5 running on a Windows 2008 Terminal Server. Server is a HP DL380 with 14GB RAM to support up to 40 users, however at present I only have around 10 users using the server for this application.
I have noted that the application consumes at minimum 100MB per user in memory and upto 800MB in some instances, also the memory usage of the EXE rises slowly at about 12K per second even when the user idles their usage and does not work on their session.
The application is written as a bespoke for the company by a third party and I am having to handle the complaints from users of slow sessions and the application hanging mid session. I use Remote App for the application so of course the helpdesk has to close the session for the user and this is increasing their frustration.
I think this application is either leaking memory or consuming more than it should per user, Outlook.exe for example uses around 100MB per session which is about right for that Microsoft app and is considered memory intensive, 800MB for an EXE is just to high I feel.
I want to push this back to the developers, have others seen .NET applications do this or have experience where they know a bespoke application causes this type of issue?
cheers
Kyle
As anything else, there could be a million different reasons for this, but my first suspicion would be that something in the way the application was written is causing issues with .NET's built-in Garbage collection routines. There are several different PerfMon counters that can be used to monitor time in GC as well as how many Gen 0,1,2 collections are occuring. I've seen in many different .NET apps that depending on how things were defined in an constructor that certain variables are not allowed to be garbage collected properly and in some cases these items are defined as static in the constructor which can cause multiple instances of the variables that are not able to be GC'd. At the end of the day, the best way to find the root cause is to use an .NET profiling tool to help find the root cause of these situations, but that would most likely need to be done by the developers of the app for full stack traces with real names of the objects/functions. BTW, if you want to do research on this on the internet, you'll find a plethora of articles discussing GC issues with .NET, so you're not alone in this. And technically it's not a .NET problem either as Java and other interpreters can too have similar GC issues if it's coded poorly.
Shawn
http://www.shawnbass.com
Attend my "Unofficial" 5-day Citrix Master Class. http://www.shawnbass.com/training.aspx
Almost forgot. The PerfMon counters you'll want to investigate are located under the .NET CLR Memory performance object.
I agree with Shawn, Garbage collection was the first thing that popped in to my head. You can also monitor the counters Sawn mentioned with Process Explorer. Look for processes highlighted in Yellow to quickly identify .NET apps. From there go to properties and look at the .NET tab, you'll see the .NET CLR Memory in the drop down.
Also, one thing you might be able to do is invite them to do a live debug of one of the users sessions. You can install the remote debugging utils(actually no install, just copy them over) and have them connect to a debug instance from their VPN/Lan/whatever connection. Then they can see the problem in action.
Developers typically have to see it to believe it if you know what I mean.
Hope this helps,
--Mike