Profiling .NET Windows Service

Use this forum to discuss subjects that don't belong in the other forums.

Moderator: SciTech Software

Profiling .NET Windows Service

Postby pcole » Mon Jan 15, 2007 10:45 am

I'm a total newbie to profiling. We are examining a .NET (2.0) Windows Service which on each timer_elapsed event selects data sets from an Oracle database (via System.Data.OracleClient) and then checks each row to determine if any any time specific values require an action. Much of the code has been generated automatically using the DataSet designer to create a DAL.

The service runs fine for about 7 hours and then simply stops processing (service status is that it is still running). The effect is as though the timer has been disabled and so no more processing iterations occur.

While the service executes there is a steady build up in the number of System.WeakReference instances, to the point where there are many millions of them hanging around. They never seem to get cleared out. We have manually placed DataTable dispose calls wherever appropriate to try to ensure they are GC'd as soon as possible, but we are not sure what to do about these WeakReferences. If indeed we need to. I don't know if it is this that is causing the appliaction to fail or not, but they look suspicious to me. Has anyone else experieced anything similar? Do you have any pointers?
pcole
 
Posts: 1
Joined: Mon Jan 15, 2007 10:25 am
Location: Peterborough, UK

Postby Andreas Suurkuusk » Tue Jan 16, 2007 9:33 pm

It doesn't sound correct that you have a steady build up in the number of WeakReference instances, but it depends on the application of course.

I suggest that you collect a heap snapshot and investigate the WeakReference instances. By double-clicking the WeakReference class in the Classes view you will bring up the details view of the class. This view will show you summary information about all WeakReference instances.

The things you should look for is allocation stacks that have created a lot of new instances (by selecting "New live instances" in the "Sort stacks by" list) and root paths that are holding on to a large number of new instances (by selecting "New live instances" in the "Sort root paths by" list).

By investigating the allocation call stacks and the root paths, you should be able to get an idea on why the WeakReferences are created, and why they're not released (or at least who's responsible for hanging on to the instances).
You can also double-click one of the WeakReference instances, to get information about a specific instance. Under the "Field values" tab you can for instance see if the WeakReference instances still have a target, or if the Target is null. If the Target is null, that's an indication that the WeakReference should probably have been cleaned up.
Best regards,

Andreas Suurkuusk
SciTech Software AB
Andreas Suurkuusk
 
Posts: 964
Joined: Wed Mar 02, 2005 7:53 pm
Location: Sweden


Return to General

Who is online

Users browsing this forum: No registered users and 3 guests

SciTech Software logo

© Copyright 2001-2016. SciTech Software AB
All rights reserved.


SciTech Software AB
Kartvägen 21
SE-175 46 Järfälla
Sweden


E-mail: mail@scitech.se

Telephone: +46-706868081