Nomad_Soul - Fotolia

Will server performance testing and diagnostics slow down my VMs?

Will diagnostics slow down my server's performance, and should I turn off performance data collection in production machines?

Server performance testing and diagnostic data collection is vital for ensuring proper system performance by locating potential bottlenecks, spotting inadequate resources and so on. However, diagnostic functions do impose a certain amount of load on a server's resources. If left unchecked, the diagnostic's resource demands might divert enough processor cycles, storage IOPS and network bandwidth to potentially impose a performance penalty on a server.

Consider a tool like VMware's vCenter Server which allows the collection of server performance data statistics over time. Administrators can set data collection to various levels of increasing detail (such as level 1, level 2 and so on). Increasing the level collects more data, but more data requires more compute and storage from the server. Increasing the collection level higher than level 2 can cause a variety of side-effects including bloated vCenter Server database and transaction log file sizes, unusually long times to organize the performance data (which may include gaps in the data), and even impair the overall performance of vCenter Server or its services. Server performance testing stress might also be seen even with generic tools like Microsoft's Performance Monitor when collecting and storing a large number of counters at high data rates.

The solution here is to apply common-sense and judicious use of server performance testing and monitoring diagnostics on production servers. Understand the performance characteristics that you need to see, turn off the data collection that you don't and set the collection frequency to a level that's appropriate. There may be some instances where more data and resolution are needed to isolate problems -- and that's perfectly acceptable as a necessary troubleshooting tactic -- as long as the diagnostics are scaled back or turned off when testing is completed.

If you discover that some other workloads are adversely affected by the diagnostic's computing overhead, consider migrating an affected workload to another server. If issues "follow" a migrated workload to another server, which can also be used as a diagnostic indicator, the problem is in the workload rather than the server hardware. You can always restore an affected workload back to the original server once the diagnostic process is completed and the data collection is scaled back or turned off.

Next Steps

The art of virtual application performance testing

Server benchmark and testing guide

What to look for in PerfMon benchmark testing

Dig Deeper on Virtual machine performance management