CLR Memory Utilisation

[jong]

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

[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.

"jo**@opentext.com" <an*******@discussions.microsoft.com> wrote in message
news:0F**********************************@microsof t.com...

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 :(

[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.

"jo**@opentext.com" <an*******@discussions.microsoft.com> wrote in message
news:0F**********************************@microsof t.com...

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 :(

[jong]

Yes Cor

I'm creating new objects within methods called by my infinite loop. However, these objects are transitory and are de-referenced immediately after use (before the completion of a sleep / processing cycle).

Thanks for the thought.

Cheers
Jg.

[jong]

Hi Will

I was using Process/Virtual Bytes focused on my .Net application process. I originally had a view that I had a memory-leak issue however I found that fireing up another application under the .NET environment causes the near linier increase in memory utilisation to de-stabilise and occasionally drop dramatically. This only occurred when running another .Net application which lead me to believe that the memory utilization was not directly due to my application. My assumption/guess currently is that, in some situations, the CLR can be lazy in returning memory to the O/S and when a competing .Net application is fired up that needs this memory it simply passes the free memory over to the competing application
I have tried the application on multiple O/S installs - Windows NT4 SP6, 2000 SP4 and XP. If have also run it under .NET 1.0 and separately with service packs 1 and 2. In each case I’ve seen the same behavior
All very odd

The memory utilization would not be a problem if I could cap the amount of memory available to the CLR (like you can limit the amount of heap space available to a Java VM). Are you or any one else aware of any way of achieving this

Thank

Jg
----- Willy Denoyette [MVP] wrote: ----

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

"jo**@opentext.com" <an*******@discussions.microsoft.com> wrote in message
news:0F**********************************@microsof t.com..

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,

I think that setting them to nothing does nothing for your memory.
In this case you have to dispose them in my opinion

What are you doing?

Cor

[jong]

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

[jong]

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

[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