IBM z13 Performance : The Benefits of Large Memory

0 Posted by - February 17, 2015 - Blog

IBM z Systems hardware has been growing the amount of memory provided with its processors over the years.  That’s why the IBM z13 (z13) will be capable of configuring up to 10 TB.  The z Systems software has also been enhanced to be better able to take advantage of more memory for improved performance.  These improvements, coupled with the enhanced memory pricing available on the z13 hardware can make for a very attractive offering.   

Significant performance benefits can be experienced by keeping data in memory and eliminating database I/O operations.  This was clearly demonstrated in recent internal z Systems measurements in which DB2® buffer pools and associated memory were scaled up: a single system and data sharing online banking transaction workload; and a single system traditional DB2 OLTP workload (this information was published in Techdocs WP102461 and WP102464 ). Based on the results of these experiments, clients should consider configuring more memory for DB2 Buffer Pools to avoid I/O and experience improved transaction response time and perhaps improved CPU usage.

While this performance benefit is highly workload dependent, many clients could see better CPU time (internal measurements demonstrated up to 24%) and better response time (internal measurements demonstrated up to 64%). Significant Synchronous Read IO reductions and much improved transaction rates were also observed. Some savings may be seen by adding as little as 14 GB, depending on workload – most customer databases have less than 10 GB of buffer pools configured per DB2.   For example, in one internal OLTP workload, increasing total local buffer pools from 10 to 24 GB resulted in an 18% CPU time savings, due mostly from a 50% synchronous IO reduction.  It warrants repeating that different workloads can experience different benefits at different buffer pool sizes due to differing access patterns, sync IO rates and resource contention rates.    Therefore, your results may definitely vary.  For example, we would expect most client CPU time benefits resulting from more memory use to be less than 3%.

The main metrics to be considered are:

  • ETR, or External Throughput Rate, which is the transaction rate;
  • ITR, Internal Throughput Rate, or the ETR normalized to 100% CP utilization, which is the basis for CPU time assertions;
  • DB Request time, as measure of transaction response time;
  • and sync I/O rates, or I/O requests to the database on disk.

It should also be noted that the workloads used in these studies are dominated by DB2 processing, meaning the application is outboard.  This may factor into the very good results observed.


Below is a graph of some of these results:

z 13 performance

Performance Gains with Larger Buffer Pools on the z 13

In addition, new tooling is available to help predict some of the performance benefits of configuring more memory for DB2 buffer pools.  This consists of a DB2 synchronous I/O simulation tool now available on DB2 11.  This tool can predict expected reduction in sync I/O resulting from a specific increase in the size of a DB2 buffer pool.  Information will be recorded to DB2 statistics records for potential use by performance reporters.  More information on this simulation tooling can be found in the DB2 11 for z/OS Managing Performance publication SC19-4060-06.

In order to determine what resulting CPU time savings might be from such a sync I/O reduction, a simple formula can be used. We estimate that each synchronous I/O saved can translate into approximately 35 microseconds of CPU time, on average – though this number can also vary significantly by environment, e.g. from 15 to 70 microseconds, based on some internal measurements. For example, if the I/O simulation tooling predicted a savings of 1000 sync I/Os per second when more memory was configured for DB2 buffer pools on a 2CPU system running at 90% CPU utilization, then over 19000 CPU microseconds per second could be saved, or about 1.9% – (35microseconds x 1000 I/O per sec) / (2 x .9).

Other z Systems middleware performance can also be enhanced when more memory is available for exploitation by various product functions. The percent gains cited below are based on internal workload measurements and are not necessarily all cumulative. For example:

  • Page fix buffers for IBM Information Management Systems (IMS™) workloads can reduce I/O delays and save up to 3% CPU time based on in-house workloads; larger memory makes fixing pages for IMS buffers a practical and effective solution
  • Larger Memory can also make tuning many DB2 areas practical and effective, possibly yielding D2 CPU time savings; Large page frames: up to 1-3% CPU reduction through better TLB efficiency; Thread reuse and RELEASE(DEALLOCATE): 0-13% by avoiding package allocation and parent locks;  Long term page fix: up to 2-3%; In-memory data cache: 0-10%;  other areas that may benefit from more memory include: Local statement cache; Global dynamic statement cache; Work file avoidance, e.g. in-memory sorting and intermediate result set processing
  • Large memory for IBM MQSeries® V8 can help to cost effectively manage the increasing message volumes generated from today’s mobile and cloud applications; and exploiting large memory buffer pools in IBM MQ V8 can increase the process efficiency of IT integration
  • Large memory can reduce latency and CPU cost, and thus improving operational efficiency, for WebSphere® Application Server and Java® applications by allowing larger heaps without an increase in paging
  • In-house experiments have demonstrated that CPU and response time savings can be experienced by configuring more memory for MDM buffers in DB2; we’ve seen in an internal workload using DB2 11 an 18% DB2 class1 elapsed time savings, reduction in DB2 sync I/O per transaction of 35.69 to 1.57 and DB2 CPU time savings of 6.8% by growing Group Buffer Pools from 120 GB to 565 GB; actual customer results may vary significantly.
  • Exploitation of larger amounts of memory resulted in near linear scalability (i.e. 95% scale efficiency) in internal measurements of Cognos Dynamic Cubes on z/OS. The number of Cognos instances, each containing two Dynamic Cubes and 160 GB of memory, was increased from one instance (160 GB total memory) to three instances (480 GB total memory), achieving close to 3X the transaction rate of the single COGNOS instance, with little variation in response time (less than 5%). This demonstrates how large memory can enable the z Systems analytics value proposition of bringing insight closer to data.

Finally, Independent Software Vendor products may also experience many of the above performance benefits once larger memory is configured.

Many customers can see performance gains in response time and CPU time by configuring more memory, in addition to simplifying systems management and relieving constraints.    Each customer should carefully review their environments, in order to determine if they can experience some of these savings.



Neither this document nor any part of it may be copied or reproduced in any form or by any means or translated into another language, without the prior consent of the IBM Corporation. IBM makes no warranties or representations with respect to the content hereof and specifically disclaims any implied warranties of merchantability or fitness of any particular purpose. IBM assumes no responsibility for any errors that may appear in this document. The information contained in this document is subject to change without any notice. IBM reserves the right to make any such changes without obligation to notify any person of such revision or changes. IBM makes no commitment to keep the information contained herein up to date.

Performance data and customer experiences for IBM and non-IBM products and services contained in this document were derived under specific operating and environmental conditions. The actual results obtained by any party implementing any such products or services will depend on a large number of factors specific to such party’s operating environment and may vary significantly. IBM makes no representation that these results can be expected or obtained in any implementation of any such products or services.

The information in this document is provided “as-is” without any warranty, either express or implied.  IBM expressly disclaims any warranties of merchantability, fitness for a particular purpose or infringement.