Memory Leak with Service?

[Jon Credit]

I have created a couple of Windows Services with VB dotNet
and I am seeing the memory usage grow on them. I have
looked real hard at my code but nothing really sticks out.
I downloaded the trial version of AQTime and ran the
services in there and again, nothing is sticking out.
Are there any known memory issues with 2003 dotNet with
building services?
The services are built in an OO model. Within the context
of a timer, get DB connection from connection manager
object (Shared functions), Retrieve a dataview, for each
row in the dataview: pull xml document from web, process
the xml document into new dataviews (4 to be exact) and
save to db.
after all rows are processed, close all DB connections and
re-enable timer.

I am seeing the memory consumption grow but I have
disposed everything I can dispose of. Are there any known
issues with what I am trying to do? or does anyone have
any suggestions on what to try?

TIA

Jon Credit

 

[Sunil TG]

Try to do garbage collection on your own,
GC.Collect(); - on the main running logic of your service
HTH
Sunil TG

 

[Jon Credit]

Thanks for the quick response. I have actually tried that
and it didn't seem to matter. The more testing I do with
AQTime the weirder this becomes. I have a class I
instantiate in my timer event. I see the total created and
current increase pretty much evenly until my service gets
a result set to process. Then the current goes to back to
0. It's almost as if the garbage collector is holding on
to memory and won't release it until the resources get
stressed.

--Jon

 

[Dag Johansen]

Hi Jon,

you said it! "It's almost as if the garbage collector is
holding on to memory and won't release it until the
resources get stressed."

And that's basically what's happening. It isn't "holding
on", but it does perform garbage collection only in
conjunction with memory allocation. Thing is that's not
something you need to worry about. Having a lot of unused
memory is not a good thing; if it isn't used it's just not
used - to what use?!? What matters is that there's memory
available when you do need it.

Garbage collection in .Net is based on a simple analysis
of an object being reachable (i.e. directly or indirectly
referenced from the heap or stack) or not. It's a major
improvement over the reference counting approach, which is
error-prone due to circular references (objects A and B
both reference each other). But it means there's no
natural "trigger" mechanism when an object goes out of
scope or a reference is overwritten with null - with the
reference counting approach the count is decremented and
if zero the memory is deallocated.

If you need to know more about your applications memory
usage to assess scalability or for similar reasons I would
suggest that you try out some of the performance analysis
tools Microsoft offer for this purpose. This will give
much more reliable results and allow you to simulate how a
large number of simultanious users affects your
application behavior in other areas than just memory
usage. (Say, database connections, concurrency.)

Happy coding,

Dag