Hello Darryl,
Am 28.09.2022 um 21:00 schrieb a4g atl <a4ginatl2@xxxxxxxxx>:
Our performance is not bad. But if the cost is reas, we may consider another processor
Adding to the valid remarks by Jim… Take this with a good grain of salt, because my experience stems from the low and old end of machinery.
There have been rather good and easy to understand books on the topic about performance tuning, decades ago. Since the sparsely revealed underpinnings of OS/400 evolving to IBM i didn't change much of the available knobs to tune, I think the general recommendations still apply.
Chuck Stupca - iSeries and AS/400 Work Management
Fielder, Machell - Supercharging the AS/400 - A Guide to Performance Management
Michael Catalani - AS400 Performance Tuning Simplified
To me, these were an eye-opener about how all the well-known components like subsystems, memory pools, activity levels and statistics (wrkactjob, wrkshrpool, wrksyssts) all come together when looking at a seriously memory-constrained system. Which apparently was the case until well into the 1990's.
Todays systems have memory and CPU cycles in abundance. I/O is much faster, even with rotating disks. I truly believe there are installations in the wild, carrying forward settings which were valid decades ago, on long gone hardware, with hand tuned multiple memory pools and carefully adjusted activity levels to get the optimum balance between competing resource requests. (I remember someone in this group jokingly complaining that he can't bring a P8 to full saturation, but because HW support will end some day, he's required to buy newer and even faster machinery.)
Adding my experiences with multiple (mostly idle, though) machines and OS releases up to 7.2 to the theory I've read… I think, all this hand-tuning is moot with said abundance of resources, and can even be counter-productive my imposing restrictions which no longer make sense but let some applications run "with the handbrake on". I have collected my recommended settings here:
https://try-as400.pocnet.net/wiki/Post-Install_Optimizations
Emphasis is on:
- using QCTL as controlling SBS (instead of default QBASE), because of added flexibility for adding custom SBSds
- Do not allow performance adjustment at IPL time, just when the machine is running
- Enable Expert Cache to always let the system use optimum block sizes for paging data around
- Adjust qtotjob and qactjob reasonably (see wrksyssts and wrkactjob) to allow a reasonable preallocation of management storage at IPL time
- Allow the database part to self-adjust by setting QQRYDEGREE to *OPTIMIZE
- Probably set QTSEPOOL to *BASE if you have nasty users running batch jobs interactively
As you can see, I mainly try to allow the OS to auto-adjust as much as it's able to.
Solid State Memory *is* much, MUCH faster than disks, but this no guarantee that storage latency is always 0. While I trust IBM to be able to not just add SSD storage in a crude way without taking care that the wires and chips to the main memory and CPU are suddenly a bottleneck, SSD is no black magic. :-)
Contrary to the Wintel-World, newer IBM i releases do not eat up the gained CPU resources of newer hardware. :-)
Coming full circle, it's hard to make a serious recommendation for a system with a (to us) unknown usage profile, and configuration settings. Perhaps another CPU might help, perhaps not. If you desperately have money to spare, probably go for it. But you might be disappointed that it doesn't show the benefit you hoped for. Or, like Jim said: It depends…
:wq! PoC
midrange.com
