Re: QPFRADJ=2 vs 3

Rob,

I always use 3 rather than 2.

For the archives:
0=No adjustment
1=Adjustment at IPL
2=Adjustment at IPL and automatic adjustment
3=Automatic adjustment

IPL jobs will alter the memory needed particularly in pools where big start up jobs run, so *BASE tends to get more memory than it needs. If you have the Apache server and the Java jobs that run to start up the Admin server moved into another pool from *BASE (a very good thing) then that pool tends to get big fast too. Pools where not much is going on *INTERACT comes to mind right away, tend to get starved with the IPL mix in the tune.

New memory will start out in *BASE, and get moved as needed anyway. How often do you add memory? If it is occasional then put the memory where you think it needs to be to start with and allow the system to alter it over time.

The problem is the automatic tuner is always looking at the past, not the future. Consider it alot like driving your car down the freeway by only using the left hand rear view mirror (or right hand for our friends in the UK and such). You can do it, however you are always reacting to what was, not what is or is coming. The second problem with the autotune function is it is great at giving memory and activity level to a pool, but really bad at taking it away, so over time the tune gets a bit out of whack and needs some adjustments. When the turns that IPL puts into the road are there, the adjustments are really off for normal workload. In situations where there is plenty of CPU available go ahead and use it, where CPU is constrained, then your better off manually tuning.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 1/17/2012 3:33 PM, rob@xxxxxxxxx wrote:

I understand the arguments against QPFRADJ because of granularity,
timeliness of change, or it doing changes when you don't want it to
because you'd rather it be tuned for process "x". However we're going to
continue to use that. IBM is recommending we change it from 2 to 3. Their
argument is your system spends quite some time getting it tuned for normal
production, why should you let an IPL throw that all out of whack? Seems
to make sense to me. Questions I ponder though include:

What about new memory adds? Adjustment at IPL would surely help that. The
counter to that is are you changing memory often enough that you can't
just change it manually the few times you do that? Mightn't you also
change your max/min's on WRKSHRPOOL at that same time also? To me, those
counter questions kill the new memory exception.

Is your system still tuned for production anyway at IPL time? Let me
explain. Let's say you bring your system down to restricted state. You
run RCLSTG for 14 hours. You do a full system save for 8-10 hours. You
IPL. Was that a good snapshot of your production memory usage anyway? Why
not let the IPL readjust it? Let's say that just about every time you IPL
these are your normal steps.


Rob Berendt
-- Group Dekko Dept 1600 Mail to: 2505 Dekko Drive Garrett, IN 46738 Ship to: Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com
--