By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,974 Members | 1,834 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,974 IT Pros & Developers. It's quick & easy.

Perf counters, instances, and RemoveInstance

P: n/a
I'm instrumenting my app with a few performance counters
and I'd like to ask you all for some advice on how to handle
performance counter instances.

I have a class library that is a base library for most of our
..NET applications. It provides configuration, logging, exception
management/publishing, data access, etc.

I have my counters, but I'm curious how I should handle instances.
Right now, the instance name is exename-procid like test.exe-5129.

However, I need to remove the instance when the process exits,
so I hook the AppDomain.DomainUnload or whatever it is, but it
doesn't seem to fire reliably.

Does anyone have experience with this? What did you do about
counter instances and how did you solve the problem of when/how
to remove them effectively?

Thanks,
Chad
Nov 16 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Hi,

If you use one of the PerformanceCounter class constructor forms {see docs}
that explicitly takes an 'instance name' parameter then your counter will
exist only during the program run. You should not have to do anything
explicit at shutdown to remove an instance based counter - even if you crash
the counter will be removed when the process exits.

Also I don't think you need to explicitly invent a unique name {aka adding a
pid to the end of the instance name} for each counter instance - the OS will
not get confused if multiple instances with the same name are active...

--Richard

"Chad Myers" wrote:
I'm instrumenting my app with a few performance counters
and I'd like to ask you all for some advice on how to handle
performance counter instances.

I have a class library that is a base library for most of our
..NET applications. It provides configuration, logging, exception
management/publishing, data access, etc.

I have my counters, but I'm curious how I should handle instances.
Right now, the instance name is exename-procid like test.exe-5129.

However, I need to remove the instance when the process exits,
so I hook the AppDomain.DomainUnload or whatever it is, but it
doesn't seem to fire reliably.

Does anyone have experience with this? What did you do about
counter instances and how did you solve the problem of when/how
to remove them effectively?

Thanks,
Chad

Nov 16 '05 #2

P: n/a
Richard,

Thanks for the reply!

I believe you are incorrect about the instance disappearing. I know this
because if I don't
call RemoveInstance, the instance never gets removed. I can verify this
because the .NET
counters (like the ".NET CLR Data" category) shows a bunch of instances of
processes that
had died or been killed a long time ago (I don't reboot much).

Rebooting clears out all the instances and starts over from scratch.

I wish to keep the processes unique because we have an app which is a
service and you can
install this service multiple times to different directories to work on
different queues. The
process name is always the same. It would not be useful to customers it all
the processes of
that app shared the same instance in perfmon.

I came up with a solution in the meantime:

Create a singleton that holds a reference to the counters. In the finalize
of the singleton instance,
clear the counters.

This works for WinForms and Console apps, but not things like ASP.NET or
NUnit which create
app domains and close them.

I bind to the AppDomain.DomainUnload event and call GC.SupressFinalize(this)
so that the
finalizer doesn't get call (I don't want both to get called, only one or the
other).

This seems to work in every scenario I've tested so far (Winforms, console,
ASP.NET, NUnit,
ASP through COM interop, etc).

Thanks for the reply. Any comments/suggestions?

-c

"Richard" <Ri*****@discussions.microsoft.com> wrote in message
news:59**********************************@microsof t.com...
Hi,

If you use one of the PerformanceCounter class constructor forms {see docs} that explicitly takes an 'instance name' parameter then your counter will
exist only during the program run. You should not have to do anything
explicit at shutdown to remove an instance based counter - even if you crash the counter will be removed when the process exits.

Also I don't think you need to explicitly invent a unique name {aka adding a pid to the end of the instance name} for each counter instance - the OS will not get confused if multiple instances with the same name are active...

--Richard

"Chad Myers" wrote:
I'm instrumenting my app with a few performance counters
and I'd like to ask you all for some advice on how to handle
performance counter instances.

I have a class library that is a base library for most of our
..NET applications. It provides configuration, logging, exception
management/publishing, data access, etc.

I have my counters, but I'm curious how I should handle instances.
Right now, the instance name is exename-procid like test.exe-5129.

However, I need to remove the instance when the process exits,
so I hook the AppDomain.DomainUnload or whatever it is, but it
doesn't seem to fire reliably.

Does anyone have experience with this? What did you do about
counter instances and how did you solve the problem of when/how
to remove them effectively?

Thanks,
Chad

Nov 16 '05 #3

P: n/a
Hmmm,

Are the processes still running in task manager? If they are then the
counters will continue to exist...

Also, if you're expecting the counter to disappear from perfmon it won't -
perfmon will display the last queried counter value until you exit and
restart perfmon... If you want behavior similiar to OS counters that display
dashed lines after process exit then you'll probably have to explicitly
delete the counter or set its raw value to some secret/special value; I never
tried to acheive that behavior so I'm unsure of how to do it exactly...

--Richard

"Chad Myers" wrote:
Richard,

Thanks for the reply!

I believe you are incorrect about the instance disappearing. I know this
because if I don't
call RemoveInstance, the instance never gets removed. I can verify this
because the .NET
counters (like the ".NET CLR Data" category) shows a bunch of instances of
processes that
had died or been killed a long time ago (I don't reboot much).

Rebooting clears out all the instances and starts over from scratch.

I wish to keep the processes unique because we have an app which is a
service and you can
install this service multiple times to different directories to work on
different queues. The
process name is always the same. It would not be useful to customers it all
the processes of
that app shared the same instance in perfmon.

I came up with a solution in the meantime:

Create a singleton that holds a reference to the counters. In the finalize
of the singleton instance,
clear the counters.

This works for WinForms and Console apps, but not things like ASP.NET or
NUnit which create
app domains and close them.

I bind to the AppDomain.DomainUnload event and call GC.SupressFinalize(this)
so that the
finalizer doesn't get call (I don't want both to get called, only one or the
other).

This seems to work in every scenario I've tested so far (Winforms, console,
ASP.NET, NUnit,
ASP through COM interop, etc).

Thanks for the reply. Any comments/suggestions?

-c

"Richard" <Ri*****@discussions.microsoft.com> wrote in message
news:59**********************************@microsof t.com...
Hi,

If you use one of the PerformanceCounter class constructor forms {see

docs}
that explicitly takes an 'instance name' parameter then your counter will
exist only during the program run. You should not have to do anything
explicit at shutdown to remove an instance based counter - even if you

crash
the counter will be removed when the process exits.

Also I don't think you need to explicitly invent a unique name {aka adding

a
pid to the end of the instance name} for each counter instance - the OS

will
not get confused if multiple instances with the same name are active...

--Richard

"Chad Myers" wrote:
I'm instrumenting my app with a few performance counters
and I'd like to ask you all for some advice on how to handle
performance counter instances.

I have a class library that is a base library for most of our
..NET applications. It provides configuration, logging, exception
management/publishing, data access, etc.

I have my counters, but I'm curious how I should handle instances.
Right now, the instance name is exename-procid like test.exe-5129.

However, I need to remove the instance when the process exits,
so I hook the AppDomain.DomainUnload or whatever it is, but it
doesn't seem to fire reliably.

Does anyone have experience with this? What did you do about
counter instances and how did you solve the problem of when/how
to remove them effectively?

Thanks,
Chad


Nov 16 '05 #4

P: n/a
The processes are long gone. These are processes I killed a long time ago
because
they were misbehaving, yet they still show up as instances under ".NET CLR
Data".

Normal processes disappear from the list of instances for ".NET CLR Data",
however.

Likewise, when I set up my RemoveInstance() calls in the finalizer and
DomainUnload
handler, everything works great (unless the program is terminated
unexpectedly).

I have restarted perfmon, these derilict instances do not disappear until
reboot.
I suppose I could connect to them by creating a PerformanceCounter with
their
instance name and then call RemoveInstance to make it disappear.

What leads you to believe that program termination should remove the
instances?
There's nothing in the .NET or Win32 Performance stuff documentation that I
can
find that hints to this at all. Instances can be called anything, it's
merely a convention
that you create an instance-per-process, but this isn't the default or
anything.

Thanks again for keeping up on this. I hope that there's something obvious
I'm just missing.

The good news is, however, that it's working regardless. I'm just curious if
there's
another/better way.

Thanks again,
Chad
"Richard" <Ri*****@discussions.microsoft.com> wrote in message
news:63**********************************@microsof t.com...
Hmmm,

Are the processes still running in task manager? If they are then the
counters will continue to exist...

Also, if you're expecting the counter to disappear from perfmon it won't -
perfmon will display the last queried counter value until you exit and
restart perfmon... If you want behavior similiar to OS counters that display dashed lines after process exit then you'll probably have to explicitly
delete the counter or set its raw value to some secret/special value; I never tried to acheive that behavior so I'm unsure of how to do it exactly...

--Richard

"Chad Myers" wrote:
Richard,

Thanks for the reply!

I believe you are incorrect about the instance disappearing. I know this
because if I don't
call RemoveInstance, the instance never gets removed. I can verify this
because the .NET
counters (like the ".NET CLR Data" category) shows a bunch of instances of processes that
had died or been killed a long time ago (I don't reboot much).

Rebooting clears out all the instances and starts over from scratch.

I wish to keep the processes unique because we have an app which is a
service and you can
install this service multiple times to different directories to work on
different queues. The
process name is always the same. It would not be useful to customers it all the processes of
that app shared the same instance in perfmon.

I came up with a solution in the meantime:

Create a singleton that holds a reference to the counters. In the finalize of the singleton instance,
clear the counters.

This works for WinForms and Console apps, but not things like ASP.NET or
NUnit which create
app domains and close them.

I bind to the AppDomain.DomainUnload event and call GC.SupressFinalize(this) so that the
finalizer doesn't get call (I don't want both to get called, only one or the other).

This seems to work in every scenario I've tested so far (Winforms, console, ASP.NET, NUnit,
ASP through COM interop, etc).

Thanks for the reply. Any comments/suggestions?

-c

"Richard" <Ri*****@discussions.microsoft.com> wrote in message
news:59**********************************@microsof t.com...
Hi,

If you use one of the PerformanceCounter class constructor forms {see

docs}
that explicitly takes an 'instance name' parameter then your counter will exist only during the program run. You should not have to do anything
explicit at shutdown to remove an instance based counter - even if you
crash
the counter will be removed when the process exits.

Also I don't think you need to explicitly invent a unique name {aka
adding a
pid to the end of the instance name} for each counter instance - the
OS will
not get confused if multiple instances with the same name are

active...
--Richard

"Chad Myers" wrote:

> I'm instrumenting my app with a few performance counters
> and I'd like to ask you all for some advice on how to handle
> performance counter instances.
>
> I have a class library that is a base library for most of our
> ..NET applications. It provides configuration, logging, exception
> management/publishing, data access, etc.
>
> I have my counters, but I'm curious how I should handle instances.
> Right now, the instance name is exename-procid like test.exe-5129.
>
> However, I need to remove the instance when the process exits,
> so I hook the AppDomain.DomainUnload or whatever it is, but it
> doesn't seem to fire reliably.
>
> Does anyone have experience with this? What did you do about
> counter instances and how did you solve the problem of when/how
> to remove them effectively?
>
> Thanks,
> Chad
>
>
>


Nov 16 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.