Data Platforms and Performance - Part 6 Caché Storage IO Profile

Myself and the other Technology Architects often have to explain to customers and vendors Caché IO requirements and the way that Caché applications will use storage systems. The following tables are useful when explaining typical Caché IO profile and requirements for a transactional database application with customers and vendors.  The original tables were created by Mark Bolinsky.

In future posts I will be discussing more about storage IO so am also posting these tables now as a reference for those articles. 

A list of other posts in this series is here
 

It is vital to have well set up storage such as a storage array to provide predictable disk IO performance, support high availability features and provide storage redundancy, scalability, and reliability for your applications.

Caché Storage IO Profile

Depending on the storage array technology selected, disk storage at the physical layer may be separated into pools or disk groups. If possible for availability and performance storage should be partitioned based on the expected IO profile. For example data and journals (transaction logs) should be on separate physical disk groups because they have different IO profiles and also for availability as corruption in the data disk group can be recovered using the journals in a separate disk group isolated from the corruption.

Similarly backups should be in a separate disk group. There are many choices of storage configuration depending on operating system, storage vendor and array model. Exact requirements will be application specific with special attention required for physical and logical configuration including allocation of physical and logical groups or pools, RAID types, filesystem types and concurrency, GB space allocated, and so on.

The read and write IO profile of Caché is detailed in the following table:

Caché Storage IO Requirements

I find that bottlenecks in storage are one of the most common problems affecting database system performance. A common problem is sizing storage simply for GB capacity, rather than allocating a high enough number of discrete disks to support expected Input/Output Operations Per Second (IOPS). Although SSDs and tiered storage are now more common care must be taken to ensure IOPS are available.

To guarantee acceptable response times for end users a disk array with a minimum IO performance profile is required. The requirements vary slightly depending on whether separate Application (ECP) servers are used. The following table details the expected storage response times and notes on IO profile.  

Whats missing?

Before you talk to your vendor you will need to have estimates of the IOPS you expect your application to be driving so that the storage options can be configured to meet the requirements above. Part 1 and 2 of the series  show examples of how to collect metrics.