We programmed an application which is a number crunching simulation that needs to run for 24 hrs non-stop.
It uses painting event in windows form to render visual representation of the subject continuous, plus we are using several realtime graphs and grids to show the progress of the project objects. It is a .NET windows form application.
After 4 hrs we get System outOfMemory Exception.
Memory Profiler shows us that if we tradeoff some realtime graphs and some other undisposed objects, we can save ‘some'(35%-40%) memory.
My concern is it’ll still not run for 24hrs non-stop. We already have 4GB RAM on our HP 8440p Elitebook Intel i5 with 32-Bit Win7 installed.
Our objective is to have maximum possible memory provision for our simulation application and for the .NET CLR on which it’s running.
Will investing in more memory (perhaps 8GB) and 64-bit OS help? What other possible CLR options do I need to consider besides adding more hardware?
Thanks a lot.
@Adam Houldsworth’s suggestion is a very good one. You might be facing a memory leak (references to stale objects are still being kept, very frequently by a live event subscription as Adam suggested, this prevents them from being garbage-collected).
@mkimes answer is also very valuable. Indeed, running as a 64-bit process will allow your application to manage much more memory, but still, there are some caveats (like the 2GB limit of a single object’s size).
If you intuitively feel that the application should not be running out of memory because, in your reasoning, most created objects are short-lived and should have been disposed, then you probably are facing a memory leak. However, if the process is building up a large amount of objects that should be kept alive after the process is finished or during a lengthy phase of computation, then you might be hitting the 32-bit memory limit barrier, especially considering that during a full garbage collection cycle, the application’s memory will tend to temporarily grow near twice the current allocated size, keeping the practical 32-bit memory-size limit around 1GB.
There is a Windows configuration switch that allows increasing the memory size a 32 bit application can handle to 3GB, however in my experience this made the operating system unstable (very frequent blue screens), so explore this option with care.
If you suspect a memory leak:
This article might help, it shows you how to use Windgb (an advanced debugger) to trace the objects that might be keeping unwanted, stale references alive.
Also (hope not), you might be victim of a very nasty problem that is memory fragmentation that can be induced by repeated, frequent allocations of what the CLR considers “large objects”, that is, objects larger than 85,000 bytes in size. Here is an article detailing the problem. Basically, such objects are allocated under a different heap that is disposed, but unfortunately, never compacted. This means that freed memory blocks will be interspersed with allocated blocks and the runtime might not find, at some point, a single contiguous block of memory to fulfill a memory request, triggering an out-of-memory exception. If this is the case, breaking up a large, monolithic object into smaller objects will help.
Finally, no object can be larger than 2GB in size even under 64-bits, so you must be aware your collections and/or arrays are not reaching this limit.