Incorrect data from perf_counter key - MSSQL process

[Murilex]

I've created an item on my TemplateMSSQLServer (zabbix) to monitor processor time of sqlserv process (MS-SQL Server process name). On Windows, the counter "\Process(PROCESS_NAME)\% Processor Time" reports the CPU consume of a process considering all the logical CPUs present on the system. Windows documentation about counter "\Process(PROCESS_NAME)\% Processor Time" says that the real processor time consumed by a process should be divided by the number of logical CPUs. On each one of my SQL Server systems, for example, there are 16 logical CPUs. Follows some sample data obtained from one of my systems using typeperf Windows built in command:

C:\zabbix>typeperf "\Process(sqlservr)\% Processor Time"
"(PDH-CSV 4.0)","\\MYHOST\Process(sqlservr)\% Processor Time"
"04/19/2010 15:57:08.965","757.807650"
"04/19/2010 15:57:09.965","906.244200"
"04/19/2010 15:57:10.965","751.557690"
"04/19/2010 15:57:11.965","828.119700"
"04/19/2010 15:57:12.965","992.181150"
"04/19/2010 15:57:13.965","989.056170"
"04/19/2010 15:57:14.965","1153.117620"

Then, considering the documentation, the real processor times are: 47.36%, 56.64%, 46.97%, 51.76%, 62.01%, 61.82%, 72.07%, respectively.

Unfortunately, zabbix_agentd always reports value "100.000000" for this counter when its real measure is above 100:

zabbix_agentd.exe -t perf_counter["\Process(sqlservr)\% Processor Time"]
perf_counter[\Process(sqlservr)\% Processor Time] [d|100.000000]

Follow my item settings on zabbix:
Description: SQL: % Processor Time
Type: Zabbix Agent
Key: perf_counter["\Process(sqlservr)\% Processor Time"]
Type of Information: Numeric (float)
Use Multiplier: Do not use
Store value: As is

Is it a known problem or am I doing something wrong?

[NOB]

Bug in zabbix agent (Win, 1.6.8) found

Hi

i can, indeed, verify your results.
The same happens on an Exchange 2007 server with the STORE
process.

It is a bug in the zabbix agent (1.6.8) on Windows, only, of course.

The default handling of the function PdhComputeCounterStatistics
is The default behavior is that counter values are capped at a value of 100.

They should have used PDH_FMT_DOUBLE | PDH_FMT_NOCAP100
instead of just PDH_FMT_DOUBLE or even use PDH_FMT_DOUBLE | PDH_FMT_NOCAP100 | PDH_FMT_NOSCALE

I'll fix the bug in our environment.
I'm not sure which side effects this will show.

Updated: The same code is in 1.8.1

Regards

Norbert.

[Murilex]

Problem reported on:

https://support.zabbix.com/browse/ZBX-2364

[jroberson]

Still an issue on 1.8.5

This is still an issue on 1.8.5 and it seems the bug is still alive on the tracker as well. I was using the 1.6.9 client on my Win SQL server but upgraded to the latest client that I had to make sure it was still an issue. I can try 1.8.6 when I upgrade the server, but if the bug is still "unresolved" on the tracker then I bet it remains with 1.8.6 clients. Too bad, I could have used this to help troubleshoot some slowdowns we've been having. I'll just have to find another way to monitor it.