Re: WRKSYSSTS paging option

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

No - this means that you are locked in to using 4KB pages when reading 
and writing to DASD - very slow!!

F1 is your friend!! Type DSPSYSVAL QPFRADJ and hit enter, then hit F1 
and you'll get what this system value controls. System pool sizes and 
activity levels is it.

The paging option (Expert Cache) is primarily connected with database IO 
- if the database access is mostly sequential in a sliding window of 
about 240 seconds (IIRC), then the system will use larger page sizes in 
IO requests, up to 128KB the last I heard. If access is random, such as 
by key, it will use smaller page sizes for IO requests.

Fixed size pools can only be set to *FIXED for paging in WRKSYSSTS - 
there is an API to do differently, but not recommended for the regular 
work, because you can easily set up shared pools instead. Their behavior 
is controlled with settings in WRKSHRPOOL, where you can set minimum & 
maximum size (in % of dasd) and activity levels and initial size and all 
that.

You can see the effect of Expert Cache using WRKDSKSTS - this reports 
the number of requests, as well as request sizes. You'll see there that 
writes are normally on the small side - makes sense.

Expert Cache is most beneficial when you separate work into more pools - 
because it can have similar kinds of data access in a pool. Having *CALC 
on *BASE is a crap shoot when everything runs there, because of the 
variety in database access going on - no consistency thereof.

Here is an item from an IBM web page on DB2, from an article in iSeries 
News from 2002 -

"This self-tuning database feature is known as expert cache and 
activated by changing the paging option for a memory pool from *FIXED to 
*CALC (CHGSHRPOOL... PAGING(*CALC)). Once the expert cache option has 
been activated, the DB2 UDB engine monitors and analyzes the access of 
database objects. If it detects that every row in a table that is being 
read sequentially, it will increase the internal blocking size to bring 
larger portions of the table into memory in an effort to reduce the 
total number of disk operations. The DB2 UDB engine can also detect if a 
range of rows in the table is being accessed frequently. If that type of 
data access is detected, then DB2 UDB will keep the memory pages 
associated with those rows in memory longer. This action once again 
reduces the number of disk operations which usually results in improved 
performance. The only administrative requirement is to activate the 
expert cache - DB2 for i analyzes and adjusts the database I/O access 
patterns all by itself to tune the performance of your iSeries server."

HTH
Vern

Steve McKay wrote:
> The WRKSYSSTS paging option on our production system is *FIXED for all 4 
> memory pools (*MACHINE, *BASE, *INTERACT, *SPOOL).  We don't have any 
> additional pools.  I don't remember other machines that I've worked on 
> having all of them set to *FIXED, it seems like most of them have been *CALC 
> except for *MACHINE.
>
> Does this mean that QPFRADJ = 2 is having no effect on my system?
>
> Thanks,
>
> Steve 
>
>
>