IBM DS8000 - Manual (Page 287)

Chapter 12. Performance considerations 265
12.4.1 Workload characteristics
The answers to questions like how many host connections do I need?, how much cache do I
need? and the like always depend on the workload requirements (such as, how many I/Os per
second per server, I/Os per second per gigabyte of storage, and so forth).
The information you need, ideally, to conduct detailed modeling includes:
Number of I/Os per second
I/O density
Megabytes per second
Relative percentage of reads and writes
Random or sequential access characteristics
Cache hit ratio
12.4.2 Cache size considerations for open systems
Cache sizes in the DS8000 can be either 16, 32, 64, 128, or 256 GB. The 16 GB of system
memory is only available on the DS8100 and the 256 GB of system memory is only available
on the DS8300.
The factors that have to be considered to determine the proper cache size are:
The total amount of disk capacity that the DS8000 will hold
The characteristic access density (I/Os per GB) for the stored data
The characteristics of the I/O workload (cache friendly, unfriendly, standard; block size;
random or sequential; read/write ratio; I/O rate)
If you do not have detailed information regarding the access density and the I/O operations
characteristics, but you only know the usable capacity, you can estimate between 2 GB and
4 GB for the size of the cache per 1 TB of storage, as a general rule of thumb.
12.4.3 Data placement in the DS8000
Once you have determined the disk subsystem throughput, the disk space and number of
disks required by your different hosts and applications, you have to make a decision regarding
the data placement.
As is common for data placement and to optimize the DS8000 resources utilization, you
should:
Equally spread the LUNs across the DS8000 servers.
Spreading the LUNs equally on rank group 0 and 1 will balance the load across the
DS8000 servers.
Use as many disks as possible.
Distribute across DA pairs and RIO-G loops.
Stripe your logical volume across several ranks.
Consider placing specific database objects (such as logs) on different ranks.