How to Collect and Download an HNAS Performance Information Report

Using an email address, the syntax is: 

$ pir -f <file_system_name> duration (in minutes) -r <your_email@domain.com> -s subject 

For example: 

$ pir -f fs1 -r <your_email@domain.com> -s PIRdata

This command gathers performance statistics from the server over a specified period and then sends the results out as a compressed folder attachment via email.  The above example will run for the default duration (~10 minutes), and it will focus on file system fs1, and the output is sent to your_email@domain.com with the subject header PIRdata.

Note:  If e-mail is unavailable, the PIR can be saved to the SMU using the "--to-ssc" option in the PIR command.

Using the --to-ssc command, the syntax is:

$ pir -f file_system_name duration (in minutes) --to-ssc -s subject 

For example:

$ pir -f fs1 --to-ssc -s PIRdata

After the PIR collection is complete, the PIR will be saved on the SMU, which you may retrieve by using SFTP to the SMU IP address.  See the man pages for "pir" for more details. The --to-ssc option puts it in the /home/manager directory on the SMU (use WinSCP) to download it.

Filesystem

If unable to determine which filesystem is causing the performance issue, the pir may run using the --no-file-system flag, but this is NOT recommended.  Instead, gather a PIR on what appears to be the busiest file system on the impacted node.  Please see this article on how to determine the most active file systems:

• How To: Determine Busy File Systems (HNAS)

If a particular storage pool appears to be impacted, try and run the PIR on the busiest file system in the storage pool.  We don't recommend using --no-file-system because it collects much less data than a PIR "focussed" on a file system and gives information aggregated for all the file systems on the node, which usually doesn't help narrow down where the problem is occurring.

In general, It is NOT recommended to use anything other than the default duration of 10 minutes. The reason is that only the last 10 minutes of the PIR contain high-resolution data.  There's no harm for a short problem from capturing more data, and there's little point in capturing more than the default collection period for a long-running problem.

Duration in Minutes of PIR

If you look at the man page for the performance-info-report command, which can be viewed on the HNAS CLI using:

man performance-info-report | less

You will see in the synopsis that it has an option:

[<duration-in-minutes>]

that allows the operator to specify a duration that the PIR "runs for."  The system can only record 10 minutes of high-resolution statistics, so if specifying a period of longer than 10 minutes, only the last 10 minutes of the PIR will have high-resolution statistics recorded.  As a result, this option is only useful to specify a PIR that runs for less than 10 minutes.

Another consideration for PIR duration is that performance problems usually occur during periods of peak behavior, not average behavior.  If you run a PIR for a long duration, the performance counters are averaged over that period, and therefore they tend to reflect the average behavior, not the peak behavior.  As a result, any peak behavior is much less distinct if not absorbed into the average and thus not apparent.

If you have an intermittent performance issue, then it is more beneficial to either schedule repeat PIRs to capture the problem or use the continuous PIR feature, as described in:

• What if my performance problem is intermittent?

Using the --all-pnodes option

If the performance problem cannot be traced to a single cluster node, use the --all-pnodes option, which requires a GSC-provided developer password.