CLR Memory Utilisation

[Guest]

I have a problem with an C# application. The application is a 24x7 low volume message processing server. The server has a single thread of processing, running in a continuous loop, for each iteration thread sleeping for 5 seconds and than reading textual message files from a Windows Folder and applying them to a database.
From an external view, the server appears to have a memory-leek, continuously consuming RAM in a near linier fashion as it runs. I’ve observed the following
• Monitoring the application with perfmon or the windows task manager, the application continuously consumes additional memory at the rate of about half a gigabyte an hour.
• Viewed internally using GC.GetTotalMemory(true), memory consumption fluctuates between 400 and 800 KB and exhibits no trend of increasing memory utilisation.
• Fireing up another application under the .NET environment causes the near linier increase in memory utilisation to de-stabilise and occasionally drop dramatically. The most extreme observed drop was from 1.5GB to just under 1 megabyte
I have tried the application on Windows NT4, 2000 and XP running it under .NET without service packs and separately with service pack 1 and with service pack 2. In each case I’ve seen the same behaviour

Is this known CLR behaviour? Is there any way of restricting the amount of memory available to the CLR

Any thoughts or info would be greatly received. I have an angry client who want’s to move back to J2EE :

 

[Cor Ligthert]

Hi Jong,

Interesting, what happens when the thread awakes, are you creating "new"
objects while the method never ends?

Just a thought

Cor

 

[Willy Denoyette [MVP]]

What memory perf. counter shows the increased memory consumption?
If it's not a CLR memory counter, and I assume it's not, you probaly have a
non CLR memory leak.
Did you ever try to attach a debugger to the process?
What version of the framework do you run this on?
What OS and DB versions?

Willy.

 

[Guest]

Hi Cor, thanks for your response

My understanding was that the GC disposes the object automatically at it’s next opportunity once an object is de-referenced. An excerpt from my code is as follows

protected void LoaderLoop(

â€
while (true) // Forever! :

â€
bRet = CheckForNew(sLocation, xSourceConfig, xTargetConfig)
â€
Thread.Sleep(interval)
â€

â€


public bool CheckForNew(String sPath, XmlNode xSourceConfig, XmlNode xTargetConfig

XMLUtilities oUtil
â€
oUtil = new XMLUtilities()
â€
sPrefix = oUtil.GetXMLValue(xSourceConfig,"FILEPREFIX")
â€


LoaderLoop() Iterates forever sleeping and calling CheckForNew(). CheckForNew() declares variables for a number of objects upfront (oUtil for example in the excerpt) and is passed a number of objects by value. At the end of CheckForNew() despose is not manually called for any of the created objects. The method simply returns (or is aborted due to an exception). The assumption is that the objects created in the arguments (that are not passed by reference) and the objects explicitly created and referenced by local variables in the method body are automatically dereference because referring variable have gone out of scope on method exit leaving the dereferenced object to be garbage collected. My understanding is that there is no need in the code to explicitly call the c# depose equivalent to destructors (?)

Jo

 

[Cor Ligthert]

Hi Jong,

This is not the part where I say I am sure.

In my opinion does setting the reference to null nothing

When you construct your object in a routine (cannot get the name) and that
routine goes out of scope it should (when it has no any references any more
to another object) be destructed by the garbage collector.

However when it stay in scoop or there stays somehow a reference to another
not to dispose object it will not be disposed and you have to do it by hand.

This is just how I understand it until now.

Cor