| Author |
Message |
eeimosn
Joined: 07 Oct 2009 Posts: 4
|
Posted: Wed Oct 07, 2009 11:08 am Post subject: Visual Studio Application 2005 - VM Increasing |
|
|
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. |
|
| Back to top |
|
 |
StephenC
Joined: 15 Oct 2007 Posts: 314 Location: Cambridge
|
|
| Back to top |
|
 |
eeimosn
Joined: 07 Oct 2009 Posts: 4
|
Posted: Thu Oct 08, 2009 2:11 pm Post subject: Re: |
|
|
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.
|
|
| Back to top |
|
 |
StephenC
Joined: 15 Oct 2007 Posts: 314 Location: Cambridge
|
Posted: Thu Oct 08, 2009 4:25 pm Post subject: |
|
|
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 |
|
| Back to top |
|
 |
eeimosn
Joined: 07 Oct 2009 Posts: 4
|
Posted: Fri Oct 09, 2009 9:24 am Post subject: Re: |
|
|
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 |
|
|
| Back to top |
|
 |
eeimosn
Joined: 07 Oct 2009 Posts: 4
|
Posted: Mon Oct 12, 2009 11:02 am Post subject: Re: |
|
|
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 |
|
|
|
| Back to top |
|
 |
|