Tag Archives: capping
We’ve already discussed the advantages of using automated capacity management as a way to get the most out of soft capping, but we thought it would be best if you saw the benefits for yourself. The following chart is from an actual z/OS environment that sought to maximize throughput and performance, limit only non-critical workloads, and manage a system’s overall demand within predetermined capacity levels by tracking the variables we mentioned in our previous post.
As you can see, after the techniques were implemented, the slope of the Rolling 4-Hour Average (R4HA) gradually tapers off to skim the cap level. This is because the lowest-priority workloads gradually slowed down as the R4HA peaked. As utilization continued to rise and increase the level of constraint, more low-to-medium priority workloads slowed as well.
While there are definitely some advantages to manual capacity management, as we discussed last week, the most effective method of meeting both the capacity and financial needs of an organization is automated capacity management—provided it’s done effectively.
The goal of any automated system should be to maximize throughput and performance, limit only non-critical workloads, and manage the overall demand within the chosen capacity levels. You ideally want to avoid, or at least limit, the entire LPAR (or LPARs) being capped.
Strict caps, as we’ve mentioned in previous posts, can be harmful to application performance. On the flip side, raising a cap to meet the needs of workload conditions can increase the Rolling 4-Hour Average (R4HA) and, as a result, cancel out the benefits of soft capping. So what is an organization to do?
Well, believe it or not, it is possible to take advantage of the financial benefits of soft capping and meet the needs of your organization at the same time. One technique is to lower the multi-programming level (MPL) of a system by controlling the available batch initiators.
As system utilization grows, applications feel the effects gradually, sometimes starting to slow down as early as 70% CPU utilization and increasing gradually until saturation and timeouts are reached. When your Rolling 4-Hour Average (R4HA) exceeds a system’s cap utilization, however, the effects are instantaneous—and come without warning. Your cap utilization can move from 80% to 90% or even 99.9% of a predetermined cap level—a level that may be far below your machine’s full capacity—without any performance interruptions, but once you exceed that threshold, watch out. Some organizations are exploring creative means to better exploit soft capping and avoid the potential impacts described above.
Soft capping—the act of artificially constraining a system so the MLC bill cannot exceed the MSU level of the cap—offers excellent financial benefits. So why isn’t everyone doing it? The answer lies, for the most part, in how IBM penalizes R4HA overages.
Basically, a system’s installation will be billed based on the peak R4HA or the peak Defined Capacity(DC)/Group Capacity(GC) limit, whichever is lower. This means the R4HA may occasionally exceed the soft cap limit without charge—but not without inconvenience.
So your organization is toying with the idea of implementing a soft capping pricing model as a means of cutting costs. There’s only one thing preventing you from pulling the trigger: Fear. Sure, on paper it makes sense. The premise behind soft capping involves artificially constraining a system so the Rolling 4-Hour Average (R4HA) is kept below a customer-provided limit. Because every licence on a CPC is based on the highest R4HA, costs are contained. And contained costs, as we all know, are not frightening at all, until soft capping wreaks havoc on your online systems and critical batch production by arbitrarily constraining workloads that happen to be high-priority.