Re: Check your ancient performance settings

Generally I agree with this - but there are workloads that can benefit from being in their own pool - things like ODBC or JDBC requests, web serving requests, etc.

If you leave those at default, they will probably be in *BASE or QCTL and contend for resources with all the stuff running there.

Regards
Vern

On 10/8/2019 3:27 AM, Patrik Schindler wrote:

Hello Rob,

Am 07.10.2019 um 19:36 schrieb Rob Berendt <rob@xxxxxxxxx>:

I had a job schedule entry which may be really old. So old that it causes more harm than good.

Good remark! Since about 10 years, I've been tinkering privately with a 150 (192 MB RAM) and a S20 (512 MB RAM) and I never really got a grip to the concept of memory pools. Maybe this isn't necessary anymore, because every decent system has so much RAM that thrashing never happens anymore. So I think there's no need to "segment" memory into separate paging domains anymore. At least that's what I think memory pools really are good for.

Thus, I set PAGING for all pools to *CALC and QPFRADJ to 3 (automatic, not at IPL). I think the system should be smart enough to figure out optimum settings by itself, based on workload (and not the one-shot IPL-stuff).

Any comments on this?

It was like this:
ADDJOBSCDE JOB(OPBASEPOOL) CMD(CHGSHRPOOL POOL(*BASE) ACTLVL(1880))
FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*MON) SCDTIME(040000)
SAVE(*NO) RCYACN(*SBMRLS) JOBD(*USRPRF) JOBQ(*JOBD)
USER(ROB) MSGQ(*USRPRF)
TEXT('QPFRADJ adjustment at IPL can be too low.')
I'm guessing that at the time I created this entry I was actually raising the base activity level. Every Monday, after a possible weekend IPL (which is really only done quarterly) up QBASEACTLVL. However, in this era, it has the reverse effect of lowering the base activity level.
Dangerously low. Like, no jobs can be started, not even the system console job, low. Like unscheduled IPL low. And having to force IPL, outside of the OS, from the HMC (from home).
DSPLOG PERIOD((*AVAIL *BEGIN)) MSGID(CPF1805 CPF0909)
System value QBASACTLVL changed from 3248 to 1880.
Ineligible condition threshold reached for pool 02.

That was one case with IBM. The second case with IBM was why is the auditing on their system values so weak?
DSPJRN JRN(QAUDJRN) RCVRNG(*CURCHAIN) FROMTIME(093019 0400)
JRNCDE((T)) ENTTYP(SV)
and
DSPLOG PERIOD((*AVAIL *BEGIN)) MSGID(CPF1805 CPF0909)

System value QBASACTLVL changed from 2707 to 1880.
System value QBASACTLVL changed from 3248 to 1880.
Ineligible condition threshold reached for pool 02.
System value QBASACTLVL changed from 2707 to 1227.

Neither of the above solve this riddle: What changed the system value QBASACTLVL to 3248?
Both show entries from QPFRADJ (and elsewhere)

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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc