Once you have created performance information using a PLA data collector set, you can use PowerShell to analyze the data.
In this recipe, you create a very simple report on the CPU usage of SRV1. The source of the report is the information logged as a result of the Creating and using PLA data collection sets recipe. As noted earlier, PLA can output the performance data in a variety of formats. In the Creating and using PLA data collector sets recipe, you used a binary log file format. This recipe, on the other hand, makes uses of a CSV format.
This recipe uses PLA data collection output logged in a CSV format from SRV1. To create CSV output, use the Creating and using PLA data collector sets recipe and change the value of the log file format to 1.
- Import the CSV file of counter samples:
$Folder = 'C:PerfLogsAdmin' $File = Get-ChildItem -Path $Folder*.csv -Recurse
- Import the performance counters:
$Counters = Import-Csv $File.FullName "$($Counters.Count) counters in $($File.FullName)"
- Fix the issue with the first row in the counters:
$Counters[0] = $Counters[1]
- Obtain basic CPU stats:
$CN = '\SRV1Processor(_Total)\% Processor Time' $HT = @{ Name = 'CPU' Expression = {[System.Double] $_.$CN} } $Stats = $counters | Select-Object -Property *,$HT | Measure-Object -Property CPU -Average -Minimum -Maximum - Add the 95th percentile value of the CPU:
$CN = '\SRV1Processor(_Total)\% Processor Time' $Row = [int]($Counters.Count * .95 ) $CPU = ($Counters.$CN | Sort-Object) $CPU95 = [double] $CPU[$Row] $AMHT = @{ InputObject = $Stats Name = 'CPU95' MemberType = 'NoteProperty' Value = $CPU95 } Add-Member @AMHT - Combine the results into a single report:
$Stats.CPU95 = $Stats.CPU95.ToString('n2') $Stats.Average = $Stats.Average.ToString('n2') $Stats.Maximum = $Stats.Maximum.ToString('n2') $Stats.Minimum = $Stats.Minimum.ToString('n2') - Display the CPU performance summary:
$Stats | Format-Table -Property Property,Count,Maximum,CPU95,Minimum
This recipe uses a CSV file of performance data created by using PLA. In step 1, you import the data in the CSV file. This step produces no output.
In step 2, you display the number of counter samples imported, which looks like this:
In step 3, you fix a known error with PLA affecting the first row returned (PLA returns an invalid first row). The fix is to assume the first two rows have identical values. That has the potential to introduce some degree of error into detailed calculations. The impact of such an error is small and mitigated by having a significant number of samples.
In step 4, you analyze the data sample and derive basic CPU usage statistics. In step 5, you create a 95th percentile value for CPU usage on SRV1.
With step 6, you work out an approximation of the 95th percentile CPU time. This is a good number to track, as it is a measure of how high, in general, the CPU load is on the computers that you are monitoring (95 percent of the time). It eliminates infrequent but high CPU measurements which might be misleading. You calculate this by first counting the total number of rows returned (sorted by CPU utilization), and then calculating an index that contains a value of 0.95 times the number of rows.
You then use this index to get that row from a list of sorted CPU values. With 100 rows of data returned, this calculation would return row 95 (that is, the 95th-highest CPU reading in the sample set).
Assuming you have a significant number of samples, this approach gets you the row that is a good approximation of the 95th-percentile CPU time measurement. At the end of this step, you add the value as a note property (CPU95).
In step 7, you display a summary of the CPU usage on SRV1, including a maximum, minimum, and 95th-percentile average CPU utilization, which looks like this:
In this recipe, we reported on just one counter, the total CPU time on just one computer (SRV1). Although there was a maximum CPU utilization during the sampling of 100%, most of the time, CPU utilization was at or below 27.26%. That suggests SRV1 is not CPU-bound.
This recipe just reported on a single performance counter. It would be straightforward to update your data-collection process to include more counters, which enables you to report on more performance information. You could include counters for networking, storage counters, and more. These other counters may help you to understand just why CPU utilization is high.
You could also make use of data collector output from the different hosts in your infrastructure. You could then adjust this recipe to report on these additional counter values from all different hosts. Knowing that overall performance load is high on Hyper-V Host HV1 but low on the host HV2 might suggest moving a VM or two between the hosts.