Garbage Collection every 100 seconds

Question

Did any one encountered a scenario where application under high memory allocation load performed second generation collection every 100 seconds ?

We using 64-bit server

Answer 1

Since you are running on a Server, I am assuming it is a multicore machine as well. If this is the case, then you get Server GC flavor by default, so you don't need to set anything in your config file.

The fact that you are getting Gen2 collection every 100 second is a factor of your allocation pattern and object lifetime pattern. if your allocation pattern is consistent, you will get consistent GC's, you can verify this behavior by looking under .Net CLR Memory perf counters under perfmon

You will need to track the following metrics

1. Gen0 Collections

2. Gen 1 Collections

3. Gen 2 Collections

4. Allocated Bytes per second

5. Bytes in all heaps.

you should see the last metric moving like a jigsaw, increasing, a Gen2 Collection kicks in, decrease again, and the cycle repeats itself.

To avoid this, you will need to check

• Can you can objects between request, in pools?, this will avoid GC all together.
• If not, can you decrease the number of objects you allocate per request?

Hope this helps. Thanks

Answer 2

If you are under high memory load, and using a lot of objects, then yes: GC will get busy... if it is hitting gen-2, then it sounds like you've got a lot of mid/long-life objects hanging around...

I'm assuming that memory usage is fairly stable? The above could indicate some kind of pseudo-leak (perhaps holding onto too many objects via static events, etc), or could just mean that you have a high memory usage!

How much memory are you using? Could you consider x64 and a ton of memory? Alternatively, would the 3gb switch (x86) buy you a few more bytes?

Answer 3

You are probably generating more objects then can fit in the young heap all at once or you have a memory leak.

If you are intensively creating a lot of objects that need to be alive all at the same time, then you are probably overflowing the young section and some of the objects have to be copied to an older generation. This forces full collections more often as the older heap fills up. You probably need to find a way to allocate fewer objects in this case unless there is a way to request a larger young heap like there is with the Sun JVM.

If you actually store off the objects somewhere (say in a list owned by an old object), then you have a logical leak. In general, you don't want old objects referring to young ones. This tends to get the young objects promoted and the GC algorithms generally are optimized for it not happening. Also, you may want to considering clearing references if this significantly shortens the scope that an object can be alive in (although it usually is superfluous).

Barring that and you just have unusually high memory usage, there probably isn't a whole lot that you can do. Remember that for any long running program, you will eventually have to do some GCing, and the more memory you need at a time, the more often it comes.

Answer 4

I assume this is for .net.

GC collects when it wants to base on its algorithm. You can suggest the garbage collector to collect but it may not actually do anything.

you can use GC.Collect() to ask the GC to look if garbage can be collected. However it may not actually remove items from memory.

NOTE: Also, make sure you are clearing references correctly. Meaning unhooking events, Clearing references between objects. This will help the GC in collected objects that are no longer in scope.

Answer 5

If you are running a dual core CPU, try setting GCServer="true" in the app/web.config.

In my case, it does about 10% of the original GC's and the application feels a lot snappier.

Answer 6

A 2nd generation collection occurring like clockwork would suggest that either the GC.Collect method is being called like clockwork, or the allocation is like clockwork.

The randomness you expect to see in garbage collection is not likely to happen unless the allocations, or GC.Collect calls, are truely random.

Given that your server application is under such high load, and you create new objects during processing, I would seriously consider refactoring the code to see if fewer objects could be newly created during processing, by using object pools for example.

An object pool differs from most garbage collectors in that objects in a pool can be reused as soon as they are put back in the pool, and the garbage collector needs to perform a collection before a previous block of memory holding an object can be used again as a different object.