IBM TotalStorage DS6000 Series: Performance Monitoring and Tuning

134 IBM TotalStorage DS6000 Series: Performance Monitoring and Tuning

the characteristics of data on your DS6000 and without using a capacity planning tool like

Disk Magic. Refer to 4.1, “Disk Magic” on page 86.

We recommend that you monitor the read hit ratio over an extended period of time:

򐂰 If the cache hit ratio has been low historically, it is most likely due to the nature of your

data, and you do not have much control over this. You can first try to perform

de-fragmentation on a file system, making indexes if none exist, rather than considering

increasing the cache size.

򐂰 If you have a high cache hit ratio initially, and it is decreasing as you load more data with

the same characteristics, then moving some data to another cluster that uses the other

cluster’s cache or adding server enclosure could improve the situation.

4.3.7 Performance gauge - considerations

All averages appearing in the summary reports are values averaged over during the

performance collection interval. When setting the performance task, this frequency can be set

from 5 minutes to 60 minutes. We recommend that to drill down to detail reports, even though

the long frequency reports appear to be adequate. For example, we recommend collecting

performance data every 5 minutes and monitoring for 24 hours (therefore, taking 288 samples

a day), to see detailed performance and busiest time in a day.

4.3.8 IBM TotalStorage Productivity Center for Disk and other tools

The IBM TotalStorage Productivity Center for Disk provides storage subsystem metric

performance data. We receive, for example, the number of I/O requests the DS6000 has

processed at different levels, the cache usage and the persistent memory use conditions. We

cannot get the host system view from the Productivity Center for Disk reports, like I/O activity

rate, I/O response time, or data transfer rate. If there is a performance problem with your

applications, you could see a delay of batch jobs and slower response times during online

transaction processing.

To determine if the I/O behavior is the reason for the problem, you need to gather the

information about I/O profiles on the host systems. For example, it is possible that one

application cannot get I/O services, while another application dominates I/O services. The I/O

response time and its breakdown for each of the logical volumes helps you to isolate the

source of the performance problem.

The following sections describe how to use host-based performance measurements and

reporting tools, in conjunction with the IBM TotalStorage Productivity Center for Disk under

UNIX, Linux, Windows 2000, iSeries and z/OS environments.

IBM TotalStorage Productivity Center for Disk Report and UNIX / Linux

Most application I/O requests against disk subsystems are through either database

management systems or file systems. It can be difficult to associate the application or

operating system I/O performance with that of the I/O subsystems directly. Why? Because

they have their own internal caching mechanisms. An I/O request from an application does

not always go directly to the I/O subsystems. You may see an I/O subsystem experiencing

poor performance while applications are not affected.

To get host information about I/O subsystems, CPU activities, virtual memory, and physical

memory use, you can use the following commands:

򐂰 iostat

򐂰 vmstat

򐂰 sar