Re: Paging option of *FIXED vs *CALC

[Jim Obeholtzer <midrangel@xxxxxxxxxxxxxxxxx>]

Rob,

The weekly review I suggest is done by running the system report from
Performance tools and looking at the summary.  It takes me about 1 hour to
go through about 40 partitions for various customers.  I print the report
from a job schedule entry.  70% of my time is switching from customer to
customer VPN connection.  The only time you react much is if there is a
complaint of some sort forwarded or if you see a memory pool starting to
page/fault more than normal.

90% of the time when that happens it's time to review the indexes on the
system to see if there's an index or two that need to be built due to
changes in the data usage.

On Fri, Feb 13, 2015 at 10:27 AM, <rob@xxxxxxxxx> wrote:

> Jim,
>
> I was looking at your recommendation of not allowing QPFRADJ to
> automatically adjust in order to avoid constant query reoptimization.
> Then you make a recommendation for a weekly review.
> Well, if I have to pour through performance data the odds of this weekly
> review getting done weekly drop.
> What about the possibility of this?
> Add two job schedule entries.  One to change QPFRADJ back to automatic.
> One to turn it back off.  The second one being two hours later.  Maybe run
> 9-11am on Tuesday mornings?
>
>
> Rob Berendt
> --
> IBM Certified System Administrator - IBM i 6.1
> 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
>
>
>
>
>
> From:   "Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
> To:     "'Midrange Systems Technical Discussion'"
> <midrange-l@xxxxxxxxxxxx>
> Date:   12/30/2014 12:52 PM
> Subject:        RE: Paging option of *FIXED vs *CALC
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> 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.