Hello all, Ashish here with a brief discussion about an issue you may have seen when using Perfmon to monitor system performance.
When you use Perfmon to monitor multiple instances of the same process, you have probably noticed that it differentiates the process by giving them an arbitrary numbered name, such as Dllhost, Dllhost#1 and Dllhost#2. This is especially noticeable in the case of Svchost.exe, which may easily have 15 or more instances on newer operating systems.
There are a few reasons why this might be less than optimal, but the primary problem is that the instance name changes if a process exits or restarts. So, consider the following scenario:
1. You have 3 Dllhost.exe processes running, which show up in Perfmon as Dllhost, Dllhost#1 and Dllhost#2.
2. The second Dllhost process exits.
3. You now have Perfmon showing processes named Dllhost and Dllhost#1.
The problem with this is that the process that was a minute ago named Dllhost#2 is now showing up as Dllhost#1 and Dllhost#2 has disappeared. If we think a little deeper on this, we see that this also means that any counter we are viewing has also switched to the new name, but is showing up on the graph in place of the counter it took over from. A way to visualize this is this:
Let’s say you have the three Dllhost processes we talked about above being monitored for CPU usage. Both of the first two Dllhost processes are using very little CPU, but for some reason the third one (Dllhost#2) is running at 90% CPU. For whatever reason, the second Dllhost process (Dllhost#1) exits and the third one (Dllhost#2) changes it’s name to Dllhost#1. What you now have is a graph that shows that Dllhost#2 stopped logging and Dllhost#1 jumps up to 90% CPU. In actually of course, Dllhost#1 exited and Dllhost#2 started logging on the same graph that used to belong to Dllhost#1. In the case of something like Svchost.exe with a lot of instances, you could end up with very different numbers after a few hours of logging. As I am sure you can guess, this would be a problem.
You can easily see this in action by running multiple instances of something like Notepad.exe. If you view the ID Process counter for each, you should see a nice flat graph for each instance of the running process since ID Process is the PID of the process and the PID does not change. However, if you kill one instance of the process, the others will realign within Perfmon, which means that the PID will change for that instance, and any other instance with a higher numbered name. Of course the PID does not actually change, but within Perfmon it will appear that that is what happened. Here is what it looks like on my system with 6 instances of Notepad.exe running:
And here is what it looked like after I killed the first Notepad process:
As you can see, the 5 remaining processes ‘moved’ up in position, at least as far as naming is concerned. Because of this, the PIDs all changed also or at least appeared to. So, the reason I am pointing all this out is that we can easily change the behavior so that it names the processes by PID, and not by a relatively meaningless number. To do this, we follow the steps in kb article 281884:
281884 The Process object in Performance Monitor can display Process IDs (PIDs)
Making this registry change will display processes in the format of ProcessName_PID instead of ProcessName#1. The article of course tells how to do this, but for the sake of simplicity, here are the steps:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance
- 1 : Disables PID data. This value is the default value.
- 2 : Enables PID data.
Warning: Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
Important: If you enable this feature, you may be unable to monitor process-specific information by using third-party utilities or custom-made programs, and this functionality may change at any time in the future without notice.
So, that’s about all for this post. This is Ashish Sangave, Technical Lead with the Windows Performance team at Microsoft Enterprise Support signing off. Happy Troubleshooting!
Ashish Sangave
| Share this post : |
|
|
|
|
|
|
|
|
<br/>
Microsoft
