opinion: Yep, DASD Performance is Still Important

I remember the last time I had to do any DASD tuning. CA Datacom database performance wasn't great, and the database team believed it was a DASD problem. So I went and systematically looked at their disk volumes.

First step was the SMF74 records. These give performance statistics for every disk volume, and break it down into categories - broadly:

• Connect time - the time to transfer the data
• Disconnect time - time waiting once the data was transferred (usually cache or disk mirroring)
• Pending time - the time waiting for hardware (usually channel or path wait times)
• IOSQ - the time waiting for a UCB

In the end I found the disk service time was all IOSQ. In those days, there was no PAVs, so we needed to reduce the I/O to the volume. This could be done with better database buffering, or by splitting the high-used databases over multiple volumes.

OK, I've gone into some detail here. But the interesting thing is that this was in 2000 - 16 years ago. As I've followed DASD improvements, I've seen DASD performance improve, and service times reduce. Those IOSQ problems are now gone with PAV (Parallel Access Devices). Caching improvements have reduced disconnect time, and the latest FICON reduces pending and connect times.

The bottom line is that I came to the conclusion that DASD performance wasn't important to me as a consultant. I was wrong.

I've been recently working on a tuning project that has shown how wrong I was. This is a high-write activity application - lots of DB2 and VSAM writes. This also means lots of CICS journal and DB2 log writes to disk. It also does a lot of Websphere MQ persistent message processing, so lots of MQ log writes. This application is synchronously mirrored (PPRC) - which slows down the service times. What we've found is that slow-down is having a very big impact on the application performance. A comparison of performance with and without disk mirroring has shown a major difference.

When I started the project, I took a quick look at DASD performance, and saw service times of around 3 milliseconds. Sounded good to me. But the reality is that this figure is putting major pressure on the application. So we've needed to find ways at the application level to work with a 3 millisecond response time. Wouldn't be needed if the disks weren't mirrored.

We also have seen some disks that are really being hammered - around 75% usage rates. So they're not going to be able to take much more I/O - another potential performance issue. So all of this has brought home the simple fact that DASD performance is still important.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.