Reducing storage occupancy with IBM zEnterprise Data Compression (zEDC) on IBM MQ for z/OS

 View Only

Reducing storage occupancy with IBM zEnterprise Data Compression (zEDC) on IBM MQ for z/OS 

Thu November 07, 2019 01:18 PM

Reducing storage occupancy with IBM zEnterprise Data Compression (zEDC) on IBM MQ for z/OS

tonySharkey |Sep 14 2016 Updated

Can I use zEDC with MQ data sets?

Sequential files allocated by using basic sequential access method (BSAM) or queued sequential access method (QSAM) can be compressed using the IBM zEnterprise Data Compression Express (zEDC Express) feature enabled.

 

In an MQ subsystem, this means that archive data sets are eligible for compression.

 

What benefits might I see?

There are a number of benefits which using zEDC to compress MQ archive logs may bring:

 

Reduced storage occupancy of archive volumes, meaning more archives can be stored on the same number of 3390 volumes. The compressibility of the messages logged will be the largest factor in the archive data set size reduction.

 

Reduced load on the IO subsystem, which in a constrained subsystem could improve response rates on other volumes.

In our tests with dual logs and dual archives where the I/O subsystems’ cache was seeing increased disk fast write bypass (DFWBP) on the control unit used by both log copy 2 and the archive volumes, enabling archive log compression resulted in the response times from the I/O to log copy 2 reducing, with DFWBP becoming 0, which manifested in a 45% improvement in peak throughput with large messages.

 

What impact might I see?

The process of compressing, or indeed attempting to compress the MQ archive logs will result in an increase in queue manager TCB costs. For a queue manager running a dedicated persistent workload with the intent to drive the MQ log process to its limit for a range of message sizes, we observed the queue manager TCB cost increase for the zEDC enabled measurements:

 

Message Size

4KB

32KB

1MB

4MB

Increase in QM TCB over non-zEDC measurement

+7%

+26%

+90%

+100%

Increase in peak throughput

1%

2%

30%

45%

 

Note that some of the increase in queue manager TCB is associated with the increased log capacity rate, but there is some additional cost on MVS from the allocation / releasing of the target compression buffer plus some costs in setting up the call to the zEDC hardware.

 

Reading the MQ archives data sets, such as when the ‘RECOVER CFSTRUCT’ command was issued, was impacted when the archives were compressed using zEDC. This impact took the form of both a reduced read rate coupled with an increase in queue manager TCB costs for decompressing the data.

 

The following table summarizes the results of a ‘RECOVER CFSTRUCT’ command resulting in the recovery of 4GB of data:

 

 

Uncompressed Archives

 Archives compressed using zEDC

Recovery Rate (MB/sec)

88

27

Cost per MB (CPU ms)

860

1900

 

The numbers in the table are based upon a MQ V9 queue manager with 4GB of data stored on shared queues with data offloaded to SMDS. For the purposes of the backup and recovery tests, the queue manager is configured with single logs and single archives. The data on the queues is highly compressible. The costs are based on the measurements running on a z13 (2964-703).

 

When MQ is writing archive logs at a high rate, the RMF PCIE report indicated that the single configured zEDC processor for the logical partition was running up to 65% utilized when compressing the dual archive logs for a single MQ queue manager. This peak usage occurred when the message was incompressible. With highly compressible messages at the peak rate, the zEDC processor was 50% utilized.

The PCIe I/O drawer that the zEDC Express feature can be installed can support up to 8 features with each feature able to be shared across 16 logical partitions. Sufficient zEDC features should be available to avoid impacting other users of the feature.

 

How we set up for testing:

For the initial configuration we used Redbook ‘Reduce Storage Occupancy and Increase Operations Efficiency with IBM zEnterprise Data Compression’  which can be found at: http://www.redbooks.ibm.com/redbooks/pdfs/sg248259.pdf

Within this document sections 4.2 to 4.5 were of particular interest as they discuss DB2 log archive data sets.

 

For our testing purposes we already had a storage group for the MQ archive data sets, so we defined a dataclass of ZEDC, specifying ZR (zEDC required) for compaction, and the data set name type of EXTENDED.

We also defined a storage group MQZEDC that was based on the existing MQMARCH storage group and added a similar number of volumes to the group.

 

Note, that the zEDC feature was already enabled on the test system.

 

Gotchas:

The initial set up did not specify a value of EXTENDED for the data set name type – as a result measurements showed similar size archive and log data sets – indicating either the data was incompressible or the no compression was attempted.

Subsequent review of the PCIE XML report produced by program ERBRMFPP indicated the zEDC processor was not being used.

 

The PCIE report can be generated by specifying ‘REPORTS(PCIE)’ and viewing the contents of the XRPTS DD card, which contains data generated in XML format.

 

Where else might zEDC benefit MQ?

zEDC offers a number of compression benefits that can benefit MQ:

-  Channel compression using ZLIBFAST. The performance benefits are discussed in performance report (MP1J), found at: http://www-01.ibm.com/support/docview.wss?uid=swg24038347

-  SMF Log stream data compression. The capacity planning and tuning guide of IBM MQ for z/OS (MP16), found at: https://ibm-messaging.github.io/mqperf/mp16.pdf



 

Entry Details

Statistics
0 Favorited
5 Views
1 Files
0 Shares
1 Downloads
Attachment(s)
docx file
OS.docx   17 KB   1 version
Uploaded - Thu November 07, 2019

Tags and Keywords

Related Entries and Links

No Related Resource entered.