IBM Publishes Power10 Performance Optimize Guide
December 7, 2022
IBM i shops looking to squeeze the most performance out of their Power10 servers have a lot of options available at their disposal. IBM covers many, if not all, of them in its latest performance paper, titled “IBM Power10 performance optimization for IBM i,” which it released last week.
The Power10 is the most powerful processor IBM ever built. Compared to the Power9 processor, the Power10 delivers 20 percent to 30 percent higher performance per core. And with 25 percent more cores per socket, that means oodles of more processing power to do useful work.
At a system level, the Power E1080 offers 1.5 to 1.6 times more capacity than a Power E980 that’s comparably equipped (except for those speedy new Power10 processors, of course). With so much raw processing power on tap, the Power10 processor is ready to gobble up customer workloads.
Not all workloads are equal, of course. Greenscreen 5250 applications are notoriously skimpy when it comes to demands on the system, and a new Power10 server, even an entry-level system, may be overkill for some customers. However, enterprises that are adopting Java or the latest Web languages that run in PASE – or are training machine learning models – may find themselves hitting performance limits, leading to a need to optimize application performance.
IBM covers a wide array of IBM i optimization techniques for Power10 in its 21-page report, which is available as a PDF here.
For example, there is program profiling, an advanced optimization technique to reorder procedures or code within procedures, and advanced argument optimization, which can make procedure calls run faster. Interprocedural analysis is another option available to some, as well as converting 16-byte pointers to 8-byte pointers when compiling C and C++ code.
IBM also discusses adaptive code generation (ACG), which is a technology that allows users to take advantage of all the processor features on their systems, “regardless of whether those features are present on other system models that are supported by the same release,” IBM says.
All ILE programs are activated under what’s called an “activation group,” which is a substructure of jobs that contains the resources needed to run the programs. There are differences in the type of activation groups, including ones that can run either in single-level storage or teraspace storage (which varies the degree of program isolation and protection from accidental access for those programs.)
IBM says users should create new activation groups only when “absolutely required.” If a new activation group is not absolutely required, IBM recommends using an existing named activation group, which “allows the program to reuse the resources that are already allocated instead of rebuilding the environment.”
IBM’s paper also includes a section on optimizing applications for PASE, the AIX runtime that is increasingly used to run applications written in languages like Node.js, PHP, and Python, as well as Java. The main options facing the intrepid PASE user is whether to use the AIX compilers, as supplied by IBM, or to use the GCC compilers from the open source community.
Java is notorious for having a hefty runtime and for slow application performance, on IBM i and just about every other operating system it runs under. IBM has a few tips and techniques ready for improving Java performance on IBM i, including using a just-in-time compiler and being really, really careful about garbage collection.
The Db2 for i database can also be tuned to improve application performance (or rather, the applications can be tweaked to get the most out of Db2). IBM has several suggestions, including using the Db2 for IBM i Health Center to capture information about a user’s database, such as the total number of objects, the size limits of selected objects, the design limits of selected objects, environmental limits, and activity level.
IBM i users can also gather data using the Database Monitor, which collects data about individual queries in real time and stores it in an output table. This information can help the user determine if the queries are performing well or if they need some fine-tuning. If there is a Db2 performance issue, the user might want to fire up the SQL Performance Center to get more detailed information about the queries.
The Db2 database comes with a bunch of self-optimization built in. One of those is the Index Advisor, which will analyze how queries are running and automatically determine if a performance index would improvement performance. The SQL Plan Cache can also provide information about the SQL Query Engine (SQE), and is available through IBM i Access Client Solutions (ACS).
Another ACS-resident tool is Visual Explain, a tool that lets you see information about both static and dynamic SQL statements. The Query Supervisor is another fixture in the database, and can detect when queries executed by the SQE are running well. If performance thresholds are exceeded, it can trigger an exit program (such as for automatically killing the query). There’s also the Predictive Query Governor, which can stop a query even before it gets going if it estimates it’s going to take too long or consume too many resources.
Some database queries may benefit from parallelization, while others will just consume more resources that way (which is why IBM recommends using these features selectively). Parallel I/O and Db2 Symmetric Multiprocessing (SMP) are both available at no charge.
IBM shares a variety of tips for optimizing database performance, such as avoiding use of “live” data (as opposed to using data copied from the database) and minimizing use of open data path (ODP) operations. Use of the “optimize” clause can also help in some situations, including using specific “fetch” and “insert” statements.
Have object names that are more than 30 characters? Consider shrinking them beneath that limit to improve performance, IBM says. Also, learn to use IBM i Wait Accounting, which can help IBM i users understand what tasks or threads are responsible for those long, uncomfortable waits.
Finally, IBM recommends using Performance Data Investigator (PDI), which is a part of IBM Navigator for i and provides a GUI for tracking long-term trends among the various data collection mechanisms, including Collection Services, IBM i Job Watcher, IBM i Disk Watcher, and Performance Explorer.
There is also iDoctor, which is a Windows-based suite of performance tools that can be used with the above-mentioned data collection mechanisms in addition to a few others, including PEX, SQL Plan Cache Snapshots as well as data from HMC, VIOS, AIX, and Linux.
“IBM i is an industry leader in performance management and has many qualities that are not found in other systems, including unparalleled performance metrics, always on collection services, and graphical viewing of performance data,” IBM states in its report. “While understanding all the different processes that affect system performance can be challenging and resolving performance problems requires the effective use of a large suite of tools, the functions offered by IBM i are intended to make this job easier for users.”