DPACK Performance Impact on Local and Remote Windows Servers

David Hunter

-Collector

DPACK uses the default protocols exposed by operating systems to collect configuration and performance data.  Collecting data from a server has virtually no impact on the server’s CPU, memory, disk, and network resources.

If a single collector process is connected to a large number (50 or more) remote servers, the collector will begin to use a small but noticeable level of CPU and memory.  This is especially true when using the Linux collector, as it will spawn an SSH process for each remote connection.

It is not necessary to run the collector on a Production Server as the collector can remotely monitor the production servers.

 

-Collection: Local/Remote

For local Windows collection, the collector uses the Microsoft PDH protocol and other Windows system API calls. These are the same performance counters that Microsoft PerfMon accesses.

The PDH protocol also could be used for remote collection. However, this protocol is not sufficiently secure when used remotely. So, for remote collection, the collector uses the remote WMI protocols. 

We are unaware of any cases where using DPACK has been confirmed to cause performance issues on a local or remotely targeted system. 

Since 2008, five cases have been reported from the field where users complained that remote WMI collection from DPACK caused problems with their Production Windows Servers.  Over that same time-frame, DPACK has collected millions of production environments.  We investigated each case, and none were proven to be related to DPACK.  Our opinion is that out of millions of runs, one is bound to coincide with an unrelated incident.  Understandably, the natural reaction is to initially blame whatever is new (such as DPACK running).

DPACK utilizes standard WMI data calls from Microsoft for remote captures.  

Win32_ComputerSystem, Win32_DiskDrivePhysicalMedia, Win32_DiskDriveToDiskPartition, Win32_DiskPartition, Win32_LogicalDisk, Win32_LogicalDiskToPartition, Win32_NetworkAdapter, Win32_NetworkAdpaterConfiguration, Win32_OperatingSystem, Win32_PerfRawData_PerfOS_Processor, Win32_PerfRawData_Tcpip_NetworkInterface, Win32_PhysicalMedia, Win32_Processor, Win32_SystemEnclosure, Win32_PerfRawData_HvStats_HyperVHypervisorLogicalProcessor, Win32_PerfRawData_PerfDisk_PhysicalDisk,  Win32_PerfFormattedData_PerfDisk_PhysicalDisk, MSCluster_Disk, MSCluster_DiskPartition, MSCluster_DiskToDiskPartition, and StdRegProv are examples.

Microsoft has acknowledged dozens of problems with WMI over the years and incorporated their fixes into service packs and OS updates.  Our recommendation is that users keep their operating systems fully patched to minimize risks.

Was this article helpful?
0 out of 0 found this helpful
Please sign in to leave a comment.