IBM TotalStorage DS6000 Series: Performance Monitoring and Tuning

78 IBM TotalStorage DS6000 Series: Performance Monitoring and Tuning

measurements show more than 200 MB/s per 2 Gbps FICON Express2 channel and an

aggregate of more than 380 MB/s for two channels.

I/O rates with 4 KB blocks are in the range of 35,000 I/Os per second or more with a single

DS6000 host port. A single FICON Express2 channel can actually perform up to about 9,000

read hit I/Os per second. Two FICON Express2 channels have the potential of over 13,000

I/Os per second with conservative numbers. These numbers will vary depending on the

server type used.

The ESS 750 has an aggregated bandwidth of about 500 MB/s for highly sequential reads

and about 350 MB/s for sequential writes. The DS6000 has achieved over 1000 MB/s with

64 KB data transfer reads and around 500 MB/s for sequential writes.

In a z/OS environment a typical transaction workload might perform on an ESS 800 Turbo II

with a large cache configuration slightly better than with a DS6000. This is the only example

where the ESS 800 outperforms the DS6000. In open systems environments, the DS6000

performs better than the ESS 750. This is also true for sequential throughput in z/OS

environments.

3.8 Logical disks - number and size

Generally, for easier administration and better overall performance, we recommend spreading

everything across everything

; meaning spread I/O across all Extent Pools, both DA adapter

pairs and two servers if possible. This will allow you to benefit from the aggregated throughput

provided by the full I/O processing capability of the DS6000. It is also important to remember

that each server has half of the cache, and its own Persistent Cache (formerly referred to as

Non Volatile Storage or NVS) area. Since all writes must go through Persistent Cache and

cache, you will want to balance I/O across both clusters.

The way to spread I/O is by assigning logical disks evenly to Extent Pools managed by each

server in the DS6000.

Sometimes though, you may want to dedicate an Extent Pool or several Extent Pools for a

given host server or application. The overall I/O performance in that case may not be as great

as spreading I/O evenly across all of the DS6000’s resources, but should still be predictable,

especially for the application (or host server) whose storage is isolated.

The DS6000 is very good at detecting I/O patterns. So if your environment does a lot of large

sequential file copying from A to B, you might want to split A-reads and B-writes to different

Extent Pools. Let the reads come from logical disks on one Extent Pool, and the writes go to a

separate set of Extent Pools.

The DS6000 is very good at detecting sequential I/O and adjusting I/O requirements

accordingly; however, avoiding large reads and writes to the same Extent Pools and the

underlying Ranks, will improve performance.

It is a challenge to select logical disk sizes in a manner that:

򐂰 Allows you to spread I/O across multiple Extent Pools.

򐂰 Does not proliferate the number of logical disk devices presented to a host.

򐂰 Allows enough granularity for performance monitoring but not that much so that analyzing

the performance data gets too complex. For example, the output from the AIX iostats

command can become overwhelming.

򐂰 Allows for growth and re-assignment of logical disks from one host to another when

working with open systems.