· Jun 17, 2016 2m read

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.

Discussion (7)3
Log in or sign up to continue

Hi, mirroring will not make much difference. Without ECP you may see 10's of writes per second on the database server journal disk (eg primary mirror). With ECP you will see perhaps 1000's of small writes per second on the data server (eg primary mirror) from journal synch activity, which is why you need such tight response time on journal disk when using ECP. My next posts will be about ECP and will cover this in more detail. 

Right now I am on leave in Bali with only occasional Internet access until late July, so look for  post early August.

Thank you Murray for these performance articles, they provide a good summary that relates to most of the performance issues that I've encountered.  I wanted to link the following documentation about the implementation of filesystem caching in certain scenarios:


I understand that implementing caching for certain types of files that Caché utilizes (such as CACHE.DATs) can lead to performance problems or worse.  This just seemed like a related topic to me that was worth a mention.