Less Is More—Too Much of a Good Thing
Once upon a time, we had the luxury of throwing resources at performance problems. But even back then, we knew that didn’t always work and that there were diminishing returns, especially for batch workloads. A perfect example is buffering. For OLTP work, you could throw a lot of buffers at it and generally see some benefit, though the gains tended to diminish.
However, with batch, you not only found that, at some point, you got no further benefit, but that having to scan all those buffers could slow the system down. Often, the right number was a good deal lower than what you thought.
Less Is More
The same is true for batch initiators. A major factor in why less is more here involves a variant of the too-many-buffers problem. But to understand it, you have to understand how cache works in modern systems. We’ve previously gotten into some detail, such as in “Cache Me If You Can.” To review, cache is a memory store that is closer to the CPU, sometimes even on the same chip. But there are levels of cache, each farther away from the CPU but still closer than main memory. You save time by having data or instructions in cache. However, there is more demand for cache than there is space.
To manage the space, the CPU uses the LRU method (least recently used) to clear out space for new instructions or data. And the deeper in the cache or in main memory, the longer it takes for the CPU to access the information. Remember, cache is for performance, but just like main memory, it can be overloaded. When you have to dig deep, the CPU waits.
A New Metric
IBM created a new metric, Relative Nest Intensity (RNI), where the Nest is the combination of all the memory spaces and the Intensity refers to the activity in the memory, particularly reflecting cache misses. The higher the RNI, the more performance degrades. While the CPU largely controls the cache and how it works, you have control over one key element, software configuration tuning. For batch, that means reducing the number of initiators to the optimal number.
When you have a lot of initiators, you have a lot of address spaces loading into cache which causes overhead when other cache lines need to be flushed. Due to the nature of batch, that information is probably going to be reused soon and will have to be reloaded. This is the theory, but we always want proof in the real world. How much good can you achieve if you reduce batch initiators to an optimal level? And what is an optimal level? How do you know?
Putting It to the Test
John Baker, z Performance Specialist, decided to test this out to find out how much good you could do with tuning—can you really say that less is more? WLM isn’t always optimal at picking the right number of initiators to achieve the best performance outcome. John had the same 1,000 jobs start under WLM and under Compuware ThruPut Manager. In his test, WLM started 300 initiators, while ThruPut Manager optimized on 25, yet finished an hour sooner. At the halfway mark, the automation of ThruPut Manager had completed 100 more jobs than WLM. Fewer initiators lead to a lower RNI and far better performance.
When you understand a thing, it’s much easier to make it work better. Now that you understand how less is more, optimize your initiators, save on resources and improve performance.
Latest posts by Denise Kalm (see all)
- All Treats, No Tricks – a Better Automated Testing Solution - October 31, 2019
- Be a Data Champion with File-AID and Topaz for Enterprise Data - October 10, 2019
- Driving Change Faster, With a Little Help From our Friends (at Compuware) - September 12, 2019