I Am a Happy Janitor – Part 1: Finding garbage

re: I Am a Happy Janitor – Part 1: Finding garbage

Anil — Fri, 13 Jan 2012 05:25:42 GMT

Hi,

We have an enterprise level system that is currently build on .NET2.0. Lately we shifted the target to .NET 4.0. The system is primarily a desktop system. After shifting the target to .NET 4.0 we have found that the average memory consumed per client has increased substantially, esp. in the CITRIX environment. Yes, the way GC works has been modified in .NET 4.0, but could this be the cause of the higher memory consumed.

Troubleshooting System.OutOfMemoryExceptions in ASP.NET

Useful IIS/ASP.NET Information provided by Microsoft Support Teams — Mon, 01 Jun 2009 18:28:29 GMT

Some common causes of OutOfMemoryExceptions in ASP.NET applications and information on how to resolve these exceptions.

re: I Am a Happy Janitor – Part 1: Finding garbage

Mike Waldrop — Thu, 01 Jan 2009 08:33:44 GMT

I thought I had a pretty good handle on the GC until I started using the DumpGen command in SOSEX. In my testing I found that during a GC, the memory in Gen 0 was not being freed. Or at least that is how it appears.

I was purposely doing a GC.Collect to see what got left over in trying to see what had some objects locked.

What I found interesting is this. Many instances of aspx pages and other objects still existed in Gen 0 after I did a collect. BUT here is the weird part.

First I did a GC.Collect then ran the below commands expecting the same result. I was always told after a GC gen 0 is practically 0.

This command: !dumpheap -type ASP.MyPage (or any obect)

showed collection working as expected. But then I used the SOSEX command of

!dumpgen 0 -type ASP.MyPage

and there were tons of instances consuming memory. Even after doing a collection. Perhaps I'm thinking of it wrong. I thought when a gen0 happens object moved to gen1 if needed, object that can be collected are and then compaction. And the pointer to gen0 reset.

I assumed the blocks that are removed are actually emptied But maybe this is where I am confused. If the pointer is moved then maybe those blocks are just overriden and the SOSEX tool however it works is just finding these?

Seems strange though. When I create dumps they are in the 200 meg range but yet the eeheap -gc tells me that it's only a few megs. And the total bytes in heaps counter jives more with the 200 megs.

So is the memory in gen 0 actually freed? Or is the SOSEX tool just showing me incorrect data.

Oh and Happy New Year, as I see it's 12:15 am.

if you could email me that would be great. jedi1_9_7_3@yahoo.com

re: I Am a Happy Janitor – Part 1: Finding garbage

Maoni Stephens — Wed, 15 Oct 2008 02:15:05 GMT

Gourav, so what does CLRProfiler about what contributes to the growth of the heap?

re: I Am a Happy Janitor – Part 1: Finding garbage

Gourav — Wed, 18 Jun 2008 14:59:49 GMT

Maoni,

I really appreciate this Weblog. Thanks A lot !!

I have one windows service which use System.Timers.Timer to Create Process in interval of 5 sec on each elapse Event memory is increasing by 4 KB, I used CLRProfiler and found heap is growing like any thing.

Please help me to solve this problem ?

re: I Am a Happy Janitor – Part 1: Finding garbage

Maoni Stephens — Sat, 30 Sep 2006 09:46:47 GMT

Raghu, I can not comment on this since legally we (as in product groups) are not allowed to run benchmarks on our competitor products.

re: I Am a Happy Janitor – Part 1: Finding garbage

Raghu — Sat, 30 Sep 2006 05:16:48 GMT

Hi,

Do you have any plans to benchmark .net framework 2.0 with BEA WebLogic Real Time (WLRT) 1.1 . They are boasting "deterministic" GC. There is a lot of hype out there....

Can you comment on this...

Thanks.
Raghu/..

re: I Am a Happy Janitor – Part 1: Finding garbage

Maoni Stephens — Tue, 12 Sep 2006 23:14:31 GMT

Mark, as you said

>>Personally, I think the GC should automatically get called when an AppDomain is unloaded, but I can see why it might not as well.

For the CLR since we need our stuff to work for a very wide range of scenarios we don't do that. As a matter of fact we used to trigger a GC on AD unload but there was perf problems with it so we didn't do that anymore.

For your own scenario, if you are completely in control when you unload appdomains and you don't do it often it's ok to induce GC yourself. I certainly would not recommand it as a general solution.

re: I Am a Happy Janitor – Part 1: Finding garbage

Mark E. — Tue, 12 Sep 2006 22:24:05 GMT

Maoni,

Thank you for your response. That is an interesting idea. The documentation (understandably) is very thin. I did find the solution to my problem that will not require such explicit memory control.

For the sake of other who may struggle with this topic, I'll include our solution...

My application's architecture is based on dynamically loading AppDomains which will then dynamically load plugins. All I had to do was to add a specific call to "GC.Collect();" at the point when the AppDomain was unloaded. This keeps the memory growth in check. It's the perfect time to call it as all the DLLs and objects have been freed with the AppDomain.

Personally, I think the GC should automatically get called when an AppDomain is unloaded, but I can see why it might not as well. At any rate, this allows us to keep a managable baseline memory footprint that a customer can see and understand.

Thanks for your help!
-Mark E.

re: I Am a Happy Janitor – Part 1: Finding garbage

Maoni Stephens — Mon, 11 Sep 2006 22:28:41 GMT

Hi Mark, take a look at IGCHostControl::RequestVirtualMemLimit:
http://msdn2.microsoft.com/en-us/library/ms404403.aspx

The IHostMemoryManager interface may also be of interest to you. For example, if you implement IHostMemoryManager::VirtualAlloc, when GC calls VirtualAlloc it will go through your implementation.