[ZBX-4117] system.cpu.load in Win32 agent is off by a factor of 10 Created: 2011 Sep 07  Updated: 2017 May 30  Resolved: 2011 Sep 15

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Agent (G)
Affects Version/s: 1.8.7
Fix Version/s: None

Type: Incident report Priority: Major
Reporter: Kent Tong Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: agent, windows
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In cpustat.c it is using the counter index of PCI_PROCESSOR_QUEUE_LENGTH, which is defined as 44. According to the the registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009\Counters, 44 is the "Processor Queue Length". According to Microsoft (http://technet.microsoft.com/en-us/library/cc940375.aspx), the value of that counter returns is scaled by 10 by default. It means that if the queue is 2, a value of 20 will be returned. However, I am not seeing that it is scaled back by the zabbix agent anywhere, so it is probably just returning a value like 20 when there are just 2 threads in the queue.

This may be the root cause for ZBX-3170.



 Comments   
Comment by Rudolfs Kreicbergs [ 2011 Sep 07 ]

The provided link is not a permanent one, found an entry in technet.microsoft.com named "Observing Processor Queue Length". There it states:
"The System\Processor Queue Length counter shows how many threads are ready in the processor queue, but not currently able to use the processor. Figure 7.2 shows a sustained processor queue with utilization ranging from 60 to 90 percent. Notice that the default scale for the Processor Queue Length counter value is 10. Therefore, System Monitor graphs a queue that is two threads long as 20. You can change the scale factor using the Data properties tab in System Monitor."

However, it is not clearly stated whether the counter value itself is scaled or the scaling is applied by System Monitor. More investigation is needed. Please provide more info, if you have (e.g. a link to the counter specification and the name of the page since microsoft.com obviously has problems with permanent links)

Comment by Rudolfs Kreicbergs [ 2011 Sep 07 ]

Found another article "Monitoring Processor Activity" that defines the counter:
The number of threads in the processor queue. Shows ready threads only, not threads that are running. Even multiprocessor computers have a single queue for processor time; thus, for multiprocessors, you need to divide this value by the number of processors servicing the workload. A sustained processor queue of less than two threads per processor is normally acceptable, depending upon the workload.

Comment by Kent Tong [ 2011 Sep 07 ]

The link is correct, just that JIRA includes the ) into it! So, please go to http://technet.microsoft.com/en-us/library/cc940375.aspx

Comment by Kent Tong [ 2011 Sep 07 ]

I think the simplest way is to write a small program to query and output the "Processor Queue Length" value and compare it to the real time value displayed in Performance Monitor in Windows. In the latter, the value displayed has a scale of 10.

Comment by Rudolfs Kreicbergs [ 2011 Sep 15 ]

Tested system.cpu.load for a Win32 agent and system.cpu.load values went well with the values shown by performance monitor when scale is set to 1 - that is an internal scale produced by the performance monitor.

Comment by Aleksandrs Saveljevs [ 2011 Sep 27 ]

See also http://technet.microsoft.com/en-us/library/cc768048.aspx : "System : Processor Queue Length. Oddly enough, this processor counter shows up under the System object, but not without good reason. There is only 1 queue for tasks that need to go to the processor, even if there is more than one CPU. Thus, counter provides a measure of the instantaneous size of the queue for all processors at the moment that the measurement was taken. The resulting value is a measure of how many threads are in the Ready state waiting to be processed. When dealing with queues, if the value exceeds 2 for a sustained period, you are definitely having a problem with the resource in question."

Generated at Thu Aug 07 08:41:32 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.