Server performance testing and diagnostic data collection is vital for ensuring proper system performance by locating...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
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
Related Q&A from Stephen J. Bigelow
Photon OS optimizes VMware Photon platform deployment, not only in vSphere but in GCE, EC2 and more. Follow these steps to learn how to run Photon OS...continue reading
Performance problems can be caused by a number of things, including overprovisioning and poor vCPU selection and assignment to VMs. Use these ...continue reading
Think about what types of workloads are running on a VM before assigning compute resources, and consider using vCPUs from different cores for ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.