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
midrange.com
