locked
Performance Monitor RRS feed

  • Question

  • Hello,

    I have encountered such a problem that my application on some machines after some time starts  consuming too much processor time and slows down other applications. My basic idea is to have some  monitoring system which is able to detect such situation and as well it is able to report where the code is running at the moment. If such a tool would be external, it would be even better. I think System.Diagnostics class offers such possibilities but I don't know it much about it. I looks to me this excercise involves some techniques which are better to be told than to try to invent them. Would anybody help me with this assignment ?

    Thanks a lot

    Monday, March 5, 2007 4:40 PM

Answers

  • There are at least a couple of approaches you can take here. The good news is, tools already exist to help you examine this type of problem.

    You can use "Performance Monitor" which ships with the OS to determine which thread(s) in the application is/are consuming the high percentage of CPU cycles. You can get to Performance Monitor by running perfmon.exe. To start you'll want to look at the "% Processor Time" counter under the "Thread" object. When the application is experiencing its high-CPU condition, you can attach a debugger and look at that thread's call stack to see where it is in the code. Timing might be tricky here if the high-CPU condition doesn't last long. If that's the case, you can launch the process under the debugger and suspend the process when you experience the condition. Alternatively, you could also capture a dump of the process at that point. In the debugger, you'll want to correlate the threads based on the "Instance ID" perfmon gives you for the thread. If you prefer to use VS to do your debugging, taking a dump will not be an option (VS does not yet support debugging managed code in dumps). I realize I omitted a lot of details on the particulars of debugging, so if you need guidance let us know and we can provide more details and/or point you to some documentation.

    Alternatively, you could use a profiler to determine where the application is spending large amounts of time. VS (Team Developer and Team Suite) ships with a code profiler. See http://msdn2.microsoft.com/en-us/vstudio/aa718570.aspx for an example. Additionally, there are a number of 3rd-party profilers which offer similar functionality. If you do a web search for ".net profiler" you should find a number of hits. Products range from freeware/shareware to enterprise support. These tools are built using the CLR profiling APIs. See http://msdn2.microsoft.com/en-us/library/ms404386.aspx for details. If you're interested in working with these APIs yourself, there is a forum targeted at helping users here: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=868&SiteID=1.

    If you do go the profiling route I'd also recommend running perfmon at the same time to ensure the application is experiencing the symptoms you describe. I'm not sure if VS Code Profiler correlates percentage of CPU time, so you'll want perfmon results to verify that process was indeed problematic at the time of the capture. 

    These options should offer you a good start.

    Kind Regards,
    Jon Langdon


     

    Monday, March 5, 2007 6:45 PM

All replies

  • There are at least a couple of approaches you can take here. The good news is, tools already exist to help you examine this type of problem.

    You can use "Performance Monitor" which ships with the OS to determine which thread(s) in the application is/are consuming the high percentage of CPU cycles. You can get to Performance Monitor by running perfmon.exe. To start you'll want to look at the "% Processor Time" counter under the "Thread" object. When the application is experiencing its high-CPU condition, you can attach a debugger and look at that thread's call stack to see where it is in the code. Timing might be tricky here if the high-CPU condition doesn't last long. If that's the case, you can launch the process under the debugger and suspend the process when you experience the condition. Alternatively, you could also capture a dump of the process at that point. In the debugger, you'll want to correlate the threads based on the "Instance ID" perfmon gives you for the thread. If you prefer to use VS to do your debugging, taking a dump will not be an option (VS does not yet support debugging managed code in dumps). I realize I omitted a lot of details on the particulars of debugging, so if you need guidance let us know and we can provide more details and/or point you to some documentation.

    Alternatively, you could use a profiler to determine where the application is spending large amounts of time. VS (Team Developer and Team Suite) ships with a code profiler. See http://msdn2.microsoft.com/en-us/vstudio/aa718570.aspx for an example. Additionally, there are a number of 3rd-party profilers which offer similar functionality. If you do a web search for ".net profiler" you should find a number of hits. Products range from freeware/shareware to enterprise support. These tools are built using the CLR profiling APIs. See http://msdn2.microsoft.com/en-us/library/ms404386.aspx for details. If you're interested in working with these APIs yourself, there is a forum targeted at helping users here: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=868&SiteID=1.

    If you do go the profiling route I'd also recommend running perfmon at the same time to ensure the application is experiencing the symptoms you describe. I'm not sure if VS Code Profiler correlates percentage of CPU time, so you'll want perfmon results to verify that process was indeed problematic at the time of the capture. 

    These options should offer you a good start.

    Kind Regards,
    Jon Langdon


     

    Monday, March 5, 2007 6:45 PM
  • ok, thx
    Tuesday, March 6, 2007 10:54 AM