alanrenouf / vCheck-vSphere

vCheck Daily Report for vSphere
MIT License
735 stars 326 forks source link

Not an issue but would people be interested in improved performance of the report #458

Open danimalrowe opened 8 years ago

danimalrowe commented 8 years ago

Would users of vCheck be interested in having the report run faster? Or because most users run the report off hours do they not care about the amount of time the report takes? I have improved the report performance at my location and if users wanted to improve the runtime I could share my changes. With the current state the report 2 hours and 7 minutes and with the changes it runs in 38 minutes. My site has the following setup

Number of Hosts: 32 Number of Templates: 0 In-active VMs: 28 Number of Datastores: 83 Active VMs: 646 Number of Clusters: 9 Number of VMs: 674 DRS Migrations for last 1 Days: 26 Number of Datastore Clusters: 13

Sneddo commented 8 years ago

Well, I'd be curious...you don't have a massive environment so kind of interested to see why it is so slow to begin with.

What plugins do you have enabled, and which are taking the longest?

danimalrowe commented 8 years ago

I am running all plugins that come with vCheck. The longest running portions and their runtime are the following:

VM CPU Usage 2709.72 VMs in uncontrolled snapshot mode 1962.5 VM CPU %RDY 1329.8 Disk Max Total Latency 294.94 Snapshot Information 161.84

Plugin finished start Run Time VM CPU %RDY 11:28:58 11:06:48 0:22:10 VM CPU Usage 12:14:07 11:28:58 0:45:09 VMs in uncontrolled snapshot mode 12:50:20 12:17:37 0:32:43

PowerCLI E:> Get-PSVersion

Major Minor Build Revision


4 0 -1 -1

PowerCLI E:> Get-PowerCLIVersion

PowerCLI Version

VMware vSphere PowerCLI 6.0 Release 3 build 3205540

Component Versions

VMWare AutoDeploy PowerCLI Component 6.0 build 2358282 VMWare ImageBuilder PowerCLI Component 6.0 build 2358282 VMware vSphere PowerCLI Component 6.0 build 3205541 VMware Cloud Infrastructure Suite PowerCLI Component 6.0 build 3205541 VMware VDS PowerCLI Component 6.0 build 3205541 VMware vCloud Director PowerCLI Component 6.0 build 3191743 VMware HA PowerCLI Component 6.0 build 2591578 VMware License PowerCLI Component 6.0 build 3188616 VMware vCloud Air PowerCLI Component 6.0 build 3191743 VMware PowerCLI Component for Storage Management 6.0 build 3191741 VMware vROps PowerCLI Component 6.0 build 3191742 VMware vSphere Update Manager PowerCLI 6.1 build 3191523

Sneddo commented 8 years ago

Do you use the VCSA or vCenter on Windows? As a comparison, my current VCSA environment has roughly half the amount of VMs, but takes about 10% the time it takes for you to pull the CPU ready and usage. Seems like there may be an issue pulling the stats from vCenter perhaps.

Also, it would be worth updating to PowerCLI 6.3 Release 3. Some very impressive speed increases in the latest release from my experience.

What changes did you make to reduce the runtime?

danimalrowe commented 8 years ago

We are using vCenter 5.1 on Windows Server 2008 R2.

The changes I made to 'VM CPU %RDY ' and 'VM CPU Usage' are similar in that I made these plugins multi-process the VMs. Originally I made each VM a separate process and limited the number to 10 VMs at a time. But the best result came when I split the number of VMs into 11 arrays and ran each array of VMs as multi-processes.

For 'VMs in uncontrolled snapshot mode' I created a plugin that runs in '00 Initialize' called '1003 Get Snapshot Info.ps1' that multi-processes the Datastores searching for snapshot file names and creating a hash list of Datastore Name and a list of snapshot file paths. This runs in about 5 minutes. Then the 'VMs in uncontrolled snapshot mode' just processes this hash for snapshots that meet the criteria for this module. This runs in about 3 seconds. The total run time is around 5 minutes while the previous version runs in about 32 minutes.

Using the concept of hash list I have created what I call indexes that are based on the VM, FullVM and Datastores arrays. For the VM array I created two index hashes. The first index has the Hash Key as the VM's ID and the data element is the VM Array position. The second index has the Hash Key as the VM's Name and the data element is the VM Array position. The FullVM and Datastores arrays have similar indexes. Where I use these indexes are in situations like found in 'More RAM than free space on Datastore' where the current line is

 $Details.FreeSpaceMB = ($Datastores|Where {$_.Name -eq (($Machine.ExtensionData.Config.Files.VmPathName).Split('[')[1]).Split(']')[0]}).FreeSpaceMB

which I switched it to the following

  $FreeSpaceMB = $Datastores[$DSIDHash[$Machine.DatastoreIdList]].FreeSpaceMB
  if ( $FreeSpaceMB.Count -gt 1 ) {
      $Details.FreeSpaceMB = $FreeSpaceMB[0]
  } else {
      $Details.FreeSpaceMB = $FreeSpaceMB
  }

Original run time is 2:37 and with the changes it ran in 1 second.