Skip to main content
Close
Hitachi Vantara Knowledge

Midrange Performance Data Collection - Overview

  1. Last updated
  2. Save as PDF

Midrange Performance Data Collection
AMS/WMS/HUS1xx

Please collect the following information for performance analysis by the Hitachi Global Support Center (GSC). If you need help, ask your local Hitachi Hardware Engineer (CE) and Hitachi Systems Engineer (SE). Collect all the information in the order shown. Ideally, you should collect all the data while the problem is occurring.

  1. Brief Description and Timeline of the Performance Problem
  2. Data Collection from Performance Monitor
  3. Simple Trace
  4. Time Difference Between Storage and Server(s)
  5. GetConfig from Affected Servers
  6. DLMgetras (if HDLM is used)
  7. Remote Copy Information (if applicable)
  8. OS Performance Information (useful)
  9. SAN Config Information (useful)

Once collected, upload the data collection to TUF.

Brief Description and Timeline of the Performance Problem

Description. This is very important. Please remember, we do not know your server naming conventions nor which servers are connected to which ports. Please answer all these questions:

  1. What are the concerns?
  2. What server(s) are affected (single or multiple)? (Include Host Names)
  3. What are the OS?
  4. If the OS is Windows, specify the LUN-to-Drive Letter relationship.
  5. Which Ports/Host Storage Domains/LUNs/Array Groups/LDEVs are having performance issues?
  6. What types of applications are affected?
  7. Is replication used - TC, TCED, COW, SI?
  8. Is this array externalized (used as external storage)?
  9. How is this problem affecting production?
  10. What type of array disk is being affected by this performance problem? (SAS, SATA, Fibre Channel, SSD)

Timeline. Sometimes performance is good at certain times of the day - and bad at other times. We need to know the exact times at which it was good - as well as the exact times at which it was bad. Please answer all these questions:

  1. Does the problem only occur at certain times or days of the week/month?
  2. At what time(s) does the problem start?
  3. At what time(s) does the problem go away? (or is it ongoing)?
  4. Detail the exact timeline of all events before, during and after the event

Please be as specific as possible.

Data Collection from Performance Monitor

You must supply the Performance Monitor data using the following procedures:

Performance Monitor is a standard feature of the AMS/WMS/HUS1xx. DF is not like RAID. With RAID Performance Monitor, you set it to collect data all the time, and then export what you want. With DF, you collect the data when you need it.

If data collection fails trying to collect data at 1 minute intervals, the DF subsystem may be under stress. If this happens, collect data at 5 minute intervals. For more details, see this topic.

Simple Trace

You must supply the following:

For AMS/WMS/HUS1xx, this is provided as an option on the Web GUI. The trace must be taken within 24 hours of the problem.

Ideally, you should collect the Simple Trace immediately after collecting the Performance Monitor data - see above.

Time Difference between Storage and Server(s)

Supply the following:

  • Time difference between the DF internal clock and that of the host with the performance problem. The DF time can be obtained from the SNM management utility or by using the Web GUI.

Unless the storage array is set to use Network Time Protocol (NTP), the internal clock is most likley not set to "server time".

GetConfig from Affected Server(s)

Supply a Getconfig for the server(s) in question:

  • Download and run the latest GetConfig for your server(s).

In many cases, the performance problem is due to bad server configuration, IO Queue Depth etc. We need the getconfig to see (a) how LUNs are allocated and (b) how the server has been setup for performance.

DLMgetras (if HDLM is used)

For UNIX, you do not need to run this as the GetConfig script runs this command if applicable.

For Windows, run this command only if HDLM is not installed in the default program location (C:\Program Files).

Remote Copy Information (if applicable)

When remote copy is being used, provide the data below:

  • Model and serial numbers of the Primary and Remote subsystems.
  • Synchronized, simple traces from the Primary and Remote subsystems taken while the performance problem is in progress.
  • Please detail exactly what was happening when the traces were taken. For example, was there large TC Initial Copy or Resync activity being performed?
  • The time difference between the clocks on the Primary and Remote subsystem.
  • Synchronized Performance Monitor data from both the Primary and Remote subsystem.
  • Diagram showing connectivity between the Primary and Remote subsystem including switches, port numbers, link and distance.

Other useful data

The list above is mandatory. In addition, the following items should also be supplied as soon as possible.

OS Performance Information

For UNIX hosts, we need:

  • iostat
  • vxstat (if VxVM is used)
  • 'sar -d' output at 15 sec interval for a couple of hours.
    • Note: preferred iostat option for Solaris is: iostat -xnzC -Td 15
    • z - Suppresses output for disks without I/O activity
    • C - Includes a line summarizing the I/O stats for each controller id

For Windows hosts, we need:

  • Windows Performance Monitor data output of all objects of Physical Disk. The recommended way to do this is to install Performance Wizard 1.1.3 to collect the Windows performance data. If you use this utility, select the default profile, which is called "Standard Perfmon".

SAN Configuration

For SAN Configuration Information, provide the following:

  • SAN diagram
  • Switch log output (if connection is through switches)