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

I've seen this 100 second frequency too, it doesn't happen on all production setups, but I've seen it locally and on other setups.

Answer 2

For that to happen the memory use should be very consistent for both the process and the system as well. Garbage collection is triggered by either of these events:

• Generation 0's budget is full
• GC.Collect() is called
• CLR wants to free memory
• AppDomain shutdown
• CLR shutdown

The likely candidates in your case are probably regular collection (i.e. due to allocation) or a timed Collect().

EDIT: Just to clarify about allocations. Allocation of regular objects always happen in generation 0 (exception is large objects of 85000 bytes or more, which are allocated on the large object heap). Instances are only moved to generation 1 and 2, when they survive a collection. There are no direct allocations in generation 1 and 2.

Also, generation 2 collection (also known as a full collect) is performed when generation 0 / 1 collections do not free sufficient memory (or when a full collect is explicitly requested).

Answer 3

That the garbage collector is being invoked frequently is not in itself necessarily a huge issue - it could however be a flag that you are not optimally handling your memory well (for instance not passing massive strings by reference into methods).

Garbage collection should be non-deterministic. That noted, if you are running a number of critical tasks, but your thread(s) are sleeping at some juncture (like every 100 seconds) it is reasonable that the garbage collector may take the opportunity to collect at that point. More likely is that the consumption due to allocation peaks at more-or-less regular intervals and the garbage collector is invoked to retrieve unused memory.

I highly suggest profiling the memory consumption of your application.

Answer 4

Could it be just your application that creates a huge object every 100s, and so GC is forced to make its work?

Answer 5

I do not understand what is causing the “performed second generation collection every 100 seconds”, it is very rare to see a real life system that does anything to such a “clock work” cycle.

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... You are probably generating more objects then can fit in the young heap all at once or you have a memory leak.

Assuming you don’t have a leak, have you checked with a memory profiler? I am also assuming you are not creating a lot of unnecessary garbage (e.g string1 += string2 inside of a loop).

I can think of two things that may help.

By limiting the number of requests (threads) Asp.net processes at the same time, you may limit the number of live objects and also speed up the processing of a single request, so not keeping object alive for as long. (Are you getting a lot of thread contact switches?)

If you are storing object in the Asp.net cache and/or the Asp.net session. You could try using an out-of-process store for this caches information, e.g the Asp.net session server, a 3rd party session server, memcache or the recently released cache server from Microsoft (Velocity). Just rereading data from the database when you need it, may be better then storing it in long lived object.

Failing the above, how much memory are you using? Could you consider x64 and a ton of memory? Or a webfarm..

Answer 6

I'm assuming you are using .NET as well. I'm not sure what tools you are using, but I'm a huge fan of Red Gate's Ants profiler. I use it at work. It can identify which objects are hogging resources. Once you narrow it down, hopefully, you can find the offending code and free up resources properly.

Check your code and make sure you're calling Dispose() whenever possible.

Let us know how it goes.