views:

243

answers:

6

I have a C# app which runs with priority RealTime. It was all fine until I made few hectic changes in past 2 days. Now it runs out of memory in few hours.

I am trying to find whether it is a memory leak I created of this is because I consume lot more objects than before and GC simply cant collect them because it runs with same priority.

My question is - what could happen to GC when it tries to collect objects in application with RealTime priority (there is also at least one thread running with Highest thread priority)?

(P.S. by realtime priority I mean Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.RealTime)

Sorry forgot to tell. GC is in Server mode

+2  A: 

Most probably GC can't collect them because somewhere you still hold a reference. Try to profile your application with a memory profiler (RedGate has a good one, you should try the trial version) to find why GC won't collect your objects.

Sebastian P.R. Gingter
are you sure the priority is not the problem? I used RedGate before I agree its good. But it might take some time.
Bobb
+1  A: 

I really doubt the real time priority is the cause of your issue. My guess is that in the couple of changes you mentioned you leak memory somewhere (which in C# usually means keeping references to objects that are not needed anymore). You can either use a memory profiler, use WinDbg with SOS (see e.g. http://msdn.microsoft.com/en-us/magazine/cc163528.aspx) or just take a look at these changes and try to eyeball the issue.

Grzenio
+10  A: 

The GC runs in your process and hence has the same priority. It's ability to collect isn't impacted by the PriorityClass with which your application runs.

This memory leak is almost certainly caused by you holding onto the root of a growing object graph which prevents the GC from collecting it.

JaredPar
yes thank you. I just realised that it was stupid question as usual :) of course how GC threads can be outside the app domain and run with different priority :)Crazy :)
Bobb
A: 

Garbage Collection Threads differently based on what type of system you have configured it to run on. On a simple work station, each individual thread will host the Garbage Collection, but only one can host at a time. If its configured to run on a server, a separate thread will host the Garbage Collection.

http://msdn.microsoft.com/en-us/library/ee787088.aspx#generations

But perhaps your objects are staying around too long and getting to the Long-Life generation, and garbage collection is not looking at them as often as you would like.

Or perhaps you have some other issue.

Meiscooldude
> On a simple work station, each individual thread will host the Garbage Collection [...]Your summary of the link is not accurate. GC may run on _any_ single user thread, but only on one each time; on server garbage collection, multiple separate threads are run.
Blaisorblade
+1  A: 

I would seriously not recommending running any program as RealTime priority. Basically, anything that runs at RealTime priority runs at a higher priority than the GUI, or even the Windows Task Manager... and thus can lock out the user themselves.

Raymond Chen talked about this last week.

In particular, since not even input runs at real-time priority, you can't stop it via any interactive means, because the thread that manages input can't even run to process your input.

R. Bemrose
There's a useful warning in that article's comments, too: If you insist on making your application run in real time priority, you should have the application detect when it loses focus and, in that situation, drop its priority. Otherwise, the user may have difficulty returning focus to the application, and thus will be forced to reboot their machine or wait until the application stops using the CPU (which may never occur).
Brian
this is purely server application and is supposed to be soft-realtime.
Bobb
A: 

Instead of changing the thread priority and possibly locking your system, you should use a memory profiler to identify the real cause of the problem. You can also use Performance Monitor to check the performance counters in the .NET CLR Memory category to see how much memory is allocated, how much survives garbage collection etc.

Panagiotis Kanavos
yeah, I identified it. The 3d party API grows in size ;)
Bobb