Although zHyperLink has been available for several years now, many mainframe sites have yet to implement the technology into their production environment. In this blog, we’ll review one site’s recent production implementation of zHyperLink for reads, for Db2. We will provide examples of reporting at the PCIe adapter, volume level and data set level which you may find helpful to analyze your own results.
Introduction to zHyperLink
Over the years, there have been many significant advances in I/O technology. Today, I/O is really, really fast. So how can we gain further improvement? One approach is to take a subset of I/Os for data that resides in close proximity to the processor, add a new higher-speed link, and make them synchronous in order to avoid interrupt processing and task switching. This is what zHyperLink does.
Figure 1 shows the physical connectivity between the CPC and the Storage Control Unit.
zHyperLink provides a short distance direct connection of up to 150 meters. I/Os are synchronous, eliminating the overhead of z/OS dispatcher delays, I/O interrupt processing and processor cache reload. Latency improvements up to 4.5 times are possible with current hardware (z15s and DS8950Fs in this example). Think of 20 microsecond I/O times, as we’ll see below.
There is a CPU time price to be paid, since the I/Os are synchronous and the processor waits for them to complete. And there are limitations on which data sets and I/Os are eligible. However, the benefits outweigh the costs for most customers. If you need assistance analyzing your workloads for zHyperLink candidates and assessing the anticipated impacts, please contact us at IntelliMagic.
zHyperLink Connectivity Best Practices
Let’s look at data from a site who recently implemented zHyperLink and review the kinds of reports you can produce for your own analysis.
We’ll begin by verifying that our configuration adheres to best practices for connectivity. Figure 2 below shows a single LPAR and a single DS8950F subsystem. We see there are two Physical Channel IDs for PCIe, each with four PCIe Function IDs.
Per best practices, you should be configured this way throughout your environment – 4 PFIDs per LPAR per zHyperLink connection (CEC, adapter ID, port #). We can also see the even distribution of I/O across PFIDs and ports. Including your other LPARs would also allow you to identify the busier LPARs.
Profile zHyperLink Usage and Performance
Now let’s look at our mix of zHyperLink and FICON I/O to start to profile our usage and performance.
Total I/O Rate
Figure 3 shows I/O rates over the course of a single day, from midnight to midnight.
Most of the I/Os are native FICON as usual, but you now also see spikes of successful synchronous reads and some synchronous read cache misses. Note that only synchronous reads are currently enabled in this data, so no writes are shown.
Figure 4 examines the synchronous I/O without the native FICON, for easier visibility into patterns.
We see there are three main spikes of activity, at 0100, 0700 and 1600, with more than 10,000 synchronous I/Os at peak. We also see the read cache misses are a small percentage of the synchronous I/Os and follow the peaks, as you might expect. Read cache misses are re-driven as native FICON I/O which incurs overhead, so you’ll want to keep an eye on misses going forward.
Figure 5 compares latency to I/O rate for the synchronous read requests.
The top red line shows latency, or response times, varying from 16-22 microseconds (way fast!) over the course of the day. The blue line of three peaks should look familiar by now, as the request rate. Note that as the request rate goes up, the response time comes down and is consistently under 20 microseconds.
Synchronous Read Hits
We can also report synchronous hits and misses by data set name. Figure 6 shows a daily summary by data set name, but you could display any of these over time as well.
This site turned on synchronous read processing for Db2, so we’re looking at the hit percentage for production Db2 data sets.
Time Pattern for Synchronous Requests
With any new implementation, it can be helpful to understand the time patterns that apply to the workload involved. Figure 7 shows that the single day we’ve been looking at is typical.
This Db2 workload drives most of its synchronous I/O in the 0100-0300 hours consistently, with little change by day of the week.
Data Set Level Performance
Another way to look at data set level performance is shown in Figure 8.
Figure 8 shows the top 30 linear data sets with ‘DBP1’ in their name, with response times and time of day when they were accessed. Reports like this, along with the related reporting in IntelliMagic Vision, provides a strong capability to profile your workload and understand technology benefits or diagnose problems or changes.
Demonstrating the Benefit of Improved Technology
zHyperLink utilizes improved technology including the PCIe bus and synchronous I/O to significantly improve latency for applications. This improvement can be shown explicitly from the RMF/SMF data and is key to justifying new technologies and new projects.
IntelliMagic Vision gives you an easy and comprehensive way to verify the benefit, not just for zHyperLink but for the many enhancements your teams implement each year.
You May Also Be Interested In:
Where Are All The Performance Analysts? - A Mainframe Roundtable | IntelliMagic zAcademy
We have brought together industry experts from across the board to discuss the importance of having an efficient team managing the performance of their business applications.
How A Db2 Newbie Quickly Spotlights the Root Cause of a Db2 Slowdown
This blog explores how a non-Db2 expert quickly identified latch contention arising from a Data Sharing Index Split as the root cause of a Db2 delay/slowdown.
Integrating Dataset Performance (SMF 42.6) and Db2 Buffer Pools & Databases (SMF 102/IFCID 199) Data
Dataset performance data from SMF 42.6 records provides disk cache and response time data at the Db2 buffer pool and Db2 database levels when integrated with Db2 Statistics IFCID 199 data.