Visual Studio Application 2005 - VM Increasing

Memory profiling for .NET developers

Moderators: StephenC, Alex.Davies, AndrewH, melvyn.harbour

Visual Studio Application 2005 - VM Increasing

Postby eeimosn » Wed Oct 07, 2009 11:08 am

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.
eeimosn
 
Posts: 4
Joined: Wed Oct 07, 2009 10:55 am

Postby StephenC » Wed Oct 07, 2009 7:49 pm

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
 
Posts: 306
Joined: Mon Oct 15, 2007 9:18 am
Location: Cambridge

Re:

Postby eeimosn » Thu Oct 08, 2009 2:11 pm

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
eeimosn
 
Posts: 4
Joined: Wed Oct 07, 2009 10:55 am

Postby StephenC » Thu Oct 08, 2009 4:25 pm

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
StephenC
 
Posts: 306
Joined: Mon Oct 15, 2007 9:18 am
Location: Cambridge

Re:

Postby eeimosn » Fri Oct 09, 2009 9:24 am

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
 
Posts: 4
Joined: Wed Oct 07, 2009 10:55 am

Re:

Postby eeimosn » Mon Oct 12, 2009 11:02 am

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
eeimosn
 
Posts: 4
Joined: Wed Oct 07, 2009 10:55 am


Return to ANTS Memory Profiler Previous Versions

Who is online

Users browsing this forum: No registered users and 0 guests