Performance adjustment for Solid State Memory

This article isn't finished yet or needs to be revised. Please keep in mind that thus it may be incomplete. Reason: Finish article

OS/400 Performance adjustment for Solid State Memory sheds some light on how to tune a system in regard to the almost zero latency for this type of secondary storage.

OS/400 is an paged virtual memory platform. There's no direct open a file and read the content into RAM system function. All data between secondary and primary storage (historically disk, and RAM) flows through the paging code.

Today, disks are largely replaced with solid state, flash based memory. It has no moving mechanical parts, eliminates the accompanying access latency, generates no noise, draws less power, generates less heat, and often uses less physical space. Older AS/400 systems can benefit from the ZuluSCSI parallel SCSI disk emulator.

OS/400 features a so called performance adjustment function, which automatically splits and shifts available memory around between memory pools according to the current workload, the goal is to minimize paging activity. The default threshold values when, and how much memory is moved around are based on the relatively high latency of rotating disk drives. One particular data point is the faulting rate, essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the faulting rate, the more aggressive memory is moved between pools.

Note: Despite the word fault seemingly indicating a fatal condition, it isn't. A page fault is a mere indicator that a requested memory location isn't in main storage and a different code path has to be taken to bring it into main storage before processing can commence. Also, a single page fault can result in multiple memory pages being copied into main storage at once.

Solid state memory allows very high paging rates, impossible with spinning disk drives, but without introducing excessive latency. The performance adjust doesn't base adjustment calculations on latency, but on faulting rate. On a system with much disk activity, this can lead to memory starvation of less active pools, and frequent invalidation of in-memory cached data due to quick reassignments of memory.

Work with Shared Pools

The wrkshrpool command allows to adjust threshold values for the performance adjuster by pressing F11. You'll be presented with a table akin to the following. Suggested adjustment values are shown below. Values printed in bold are changed (non-default) values.

		Size (%)		Faults/Second
Pool	Priority	Minimum	Maximum	Minimum	Thread	Maximum
*MACHINE	1	25.49	50	100	0	100
*BASE	1	4.99	100	25	0.5	2000
*INTERACT	2	5	25	50	2	1000
*SPOOL	3	1	10	25	1	1000

Some explanation to the meaning of the Faults/Second values:

• Minimum: If a pool's faulting rate drops below this value, the adjuster views the pool as over-allocated and will begin to strip memory away from it to feed other pools.
• Thread: The multiplier allocated per active thread. The OS calculates active threads by evaluating only threads that have actually consumed CPU slices during the most recent tuning interval.
• Maximum: If the pool's faulting rate exceeds this value, the adjuster considers the pool starved and starts aggressively moving memory into it from other pools.

The primary goals behind the suggested values are

• Establish hard Size % limits to prevent pool starvation
• Allow for much higher faulting rates (Faults/Second) before taking action

See also

• Post-Install Optimizations