Performance adjustment for Solid State Memory: Difference between revisions
New |
Better wording: Paging ≠ Faulting |
||
| Line 8: | Line 8: | ||
Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|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. | Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|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 | 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. | ||
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 | <blockquote>'''Note:''' Despite the word ''fault'' seemingly indicating a fatal condition, it isn't. A [[wikipedia:Page fault|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.</blockquote> | ||
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 == | == Work with Shared Pools == | ||
| Line 62: | Line 64: | ||
Some explanation to the meaning of the ''Faults/Second'' values: | Some explanation to the meaning of the ''Faults/Second'' values: | ||
* '''Minimum''': If a pool's | * '''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. | * '''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 | * '''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 | The primary goals behind the suggested values are | ||
* Establish hard ''Size %'' limits to prevent pool starvation | * Establish hard ''Size %'' limits to prevent pool starvation | ||
* Allow for much higher | * Allow for much higher faulting rates (''Faults/Second'') before taking action | ||
== See also == | == See also == | ||
Revision as of 09:30, 6 October 2026
|
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.
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[1] | 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
Footnotes
- ↑ Use literal *DFT to reset to default, if unsure.