Was wondering if anyone could shed some light on this.
I have an application which has a large memory footprint (& memory churn). There aren't any memory leaks and GCs tend to do a good job of freeing up resources.
Occasionally, however, a GC does not happen 'on time', causing an out of memory exception. I was wondering if anyone could shed any light on this?
I've used the REDGate profiler, which is very good - the application has a typical 'sawtooth' pattern - the OOMs happen at the top of the sawtooth. Unfortunately the profiler can't be used (AFAIK) to identify sources of memory churn.
Is it possible to set a memory 'soft limit', at which a GC should be forced? At the moment, a GC is only performed when the memory is at its absolute limit, resulting in OOMs.
It shouldn't really be possible for a Garbage Collection to 'not to happen in time'. They happen when a new memory allocation would push Gen-0 past a certain limit. Thus they always happen before a memory allocation would push the memory past its limit. This happens so many times a day throughout the world I would be surprised if any bugs weren't well known about.
Have you considered that you might actually be allocating more memory than is available? The OS only lets you access 2GB on most 32-bit machines.
There are some other possibilities:
- Is your application using un-managed memory?
- Is your application Pinning any memory? If so that could cause a fragmentation issue especially if you aren't releasing pin.
If you use a lot of memory and you garbage collect a lot I guess you should consider the "Flyweight" design pattern.
As an example, if you garbage collect a lot of strings, see String.Intern(string s). Msdn reference
You can use GC.collect() to force the garbage collector to do its work. But it is not preferable.
Use memory profiles like(memprofiler) to detect the leaks. Almost all your code performs leaks at some points.
来源：https://stackoverflow.com/questions/15923073/garbage-collection-runs-too-late-causes-outofmemory-exceptions