| Issue 2, 2013 | Download pdf |
By Arno Zude and Nate Sathre, R&D, Software AG
Software AG is a member of zSeries® Partner in Development and actively adopts IBM® mainframe hardware and software innovations. This past November, Software AG tested the latest version of Adabas and its add-on products on new IBM mainframe hardware and operating system software at the IBM System z® Benchmark Center in Poughkeepsie, NY. Recommendations on how to leverage IBM’s zHPF™, Flash Express™ and Large Pages with Adabas for increased scalability and throughput are discussed below. To dive into the detailed test results, please read the white paper at www.softwareag.com/adabasperformance
Test Objectives
The test database and workload were designed to align with the well-known TPC-C OLTP benchmark. Multiple scenarios with Adabas and various add-on products set up on IBM’s latest mainframe hardware and system software were established to test for optimal performance and scalability. The objectives of the tests were to determine the following:
- Scalability of Adabas Cluster Services and Adabas Parallel Services
- Maximum throughput achieved with Adabas Parallel Services
- Relative performance of Adabas with and without IBM zHPF
- Relative performance of Adabas with and without large pages
- Impact of paging with IBM Flash Express on Adabas performance
- Relative performance of Entire Net-Work with different line drivers
Scalability
Adabas Cluster Services scaled well up to 12 nuclei in a cluster, increasing the external throughput (number of Adabas commands per elapsed wall clock second) as nuclei were added. Beyond that cluster size, the external throughput flattened out, probably because the Adabas Cluster Services nuclei were limited by the many read I/Os from ASSO and DATA.
Adabas Parallel Services scaled well up to 24 nuclei in the cluster, increasing the external throughput as nuclei were added as shown in Figure 1. Beyond that cluster size, the external throughput flattened out, probably because the Adabas Parallel Services nuclei were limited by the many database I/Os.
Figure 1: External throughput increases with cluster size
For both Adabas Cluster Services and Adabas Parallel Services, as additional nuclei were added to the cluster, the average CPU consumption per command increased only slightly per nucleus added. In fact, when a small cluster was increased, the average CPU consumption at first decreased (with a low at four nuclei with Adabas Cluster Services and 20 nuclei with Adabas Parallel Services); then it increased by about 1 percent or less per nucleus added.
Recommendations: Put an Adabas Cluster Services nucleus on every system within the Parallel Sysplex that hosts users who issue a significant number of Adabas calls. The better performance gained from users making local calls to the Adabas Cluster Services nuclei outweighs the small performance cost of increasing the cluster.
If the update load is very high, tune the Adabas buffer flush and the I/O subsystem to achieve that updated blocks are written out to the database as fast as the updates are performed in memory. Avoid that the cache structure runs full with updated blocks. Structure-full events for Adabas Cluster Services reduce the external throughput.
Use as many Adabas Parallel Services nuclei in the cluster as needed to keep each individual nucleus from becoming a bottleneck, whether by consuming up to 100 percent of one CPU or by being limited in its WORK/PLOG writes or by something else. Adabas Parallel Services clusters scale well. If individual nuclei are resource-constrained, adding another one may relieve the constraint, up to at least 20 nuclei.
Maximum Throughput
A number of tests were performed to explore which configuration of Adabas Parallel Services achieved the highest External Throughput Rate (ETR) as shown in Table 1. The highest external throughput seen in the standard update test, with ~5.2 percent update/insert commands and ~5.9 percent commit/backout commands, was 1,140,272 Adabas commands per second elapsed (wall clock) time.
The highest external throughput seen in the read-only test, with no update commands, was 1,463,546 Adabas commands per second elapsed (wall clock) time.
|
Test ID |
Cluster |
CLUCACHE- |
User |
Avg. TXG |
Total Adabas |
ETR |
ITR |
|
D27PM |
28 |
245G |
509,983,708 |
7.50 |
156.44 |
1,140,272 |
54,333 |
|
D26P1 * |
31 |
260G |
906,576,746 |
12.05 |
252.38 |
1,254,222 |
59,868 |
|
D27P3 * |
31 |
245G |
906,490,607 |
10.46 |
248.78 |
1,463,546 |
60,728 |
zHPF Greatly Improves Performance
We tested if potential improvements in I/O performance translated to performance gains for Adabas applications.
Caveat: When running a large cluster (more than eight nuclei) with high buffer efficiency and an update-intensive application workload, watch the relation between WORK/PLOG writes and ASSO/DATA I/Os before and after the switch to zHPF.
Large Pages Affect The Whole System
IBM z/OS 2 GB Large Pages, supported by Adabas Parallel Services and Adabas Caching Facility, may provide lower CPU consumption for large memory objects in long-running memory-intensive applications, such as a database server.
Backing the large, shared Adabas Parallel Services cache with large pages (1 MB pages or 2 GB pages) reduced the average CPU consumption per command in the range of 3.7 to 6.8 percent, but did not demonstrate a clear improvement in the external throughput. The benefit from large pages may be smaller if there are fewer than the 31 nuclei in the cluster that we used in our tests.
Recommendation: The expectation of CPU savings should be weighed case by case against taking the related storage away from the rest of the system for only this purpose. Configuring a system with large pages affects the whole system, not just the subsystem that uses the large pages.
Flash Express Faster Than Disk But No Paging is Best
Flash Express exploits flash memory for paging as a new optional feature of the IBM zEnterprise® EC12 (zEC12) processor. The flash memory cards on the zEC12 processor come in pairs with each pair of cards providing 1.4 terabytes of storage.
When Adabas Parallel Services was tested with a larger shared cache, which caused paging to Flash Express, an increase in external throughput was experienced. But paging to disk and severe paging to Flash Express caused the external throughput to drop precipitously. The impact of paging would probably be smaller with fewer parallel users. But better external throughput was achieved with an Adabas configuration that did not include paging.
Recommendation: For best performance, configure Adabas to avoid paging. Occasional light paging to Flash Express devices may be tolerable. However, reconfiguring Adabas to avoid paging promises the best results.
ENTIRE NET-WORK Performs Best with FCTC Line Driver
Entire Net-Work transparently connects Software AG’s server products—including Adabas—with client programs (e.g., Adabas users) that are running on other systems (e.g., mainframe, UNIX® and Windows®). We explored the relative performance of different Entire Net-Work line drivers when the Adabas users were remote to Adabas.
Entire Net-Work performed best with the FCTC line driver of version 6.3 SP1, achieving higher external throughput and lower Net-Work CPU time per Adabas command than the CTCA driver and the FCTC driver of version 6.2 SP2. With the payload data generated by the test application, send and receive block sizes of 32 KB performed slightly better than 60 KB blocks.
The configurations with the TCP/IP and XCF line drivers did not perform as well, but they were not specifically tuned for best performance. It is possible that they would have fared better with other configuration settings.