The data_engine is dropping ntperf probe QOS data. Log entry sample: de: QoSInsert::CheckDataIntegrity - message dropped; samplemax found in data but not in the definition. qos=QOS_WIN_PERF source=xxxxxxxx

book

Article ID: 6148

calendar_today

Updated On:

Products

DX Infrastructure Management NIMSOFT PROBES

Issue/Introduction

data_engine is dropping ntperf QOS_WIN_PERF data. The log shows numerous messages of the QOS data being dropped, e.g.,

Mar 2 03:52:11:116 [85288] de: QoSInsert::CheckDataIntegrity - message dropped; samplemax found in data but not in the definition. qos=QOS_WIN_PERF source=xxxxx.xxxx.local target=DFS MPIO 10 READ/10 M:

Cause

The ntperf probe sends QOS_MESSAGES in an incorrect format in this case. Specifically, there are two types of QoS messages: those which have a maximum possible value (like a percentage with a maximum value of 100) and those with no defined maximum value.

The ntperf probe is sending data for QOS_WIN_PERF and is sending an erroneous value for the "samplemax" bit - which tells the data_engine that it is sending a maximum value. However, the corresponding QOS_DEFINITION entry, which tells the data_engine what format to expect, indicates that there is not supposed to be a maximum value on the data.

***This causes data_engine to drop the QOS messages, and when a very  large number of these messages are being dropped, the performance of the data_engine may suffer***

Numerous messages in the data_engine log for QOS coming from robots running the ntperf probe(s):

Mar 2 03:52:11:116 [85288] de: QoSInsert::CheckDataIntegrity - message dropped; samplemax found in data but not in the definition. qos=QOS_WIN_PERF source=xxxxx.xxxx.local target=DFS MPIO 10 READ/10 M:
Mar 2 03:52:11:116 [85288] de: QoSInsert::CheckDataIntegrity - message dropped; samplemax found in data but not in the definition. qos=QOS_WIN_PERF source=xxxxx.xxxx.local target=DFS MPIO 11 READ/11 P:

Environment

- UIM 8.5- data_engine 8.47- SQL Server 2012 SP3- ntperf v2.06

Resolution

This is a known issue with the ntperf v2.06 probe.

Obtain ntperf 2.09 (available in the UIm GA Archive) to resolve this issue.

To take full advantage of this new version you will need to deploy it to all robots where the ntperf probe is deployed. (You can use Infrastructure Manager, Find->Probes to help you locate them.) That will ensure that no robot wth ntperf is sending erroneous QoS messages any longer.