<p>My huge 32-bit web services LLBLGen-based data access application is running alone on a dedicated 64-bit machine. Its physical memory consumption steadily grows up to approximately 2GB when the process releases almost all of the allocated space (up to 1,5GB) and continues to grow from that point again. There is no observable increase in Page Input values or other page file usage parameters so it looks like the memory is released rather than being swapped out to page file. I am thinking what kind of profile is this? There is nothing to actually prevent the process from grabbing all memory it can, on the other hand there are unacceptable http internal errors around the memory release - probably the clean-up blocks useful work. What would be a good strategy to make the cleanup less obtrusive, given the above is an acceptable behaviour in the first place.</p>

The Garbage Collector doesn't automatically free memory when it releases objects, it holds on to that memory to help minimise the expense of future mallocs.
When a low memory condition is triggered that memory will be returned to the OS and you will see more available memory when looking through task manager.  This will normally happen about the 2GB mark, or 3GB if you use the
relevant switch
.
```
<contentious>
```
By setting objects to null when they are dead you can encourage the GC to reuse the memory consumed by those objects, this limiting the growing consumption of memory.
But which objects should you set to null?  Big objects, large collections, frequently created objects.
```
</contentious>
```
EDIT
: There is evidence to support the value of setting objects to null.  See
this
for detail.  Of course there is no
need
to set objects to null, the point is does it help memory management in any way?
EDIT
: We need a recent benchmark if such a thing exists rather than continuing to opine.