what is the reason for high % time in GC? for our

问题:

Does this mean memory leakage? The %Time in GC goes to 99% even when noone is using the application. Could you please help me why this %time in GC counter is strangely behaving. this could be a code issue? application is in Asp.net and uses services to call some methods. For disposing oracle connections, we used disposed method. we used standard dispose pattern in the application. Could someone give me insights into this?

回答1:

It is hard to diagnose this kind of problem without very detailed analysis and direct observation of the measurements, but on the surface what this suggests is that you have a very large number of objects that have been allocated and which are retained for a long time - combined with some form of memory pressure. The net performance of full GC2 garbage collection is essentially bound by the number of alive / reachable objects in your system. So: what is the memory consumption? Is it in the GB area? If you have a large memory footprint, it doesn't necessarily mean a leak - but it can mean a leak. You can use memory analysis tools (usually against memory dump files) to investigate what objects exist, and how they are "rooted" - i.e. what is stopping them from being collected.

The most common things that cause this are:

• a huge object model loaded into memory and retained for a long period - for example, loading a large chunk of your database into very large arrays/lists and keeping them globally to "help performance"
  • a common case of the above is reusing a single "data context" / "unit of work" / etc in your DAL between many requests
• inappropriate use of events - especially registering objects to listen to events on a long-lived object - that cause objects to stay reachable forever via a hypothetical event that actually never happens - for example, for every row doing globalObj.SomeEvent += row.SomeHandler; : once you've done this, row is reachable from globalObj, so if globalObj doesn't die: neither will row
  • a common case of the above is subscribing temporary objects to static events (and not unsubscribing them); static events don't die

As for what it is in your case - if there even is an actual problem: only deeper analysis will show what.