Memory leaks that build up over long periods of time on production servers can be difficult to diagnose with memory profiler. The memory profiler will introduce even more memory usage, and in a 5GB process, I'd say this is stretching the limit of practicality for a memory profiling tool.
Unfortunately, Memory Profiler cannot analyze a dump file -- I think we do have this on the wish list for a version down the road if at all practical.
Windbg and sos.dll can provide a lot of the raw stats about objects on the managed heap, so that give you some idea where to look. When SOS is loaded, you can use these commands:
counts objects by their type
lists the objects currently on the stack
!gcroot <obj address>
will show what objects are holding a reference to <obj...
has lots of practical examples of debugging memory leaks in ASP .NET.
Once you get a feel about what objects could be leaking, you can then run some smaller tests with the Memory Profiler to get a better picture of where the references are.