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
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.

Get IBM TotalStorage DS6000 Series: Performance Monitoring and Tuning now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.