13,600 I/Os per second with the conservative numbers. These numbers vary depending on the server type used.
The ESS 800 has an aggregated bandwidth of about 500 MB/sec for highly sequential reads and about 350 MB/sec for sequential writes. The DS6800 can achieve higher data rates than an ESS 800.
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 DS6800. This is the only example where the ESS 800 outperforms the DS6800. In all open systems environments, the DS6800 performs better than the ESS 800. This is also true for sequential throughput in z/OS environments.
11.5.3 An appropriate DS6000 size in z/OS environments
The potential of the architecture, its implementation and utilized technology allow for some projections at this point (though without having the hard figures at hand). Rules of thumb have the potential to be proven wrong. Therefore you see here some recommendations on sizing which are rather conservative.
A fully configured ESS 800 Turbo with CKD volumes only and 16 FICON channels is good for the following:
Over 30,000 I/Os per second
More than 500 MB/sec aggregated sequential read throughput
About 350 MB/sec sequential write throughput in mirrored cache
Without discrete DS6000 benchmark figures, a sizing approach to follow could be to propose how many ESS 800s might be consolidated into a DS6000 model. From that you can derive the number of ESS 750s, ESS F20s, and ESS E20s which can collapse into a DS6000. The older ESS models have a known relationship to the ESS 800.
Further considerations are, for example, the connection technology used, like FICON or FICON Express channels, and the number of channels.
Generally speaking, a properly configured DS6000 has the potential to provide the same or better numbers than an ESS 800, except for transaction workloads with a large cache in the ESS. Since the ESS 800 has the performance capabilities of two ESS F20s, a properly configured DS6000 can replace two ESS F20s.
Processor memory size considerations for z/OS environments
Processor memory or cache in the DS6000 contributes to very high I/O rates and helps to minimize I/O response time.
It is not just the pure cache size which accounts for good performance figures. Economical use of cache and smart, adaptive caching algorithms are just as important to guarantee outstanding performance. This is implemented in the DS6000 series, except for the cache segment size, which is currently 68 KB.
Processor memory is subdivided into a data in cache portion, which holds data in volatile memory, and a persistent part of the memory, which functions as NVS to hold DASD fast write (DFW) data until staged to disk.
The IBM Tucson performance evaluation lab suggests a certain ratio between cache size to backstore capacity. In general, the recommendation is:
0.5% cache to backstore ratio for z/OS high performance
Chapter 11. Performance considerations | 235 |
