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 activtiy. 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 paging rate, essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the paging rate, the more aggressive memory is moved between pools.

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 paging 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 paging 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 paging 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 paging rates (Faults/Second) before taking action

See also

• Post-Install Optimizations