OMEGAMON zIIP Eligibility: Take Care of Other Vendors’ Claims
rdeem 110000ESR2 Comment (1) Visits (8864)
'Dear Rocky' answers your System z monitoring and performance tuning questions.
Rocky McMahan, a Senior Software Performance Engineer in z System Software R&D, offers valuable tips to help you get more out of your z System monitoring software.
Glenn Crawford contributed to this article
Recently there has been a lot of discussion around the zIIP off-loading capability with monitoring and availability products. A zIIP, or System z Integrated Information Processor is a specialty processor available on the mainframe that can be used to relieve Central Processors (CPs, general purpose engines) of unique processing, thus saving customers money on software monthly license charge (MLC). DB2, Java, as well as XML parsing are some of the first workloads to take advantage of zIIPs.
The OMEGAMON family of products also takes advantage of zIIP processing, but only where it makes sense. By saying so, I mean that OMEGAMON only off-loads CPU to the zIIP when it saves CP usage. For example, a monitoring product may not necessarily be a good candidate for zIIP off-loading by the nature of the product’s behavior. Calculating π (Pi) to 1 million decimal places maybe is more suitable for a zIIP, or code that can run as a task, independent of its parent address space. As a result, if you hear other monitoring and availability vendors make astonishing claims about how much their products can be off-loaded to a zIIP, take a pause.
Before you run code or a routine on a zIIP, ensure it is Service Request Block eligible or in SRB mode. As a result of running in SRB mode, the code or routine running on a zIIP is not allowed to make Supervisor Call Instructions or SVCs. Thus, the code executing on a zIIP cannot conduct basic functions, for example, allocating memory, opening a file or dataset, or starting a new task. Before you execute Supervisor Call Instructions for code running on a zIIP, ensure it is switched back from the zIIP to the Central Processor.
The constant switching of code between the zIIP and the CP results in more work for the CP to coordinate between the two Processors. Therefore, any CPU savings gained by running on the zIIP are lost because the CP manages the off-loading onto the zIIP.
That is why off-loading must be done with surgical precision. If done incorrectly, it’s possible to drive longer path length workloads through the CP, more costly than by not having a zIIP at all. As we, IBM, continue to develop and invest in OMEGAMON, we are always looking for ways to off-load to the zIIP. However, based on several experimental cases in the lab, there are situations when code is moved to the zIIP, but the increase of cost in the CP exceeds the savings gained, so it does not make sense to adopt this approach.
Finally, we as software engineers love a challenge. And clearly there are ways to minimize making SVC calls in the code running on the zIIP, thus constraining or pushing more of the code to run on the zIIP. However, much more software must be developed and executed on the zIIP to force the original code to be executed there. This will require more CPU usage of the zIIP which in turn gives an impression that because more of the zIIP is being utilized, I must be saving more time on the CP.
Here is an example:
Task X uses 10% of a Central Processor. Bring a zIIP on-line and we see the zIIP at 3%. Does that mean 30% the task’s CPU is moved to the zIIP? Maybe not. If we look at the Central Processor we may see that Task X is still using 10% of a Central Processor. With a zIIP, Task X now uses 13% (10% of a Central Processor + 3% of a zIIP). The overhead cost of moving the processing to a zIIP negated the benefit. No Central Processor savings and wasted zIIP cycles. See Chart 1 below.
Therefore, the next time a monitoring and availability product claims it can save a customer money because more of their code runs on the zIIP, be aware. Remember the customer is not saving money by how much code is running on the zIIP. The customer saves money by how much code is NOT running on the CP.
Start asking questions. A simple way to demonstrate the saving is to have the vendor show a central processor CPU usage report of their product executing with the zIIP enabled. Then ask for the same report showing the central processor CPU usage with the zIIP disabled. This will clearly demonstrate the savings, or in some cases, the extra cost of off-loading to a zIIP.
Figure 1: Process X CPU% Utilization of CP and zIIP.