Reporting performance problems

Before you report a problem, you can collect information in advance to facilitate the problem investigation.

About this task

When you report a performance problem, it is not enough just to gather data and analyze it. Without knowing the nature of the performance problem, you might waste time and resources when you analyze data that might have nothing to do with the problem that is being reported.

Your local support personnel can use this information to help solve the performance problem with you. For information about opening a problem management record (PMR) and gathering information, see the following resources:

Procedure

To help get your problem resolved more quickly, complete the following tasks:

  1. Gather information about the performance issue to help you prepare a problem description:
    • For backup-archive client performance issues, run the client instrumentation and the server monitoring script simultaneously.
    • For server performance issues, run the server monitoring script.
    • Gather detailed information about LUN layout, cache size and setting information, disk system information, file systems type, RAID type, and other setup details. Because many performance issues are I/O related, this information is important.
    • Collect a list of the hardware information such as host bus adapter type, processor type, and amount of RAM you have on the client and server.
    • Gather network and SAN zoning information.
  2. Gather more information about your performance problem and your environment by completing the Tivoli Storage Manager performance questionnaire.
  3. Provide a statement of a simple specific instance of the problem. Separate the symptoms and facts from the theories, ideas, and your own conclusions. Problem Management Records that report the system is slow statements can require extensive investigation to determine what is meant by slow, how it is measured, and what is acceptable performance.
  4. Gather information about everything that changed on the system in the weeks before the problem. Missing something that changed can block a possible investigation path and might delay finding a resolution. If all the facts are available, IBM® Support can eliminate the unrelated facts.
    Tip: Be sure that you collect the information from the correct system. In large sites, it is easy to accidentally collect the data on the wrong system, which makes it difficult to investigate the problem.
  5. Provide the following information:
    • A problem description that can be used to search the problem-history database to see whether a similar problem was reported.
    • Describe the aspect of your analysis that led you to conclude that the problem is caused by a defect in the operating system.
    • Describe the hardware and software configuration in which the problem is occurring:
      • Is the problem confined to a single system, or does it affect multiple systems?
      • What are the models, memory sizes, and number and size of disks on the affected systems?
      • What kinds of LAN and other communications media are connected to the systems?
      • Does the overall configuration include other operating systems?
    • Describe the characteristics of the program or workload that is experiencing the problem.
      • Does an analysis with operating system tools indicate that it is processor-limited or I/O-limited?
      • What is the workload that is run on the affected systems?
    • Describe the performance objectives that are not being met.
      • Is the primary objective console or terminal response time, throughput, or real-time responsiveness?
      • Were the objectives derived from measurements on another system? If so, what was its configuration?
  6. If this report is the first report of the problem, you will receive a PMR number for use in identifying any additional data that you supply and for future reference. Include all of the following items when the supporting information and the performance data are gathered:
    • A means of reproducing the problem:
      • If possible, include a program or shell script that demonstrates the problem.
      • At a minimum, a detailed description of the conditions under which the problem occurs is needed.
    • The application that is experiencing the problem:
      • If the application is, or depends on, any software product, identify the exact version and release of that product.
      • If the source code of a user-written application cannot be released, document the exact set of compiler parameters that are used to create the executable program.