Search code examples
c#.netmemory-managementowinprocess-explorer

Is it conceivable that the Virtual Size reported by Process Explorer could cause OutOfMemory exceptions?


I am working to diagnose a series of OutOfMemoryException problems within an application of ours. This is an internal 32-bit (x86) OWIN-hosted WebAPI that runs within a console application and talks to a series of hardware components in parallel. For that reason it's creating around 20 instances of a library, and the sharp increase in "virtual size" memory matches when those instances are created.

process explorer image

From the output of Process Explorer, and dotMemory, it does not appear that we're allocating that much actual memory within this application:

dotMemory screenshot

From reading many, many SO answers I think I understand that our problem is either from fragmentation within the G0, G1, G2 & LOH heaps, or we're possibly bumping into the 2GB addressable memory limit for a 32-bit process running on Windows 7. This application works in batches where it collects a bunch of data from hardware devices, creates collections in memory to aggregate that data into a single object, and then saves it to be retrieved by a client app. This activity is the cause of the spikes in the dotMemory visual, but these data structures are not enormous, which I think the dotMemory chart shows.

Looking at the heaps has shown they rarely grow beyond 10-15MB in size, and I don't see much evidence that the LOH is growing too large or being severely fragmented. I'm really struggling with how to proceed to better understand what's happening here.

So my question is two-fold:

  1. Is it conceivable that we could be hitting that 2GB limit for virtual memory, and that's a cause for these memory exceptions?

  2. If that is a possible cause then am I right in thinking a 64-bit build would get around that?

We are exploring moving to a 64-bit build, but that would require updating some low-level libraries we use to also be 64-bit. It's certainly an option we will explore eventually (if not sooner), but we're trying to understand this situation better before investing the time required.

Update after setting the LARGEADDRESSFLAG

Based a recommendation I set that flag on the binary and interestingly saw the virtual size jump immediately to nearly 3GB. I don't know if I should be alarmed by that?!

memory use with LARGEADDRESSFLAG set on the exe

I will monitor the application with this configuration for the next several hours.


Solution

  • In my case the advice provided by @ThomasWeller was indeed correct and enabling the "large address aware" flag has allowed this application to run for several days without throwing memory exceptions.