Almost. They are mutually exclusive settings.
Expert cache is the systems autonomic ability to adjust paging sizes while
that individual pool is paging and manages the caching for the jobs within
the pools. Its caching algorithm monitors physical and logical storage
activity, dynamically adjusting the cache parameters for a given pool. It
manages the data flow in a way that is most beneficial overall to total
performance. Basically it optimizes I/O from/to Mainstore memory. It is
part of the IBM i Storage Management brilliance.
Performance adjustment is just that. The adjuster will move memory between
storage pools and raise activity levels as needed. It is independent of
expert cache.
<Assuming sufficient memory on the system>
I will argue that performance adjustment while very good is not as good as
human tuning. If you tune the system manually for a daytime workload, and
then again for a nighttime workload, and have a CLP that changes it (most
folks called these programs DAY and NIGHT) you'll have a better tuned
system.
Reason: The performance adjuster is much like driving down the highway with
nothing but the rear view mirrors to guide you. It's possible to do if
there are no sharp turns. Its biggest drawback is Its always reacting to
the past. The other issue I have with it is once it gives resources (memory
AND activity level) it is not as good as it could be to take away those
resources, particularly activity levels. Memory tends to move but activity
levels stay high. Too many activity levels can hurt the processes running
in a pool just as much as not having sufficient memory in the pool. These
are the limitations I referred to earlier in this thread.
<Not enough memory on the system>
In the case where the system is running very thin on memory your best off to
leave the auto adjust turned on. It will optimize the box better that a
human can. But since memory is really cheap by comparison to everything
else, unless there is a physical constraint, add memory.
Bottom line: Expert Cache always on, performance adjuster depends on the
type and variability of the workload.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Tuesday, December 30, 2014 4:15 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Paging option of *FIXED vs *CALC
Jim,
Thanks for SQL tip.
We use very little SQL, but that could change.
Question, if QPFRADJ off, how does memory get moved back and forth between
batch and interactive? We all know batch will take as much as it can.
It doesn't make sense to have large amounts in both, then when that pool is
least used, a waste of memory.
I remembered the setting requires *CALC, Expert cache.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim
Oberholtzer
Sent: Tuesday, December 30, 2014 12:52 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Paging option of *FIXED vs *CALC
Paul,
I suggest you consider your use of the automatic tuning function (QPFRADJ).
For more traditional applications and batch processing this is a good
setting. It will migrate memory from pool to pool as needed, with some
limitations.
However if your application suite uses SQL in any meaningful way, then it's
likely that setting is hurting more than helping. One of the things the SQL
optimizer looks at when starting the optimization process is "did my
environment change?". If not run the query, if it did, then optimize to be
sure the query runs as fast as possible. QPFRADJ almost forces every query
to optimize every time since the environment by definition is changing. In
an environment where quite a bit of SQL and particularly remote SQL (Zend,
WAS, and several other ways of doing remote SQL) then a steady environment
will make these queries more efficient.
I would say that 90% of my customers run better with QPFRADJ off, and an
occasional (meaning weekly) look at the performance statistics to see if
there is an adjustment needed.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Tuesday, December 30, 2014 11:19 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Paging option of *FIXED vs *CALC
*CALC for all, machine cannot be changed, forced to *fixed.
QPFRADJ = 2
During the day, most memory is moved to *interact for users.
During evening and night hours, memory moved to *SHRPOOL1 for large batch
processing.
There is also a setting or feature that added improved performance if set to
*CALC.
I can't remember what this was called.
Work with Shared Pools
System:
PENCOR05
Main storage size (M) . : 200704.00
Type changes (if allowed), press Enter.
Defined Max Allocated Pool -Paging Option--
Pool Size (M) Active Size (M) ID Defined Current
*MACHINE 22077.42 +++++ 22077.42 1 *FIXED *FIXED
*BASE 18888.82 1714 18888.82 2 *CALC *CALC
*INTERACT 92082.62 3999 92082.62 4 *CALC *CALC
*SPOOL 3010.55 30 3010.55 3 *CALC *CALC
*SHRPOOL1 64644.56 30 64644.56 5 *CALC *CALC
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike
Cunningham
Sent: Tuesday, December 30, 2014 11:26 AM
To: Midrange Systems Technical Discussion
Subject: Paging option of *FIXED vs *CALC
It has been some time since we have looked at this option so I decided to
review this setting for storage pools. We have always found in the past that
*FIXED performed better for us and that is how we have all pools set at the
moment. I think the last time we evaluated this setting was back pm V5R4 and
we are now at 7.1 (we skipped 6). We have 7 pools setup. Besides *MACHINE
and *BASE we have *INTERACT , *SPOOL and three Shared Pools. *INTERACT is
mostly traditional 5250 but also some jobs that we run all day doing
interactive type transactions. One shared pool runs only ODBC/JDBC tasks
from a system running on Linux but using DB2 as its database. Second shared
pool is for QBATCH work. Third shared pool is for WTR jobs. *BASE runs
everything else. (HTTP, Websphere, Zend, QCTL, QSERVER, QSYSWRK, QUSRWRK and
a few 3rd party tools - Curbstone, Websmart, GoAnywhere.
We do not have any real performance issues with the exception of an
occasional SQL requests coming on from the Linux systems via ODBC, where it
will spike the CPU for a 4-5 seconds. And some outgoing JDBC requests from a
job running on the i OS and getting data from a MS SQL system.
I have not seen many articles after 2010 on this setting and those I did
find say to use *FIXED for 5250 work and *MACHINE and *CALC for anything
doing only database (aka ODBC) tasks or do batch type work. "back in the
day" IBM's recommendation was to try each setting and see which performed
better and use that one. We found that *FIXED worked better for us.
QPFRADJ is setup to No Adjustment.
What do others run for these settings and for what type of workload?
Thanks
Mike Cunningham
VP of Information Technology Services/CIO Pennsylvania College of Technology
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
