Visual Studio Application 2005 - VM Increasing

eeimosn

Hi Folks

I have an application that has its Virtual Memory increasing all the time until finally after 2-3 days it produces an Out of memory exception. I have taken snapshots of the application running and also while it is just loaded but not running, in both cases the virtual memory is increasing gradually over time. The application is used in a production enviroment and I am wondering what is causing the OOM exception to occur? I also noticed that the HD gets very fragmented over time. I am trying to track down what is happening from the app but the snapshots appear to show nothing? Any ideas in how I might go about this would be really appreciated !!! Thanks.

StephenC

When you say that the application appears to show nothing are you having no increases in either the number or size of the .NET classes over time?

Perhaps it's a memory fragmentation issue:
http://www.simple-talk.com/dotnet/.net- ... ject-heap/

Stephen

eeimosn

That is my suspect aswell. Perhaps but when I monitor the large heap size I do not see it increasing either so I am at odds? Is there anything else that might tell me what is going on?

I used perfmon with teh counter for the 'large heap size' to monitor but I have not seen an increase over 2 hrs?

When I use the ANTS memory profiler and take two snap shots and look at the difference all I see no increase in classes etc like you say.

The evidence is that the VM memory increases at a rate of ~1MB/hr and that it generates an OutOf MemoryException Error.

StephenC wrote:

When you say that the application appears to show nothing are you having no increases in either the number or size of the .NET classes over time?

Perhaps it's a memory fragmentation issue:
http://www.simple-talk.com/dotnet/.net- ... ject-heap/

Stephen

StephenC

Hi,

The LOH counter isn’t very good, I think it only counts used memory.

You should look at the ‘free space in all .NET heaps’ in the profiler and compare it to the largest object that can be allocated: if the former is large but the latter is small then it’s fragmentation.

If not, then it’s unmanaged memory usage, which the profiler doesn’t deal with.

Stephen

eeimosn

Stephen

I used the session overview tab and looked at '#bytes in all heaps' and the 'largest object heap size'.

The '#bytes in all heaps' unused is >8MB while the 'large object heap size' unused is ~ 1MB. I am looking throiugh to see what is the largest object allocated is..unfortunately it is not me code..

Thanks for the feedback..

StephenC wrote:

Hi,

The LOH counter isn’t very good, I think it only counts used memory.

You should look at the ‘free space in all .NET heaps’ in the profiler and compare it to the largest object that can be allocated: if the former is large but the latter is small then it’s fragmentation.

If not, then it’s unmanaged memory usage, which the profiler doesn’t deal with.

Stephen

eeimosn

Yes it appears to be an unmanaged memory leak that is linked to the application, both the virtual bytes and privates bytes for the application are increasing over time but the total bytes in the heap is not.

eeimosn wrote:

Stephen

I used the session overview tab and looked at '#bytes in all heaps' and the 'largest object heap size'.

The '#bytes in all heaps' unused is >8MB while the 'large object heap size' unused is ~ 1MB. I am looking throiugh to see what is the largest object allocated is..unfortunately it is not me code..

Thanks for the feedback..

StephenC wrote:

Hi,

The LOH counter isn’t very good, I think it only counts used memory.

You should look at the ‘free space in all .NET heaps’ in the profiler and compare it to the largest object that can be allocated: if the former is large but the latter is small then it’s fragmentation.

If not, then it’s unmanaged memory usage, which the profiler doesn’t deal with.

Stephen