Our IIS 6.0 application pools take up on first load of a page 155Mb of memory. On subsequent refreshing of the same page the App pool memory consumed goes up to approx 245Mb.
Its a webforms application and uses Entity Framework and DevExpress controls.
At first I thought this was a memory leak, but on further investigation using a memory profiler found that over half the space being taken up by the app pool was free space but fragmented.
This pointed the finger towards Large Object Heap memory fragmentation as the culprit. There was indeed a long list of approx 980Kb which typically can cause fragmentation especially when the list grows and resizes leaving behind holes in memory.
So I've created a composite list, basically a list of lists, the idea being that as each list would be under 85000 bytes, it would be allocated in the normal heap which gets compacted after garbage collection (unlike the Large Object Heap, which never gets compacted)
Had expected the composite list to do the trick as read elsewhere that others have used lists of lists to ensure objects escape the Large Object Heap, however it doesn't appear to have made any real difference in this case, and the App pool memory is still around 240Mb whereas memory profilers report the dot net CLR memory at around 10Mb.
Am planning on doing a memory dump to see whats going on, but just wondered if anyone else had a view on what might be possible causes.