Re: WRKSYSSTS paging option

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