ibm system z ds8000 i/o priority manager · is vsam file access and serialization is controlled by...

February 2012

IBM System z DS8000 I/O Priority Manager Azeem Mohammed [email protected] Stefan Wirag [email protected]

IBM System z: DS8000 I/O Priority Manager Page 1

Table of Contents 1: A High-Level Description of I/O Priority Manager: ....................................................................2 2: Our Parallel Sysplex Environment: ...........................................................................................3 3: DS8000 and Workloads Setup:.................................................................................................3

3.1: ATM transaction workload .................................................................................................4

3.2: Middleware OLTP workloads.............................................................................................4

3.3: IMS data sharing workloads: ..............................................................................................4

3.4: CICS VSAM/RLS data sharing workload:...........................................................................5

3.5: CICS VSAM/NRLS workload: .............................................................................................5

3.6: DB2 data sharing workloads:..............................................................................................5

3.7: DB2 Large Storage Utilization Workload: ...........................................................................5 4: Running Workloads and I/O Priority Manager: .........................................................................6 5: Test Results: .............................................................................................................................7 6: Conclusion: .............................................................................................................................22


1: A High-Level Description of I/O Priority Manager: IBM System z® has high perceived value due to its capability of running many diverse workloads and allowing expensive resources to be shared among consumers in the hopes of benefiting all. System z connected to DS8000® storage unit provides high performance and scalability but sometimes optimal performance cannot be achieved due to number of reasons such as badly configured disk or overly committed z/OS® system. The disk storage subsystems and z/OS have created many synergy items to simplify the configuration of I/O resources and to address backend I/O performance degradation. I/O priority manager is a new function which can help enable greater cache efficiency and improve performance for higher priority workloads residing on DS8000. I/O priority manager provides Quality of Service (QoS) in a DS8000 storage server. It accomplishes this by allowing high priority work preferred access to storage server resources. Lower priority work may be constrained from accessing some resources like caches or disks. This is implemented by delaying the low priority work with a throttle. The high priority work is preferred because it does not get throttled and it utilizes the resources that the throttled work is freeing up.

In a system z environment, I/O priority manager collaborates with the z/OS Workload Manager (WLM) to handle specified performance requirements and to achieve the desired QoS. z/OS WLM passes service class importance and goal information to the storage I/O priority manager in IBM Storage DS8000 series. The information enables the storage I/O priority manager to provide favored processing for I/O requests of important workloads that are not achieving their goals.

The storage I/O priority manager analyzes the properties of the service class period associated with an I/O request and determines whether the I/O request should be favored, or throttled.

For service class periods with a response time goal, the goal achievement and specified importance are analyzed. Service class periods that exceed their goal may be throttled if there are service class periods that do not achieve their goal. Service class periods that miss their goal might only be throttled if there are service class periods with a higher importance that do not achieve their goal.

For service class periods with a velocity goal, the specified velocity goal and importance are taken into account. Service class periods with a high importance (1 or 2) and a high velocity goal will most likely be favored. Service class periods with a low importance and a low velocity goal might be throttled.


I/O requests associated with the system-provided service classes SYSTEM, SYSSTC, or SYSSTC1 - SYSSTC5 are not managed by the I/O priority manager. These I/O requests are handled at the same priority as favored I/Os, and may benefit from IO priority manager decisions made for other favored work. I/O requests associated with service class periods that have a discretionary goal may be throttled, but will never be favored.

2: Our Parallel Sysplex Environment: We run a Parallel Sysplex® with nine production members consisting of the following:

Five central processor complexes (CPCs) running z/OS V1R13 in nine logical partitions (LPARs).

The CPCs consist of the following machine types:

One IBM zEnterprise™ 196 (z196) CPC Two IBM zEnterprise 114 (z114) CPCs One IBM System z10® Enterprise Class (z10 EC™) CPC One IBM System z9® Enterprise Class (z9® EC) CPC

Four coupling facilities (CFs):

One failure-independent coupling facility that runs in a LPAR on a standalone CPC

Three non-failure-independent coupling facilities that run in LPARs on three of the CPCs that host other z/OS images in the sysplex

Other I/O devices, including FICON®-attached DASD and tape drives

3: DS8000 and Workloads Setup: This feature is supported on IBM System Storage® DS8700 and DS8800 series, and requires a DS8000 licensed machine code as follows:

IBM System Storage DS8700 - level 7.6.2.xx.xx (bundle version 76.20.xxx.xx)

IBM System Storage DS8800 - level 7.6.2.xx.xx (bundle version 86.20.xxx.xx)

We used a DS8800 controller for our test and ensured that we have applied the activation code properly for this feature. Support for the I/O priority manager was enabled via WLM APAR (OA32298) on z/OS. We configured 24 ranks and 8 logical control units (LCUs) on DS8800 storage controller. We moved our customer modeled workloads that have different service classes assigned to this DS8800. Our DB2® subsystem is assigned to a service class (e.g. STCI2V50) with importance 2 and Velocity 50 goal, the CICS® subsystem is assigned to a service class (e.g. STCI2V60) with Importance 2 and Velocity 60 goal, and all the CICS transactions are assigned to service classes (e.g. CI250%3S, CI290%P5 and CI390%01) with


Importance values ranging from 2-3 and response time goal values ranging from 50 - 90% of transactions completing within 0.6 to 3 sec. The IMS™ subsystem is using a service class (e.g. STCI2V50) with Importance 2 and velocity 50 goal as well. All the IMS transactions are using service classes (e.g. II290%P5, II390%P7) with Importance values ranging from 2-3 and response time goal values of 90% of transactions completing within 0.7 to 1 sec. We also had some batch work running under the service classes (e.g. BATI4V10, STCI2V40) with importance values ranging from 2-4 and velocity values from 10 to 40

The following workloads were used for the purpose of this test:

3.1: ATM transaction workload

ATM transaction workload is a banking application to simulate ATM transactions in a Parallel Sysplex environment. This application uses CICS, IMS, and DB2 and runs in a four-way IMS and DB2 data sharing environment.

3.2: Middleware OLTP workloads

We have 3 application groups run different OLTP workloads using CICS or IMS as the transaction manager:

Application group 1 — IMS data sharing, including IMS shared message queue

Application group 2 — VSAM in record level sharing (RLS), local shared resource (LSR), and non- shared resource (NSR) modes

Application group 3 — DB2 data sharing (four different OLTP workloads, a well as several batch workloads)

3.3: IMS data sharing workloads:

In application group one, we run the following IMS data sharing workloads:

IMS EMHQ Fast Path

Full function, Fast Path, and mixed mode transactions. Integrity checking on INSERT calls using SDEP journaling

A batch message processing (BMP) application to do integrity checking on REPLACE calls.


3.4: CICS VSAM/RLS data sharing workload:

In application group 2, we run two OLTP VSAM/RLS data sharing workloads. These workloads run transactions that simulate a banking application (ATM and teller transactions), hotel reservation application, inventory tracking, order entry, and stock control transactions. Some of the transactions are similar to the IMS data sharing workload that runs in application group 1, except that these transactions access VSAM files in RLS mode and use DFSMS™ (SMSVSAM) as the lock manager.

3.5: CICS VSAM/NRLS workload:

Also in application group 2, we run additional workloads. One workload uses transactions similar to our VSAM/RLS workloads, but the VSAM files are accessed in non-RLS mode. That is VSAM file access and serialization is controlled by CICS File Owning Regions (FORs) instead of DFSMS. Another workload is an I/O-intensive workload that simulates a financial brokerage application.

3.6: DB2 data sharing workloads:

In application group 3, we run four different DB2 data sharing OLTP workloads. These workloads are also similar to the IMS data sharing workload running in application group 1.

In the first of the DB2 workloads, we execute 8 different types of transactions in a CICS/DB2 environment. This workload uses databases with simple and partitioned table spaces. In the second of our DB2 workloads, we use the same CICS regions and the same DB2 data sharing members. However, we use different transactions and different databases. The table space layout is also different for the databases used by the second DB2 workload—it has partitioned table spaces, segmented table spaces, simple table spaces, and partitioned indexes. Our third workload is a derivative of the second, but incorporates large objects (LOBs), triggers, user defined functions (UDFs), identity columns, and global temporary tables. The fourth workload uses IMS/TM executing 12 different transaction types accessing DB2 tables with LOBs. It also exercises UDFs, stored procedures and global temporary tables.

3.7: DB2 Large Storage Utilization Workload:

The DB2 LSU workload is a high I/O intensive tool designed to test large amounts of storage utilization on a z/OS DB2 subsystem which creates, inserts, selects and destroys table spaces.


4: Running Workloads and I/O Priority Manager: We performed our tests in a z/OS V1R13 environment. I/O priority manager support is controlled by a new parameter for PARMLIB members IEAOPTxx, called STORAGESERVERMGT. That parameter can take two possible values such as STORAGESERVERMGT=NO or STORAGESERVERMGT=YES. When we specify STORAGESERVERMGT=NO (default), I/O priority manager will be in monitoring mode only. When we specify STORAGESERVERMGT=YES, I/O priority manager will be in throttling mode. I/O priority support can be enabled/disabled dynamically by issuing MVS™ SET OPT=XX command on the console. The primary control was turned on or off via the DSCLI (DS8000 Command Line Interface) or the DSGUI (DS8000 Graphical User Interface) on DS8000. There is no monitoring tool available on z/OS to monitor I/O priority activity so we enabled SMF 99, 30 and 70-78 records to analyze the data. We ran our workloads for 60 minutes. I/O priority manager was run in monitoring mode (i.e. no I/O throttling) during the first 30 minutes and in the throttling mode, (i.e. with I/O throttling) during the second 30 minutes. We verified that when we ran I/O priority manager in throttling mode it actually resolved poor response time and improved the performance of our critical application residing on DS8800.


5: Test Results: During our tests we observed the following behavior while running I/O priority manager in monitoring mode (first 30 minutes) and then in throttling mode (last 30 minutes).

Figure 1 shows the average Performance Index (PI) of response time service classes on the different importance levels. Furthermore, a 10 min rolling average of the PI is shown to make the changes in monitoring mode and throttling mode more obvious.

Figure 1. Average Performance Index (PI) of Service Classes with Response Time Goal

We observed that the average PI of high important service classes missing their goal is improved as well as the PI of low important service classes meeting their goal. The PI of Importance 1 service classes improved by 10%; from 4.0 in monitoring mode to 3.6 in throttling mode. The PI of Importance 2 service classes improved by 22%; from 2.3 in monitoring mode to 1.8 in throttling mode. The PI of Importance 3 service classes improved by 23%; from 0.9 in monitoring mode to 0.7 in throttling mode. The Importance 1 service classes benefitted less from throttling mode than the Importance 2 and 3 service classes, because the Importance 1 service classes emitted fewer I/O requests.


These lower PI values reflect improvements in end-to-end transaction response times. Those transactions depend not only on storage performance but also on processing and on communications delays, which are not expected to change between monitoring and throttling modes. Nonetheless, improvements in storage response times were sufficient to cause significant improvements in transaction response times.

Figure 2 shows the average PI of velocity service classes on the different importance levels. Furthermore, a 10 min rolling average of the PI is shown to make the changes in monitoring mode and throttling mode more obvious.

Figure 2. Average Performance Index (PI) of Service Classes with Velocity Goal

We had only Importance 2 velocity workloads and observed that the average PI of these service classes became slightly worse. The average PI increased by 4%; from 1.25 in monitoring mode to 1.3 in throttling mode.


Figure 3 shows the I/O velocity of service classes with response time goal. The I/O velocity is the ratio of I/O Connect Time and I/O Connect Time + IOS Queue Time + Pending Time + Control Unit Queue Time + Disconnect Time. The I/O velocity describes the ratio of doing I/O versus waiting for I/O.

Figure 3. I/O Velocity of Service Classes with Response Time Goal

Figure 3 shows that the I/O velocity of response time service classes with importance 3 improved by 12%; from 0.28 in monitoring mode to 0.32 in throttling mode. The I/O velocity of service classes with importance 2 improved by 6%; from 0.19 in monitoring mode to 0.2 in throttling mode. This means the importance 3 service classes benefited slightly more than the importance 2 service classes from throttling mode.


Figure 4 shows the I/O velocity of service classes with velocity goal. The I/O velocity of service classes with importance 2 decreased by 36%; from 0.63 in monitoring mode to 0.4 in throttling mode. This means service classes with velocity goal were disadvantaged in throttling mode. The reason was that some of these service classes were throttled to help response time service classes which were missing their goal.

Figure 4. I/O Velocity of Service Classes with Velocity Goal

There were several response time service classes which did overfulfill their specified goal: II290%P5, II390%P7. There were several response time service classes which did not meet the specified performance goal: WI180%01, CI250%3S, CI290%P5, CI390%01. There were velocity service classes which met their goal: STCI2V40, STCI2V60. There were velocity service classes which missed their goal: STCI2V50. There were velocity service classes that over fulfilled their goal: BATI4V10.

First, let us take a closer look at the service classes with response time goals.

Service classes II290%P5 (Importance 2) and II390%P7 (Importance 3) were not impacted by throttling mode. Their I/O velocity and the PI did not change noticeably.


Service class WI180%01 (Importance 1) did not do much I/O but could still benefit from throttling mode. The PI improved from 4.0 in monitoring mode to 3.6 in throttling mode as Figure 5 shows.

Figure 5. Performance Index (PI) of Service Class WI180%01


Figure 6 shows the average response time for service class WI180%01. When throttling mode was turned on the average response time was reduced slightly.

Figure 6. Average Response Time of Service Class WI180%01

Service class CI250%3S ran CICS transactions and had one period with an importance of 2 and an average response time goal of 100 ms. Figure 7 shows the performance index of this service class. In average the performance index increased continually in monitoring mode. When throttling mode was turned on, the performance index decreased from 3.8 to 3.3.


Figure 7. Performance Index (PI) of Service Class CI250%3S


Figure 8 shows the I/O velocity of service class CI250%3S. In monitoring mode the I/O velocity was in average 0.43. In monitoring mode it increased to an average of 0.46. This means the service class was delayed less with regard to I/O.

Figure 8. I/O Velocity of Service Class CI250%3S


Figure 9 shows the achieved response time and the response time goal of Service Class CI250%3S. The achieved response time increased in monitoring mode from 340 ms up to 400 ms, and when throttling mode was turned on it decreased to 330 ms.

Figure 9. Response Time of Service Class CI250%3S

Service class CI290%P5 also ran CICS transactions and had one period with an importance of 2 and a percentile response time goal of 90% in 500 ms. Figure 10 shows the performance index of this service class. When throttling mode was turned on, the performance index decreased from 4.3 to 3.0.


Figure 10. Performance Index (PI) of Service Class CI290%P5


Figure 11 shows the achieved response time and the response time goal of Service Class CI290%P5. The average achieved response time in monitoring mode was 800 ms. When throttling mode was turned on the average response time decreased to 570 ms.

Figure 11. Average Response Time of Service Class CI290%P5


Figure 12 shows the PI for service class CI390%01 which had importance 3. Some I/O requests of this service class were throttled to help the other CICS service classes which were missing their goal. However, the PI of this service class still improved from 1.4 in monitoring mode to 1.0 in throttling mode.

Figure 12. Performance Index of Service Class CI390%01


Figure 13 shows the average response time for service class CI390%01. The average response time decreased from 370 ms in monitoring mode to 320 ms in throttling mode.

Figure 13. Average Response Time of Service Class CI390%01

Let us take a look at the service classes with execution velocity goal.

The velocity service classes STCI2V50 and STCI2V60 could benefit little from throttling mode. Their PI did not change. Their I/O velocity improved continuously during the test run independent of monitoring or throttling mode.


Service class STCI2V40 which had importance 2 and an execution velocity goal of 40 was throttled to help the CICS service class which was missing its goal. Figure 14 shows the Performance Index of this service class. The Performance Index of this service class stayed in the same range in monitoring mode and in throttling mode.

Figure 14. Performance Index (PI) of Service Class STCI2V40


Figure 15 shows the I/O velocity of service class STCI2V40. Due to the throttling, the I/O velocity decreased from 0.63 in monitoring mode to 0.27 in throttling mode.

Figure 15. I/O Velocity of Service Class STCI2V40


Service class BATI4V10 became active at 11:17 and was immediately throttled to help the CICS service classes not fulfilling their goals due to its low importance and low velocity goal. However, the PI of this service class was 0.5, i.e. still very good.

6: Conclusion: The test results have shown that I/O priority manager can effectively manage quality of service levels for each application running on DS8000 thus efficient performance can be achieved. I/O priority manager constantly monitors system resources and requires minimal supervision from the storage administrator. In our environment, I/O priority manager relieved I/O contention and prioritized more important I/O streams to help meet our performance goals. With this cost effective solution our one storage system can now serve many categories of workloads with different characteristics and requirements.

Subject Identifier

®Copyright IBM Corporation 2012

IBM Systems and Technology Group Route 100 Somers, New York 10589 U.S.A. Produced in the United States of America, 02/2012 IBM, IBM logo, CICS, DB2, DS8000, DFSMS, FICON, IMS, MVS, Parallel Sysplex, System Storage, System z, System z9, System z10, z9, z10 EC, zEnterprise, and z/OS are trademarks or registered trademarks of the International Business Machines Corporation. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. All statements regarding IBM’s future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Performance is in Internal Throughput Rate (ITR) ratio based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput improvements equivalent to the performance ratios stated here.

ZSW03219-USEN-00

ibm system z ds8000 i/o priority manager · is vsam file access and serialization is controlled by...

Documents