4

I have a windows service that runs 24x7 and the memory usage climbs steadily and about once a week we have to restart it.

I'm looking for information on understanding memory usage in .NET so that I may get a clear understanding of why our service is doing this.

I'd also like to gain a better understanding of this in .NET going forward.

Anybody got any good links?

THanks

Mike Murphy
  • 1,287
  • 1
  • 12
  • 23
  • Not what you're after, but for fixing this particular issue, I'd look for .NET objects that implement IDisposable, but that you're not disposing of. This is typically DB connections, calls into unmanaged code, anything the runtime can't completely identify as far as when it's really "done". – Harper Shelby Jun 28 '10 at 15:08
  • @Harper Not sure this would create a leak - the GC would eventually get around to cleaning this - unless a reference is held. The benefit of the IDispose interface and subsequent pattern is that you can release unmanaged resource or close off connections deterministically; if they aren't handled this way, GC should still kick in as a last-resort. – Adam Houldsworth Jun 28 '10 at 15:09
  • @Harper, I have to agree with Adam. Typically what you see when not calling `Dispose()` on disposable objects is locked files, failure to open more DB connections and such. Since the memory usage climbs so slowly it is unlikely that the GC did not run "early" enough to run the finalizers and release unmanaged resources. – Lucero Jun 28 '10 at 15:13
  • Perhaps I didn't say as much as I thought. My actual suspicion is that somewhere, there's a long-lived object that's holding references to one or more of these things. Of course, that could be the case with other, non-IDisposable implementing, objects as well. I just typically start there, as those are the kinds of things you will hold on to for a longer period of time, particularly if they're expensive to create. – Harper Shelby Jun 28 '10 at 21:23

4 Answers4

4

I haven't got any links, but it sounds like you have a memory leak somewhere - though I'm struggling to see how this would be introduced specifically on a weekly basis. Does your service register events in code? These are quite often gotcha memory leaks (the object that registered the event is finished with, but the handler was not unregistered, meaning a live reference exists so the object cannot be garbage collected).

Unregistered event handlers cause memory leak

Community
  • 1
  • 1
Adam Houldsworth
  • 63,413
  • 11
  • 150
  • 187
2

Well, it's kind of simple: the GC runs every now and then and removes dead objects. An object is considered dead when no live reference points to it. Life references are determined by starting at the roots (e.g. static variables, CPU registers, etc.) and traversing all the objects. All objects not reached by this are dead.

So to address you problem you should use a memory profiler and check what objects are staying in memory, for instance caused by having a static dictionary which "caches" values and such.

Lucero
  • 59,176
  • 9
  • 122
  • 152
1

What you're seeing is called a Memory Leak. There's plenty of resources available online. I'm not sure this is a valid question, unless you want to provide some of the code for us to identify the leaks.

JustLoren
  • 3,224
  • 3
  • 27
  • 34
0

http://www.eqatec.com/tools/profiler/ <= free