PS C:\> Get-CimInstance Win32_Thread - filter "ProcessHandle = 77656" | select ProcessHandle, Handle, UserModeTime These two threads were created with the following snippet: Here is another example, this time PowerShell 7, running two threads, each fully utilizing a single core. Lastly, in the lower section of the screenshot, it shows the User Time, which tells us how long that particular thread has been running for. Further, if the usage was higher, say, 20%, it would still reveal that one thread was fully consuming a core, while another thread could be consuming the remaining ~3.4% on a different core. This confirms that a single thread is being bottlenecked and that it’s not multiple threads each doing a bit of work to total ~16.6% usage. We can immediately see our PowerShell process has a total of 10 threads, one of which is actively doing work, and is consuming ~16.64% percent of the CPU. Process Explorer is a fantastic tool that makes it easy to see this data, let’s load it up and look at the properties of the PowerShell process, specifically the Threads tab. Thread CPU utilization with Process Explorer But if we divide 100 by the number of cores in the system (6), we get 16.6666666666667, and it becomes clearer that it is bound by the performance offered by a single core.īut this is all guesswork, let’s verify that with Process Explorer. Our bottlenecked process (PowerShell) is only consuming ~17% of the CPU. Even sorting the processes by CPU usage doesn’t show a clear issue. The single threaded workload is being bounced around the cores by the CPU scheduler, so it looks like our CPU utilization couldn’t possibly be the culprit. Most people looking at this (albeit exaggerated) example aren’t going to immediately jump to the conclusion that there is a CPU bottleneck, yet, there is a single threaded process running which consuming 100% of a single core.Įven if we look at the CPU graphs it isn’t obvious. Long running single threaded operations require us to understand what is happening inside a process, and looking at Task Manager isn’t good enough, as shown by the following screenshot. If you’ve spent time in a sysadmin or similar role you’ve probably been asked to investigate why something is running slow, and to offer solutions for making it run faster. We’re going to cover two methods: Process Explorer and PowerShell, but first let’s cover why this even matters. So how can we drill into a process to get real data on thread performance? It could also be that the CPU utilization of the process is some odd number that doesn’t neatly fit into our division, and we don’t have a good way of knowing what is happening. It could be that two threads within the process are both using 50% of a single core, and making it look as if the process is CPU bound when it is not. However, as we saw in the previous post, unless we configure CPU affinity for that process (which we generally don’t want to do), this bottleneck won’t be visible in Task Manager or other CPU graphs as the thread would be moved between cores by the Windows CPU scheduler.Īnother downside of this method is that it doesn’t give us any verifiable data - we’re making educated guesses. To illustrate this with an example, if we have a 4 core CPU and a process in Task Manager is sitting at 25% CPU utilization, we can make a guess that a thread within that process is fully utilizing that core. In a previous post we examined ways to get per core CPU performance data using PowerShell and WMI, and there was a question that we mostly glossed over - how do we know when a thread is CPU bound?Ī simple but unreliable method was to look at the CPU usage of a process, and if the usage was hovering at a value that equaled the percentage a single core contributed to the total CPU resources available, then it was likely that a thread within the process was CPU bound. Analyzing Thread CPU Utilization with ProcessExplorer, PowerShell, and WMI
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |