Effects of SMAPP on performance and storage

Processor performance

SMAPP has some effect on processor performance. The lower the target recovery time you specify for access paths, the greater this effect may be. Typically, the effect on processor performance is not very noticeable, unless the processor is nearing capacity. Another situation that may cause an increase in processor consumption is when local journals are placed in standby state and large access paths built over files journaled to the local journal are modified. The presence of standby state flags the access paths as not eligible for SMAPP protection. This may force SMAPP to protect many other small access paths in an attempt to achieve the specified target recovery time, and this can lead to performance concerns. Using the F16=Display details function from the Display Recovery for Access Paths (DSPRCYAP) shows the internal threshold used by SMAPP. All access paths with estimated rebuild times greater than the internal threshold are protected by SMAPP. The internal threshold value might change if the number of exposed access paths changes, the estimated rebuild times for exposed access paths changes, or if the target recovery time changes.

To alleviate the processor performance impact, INCACCPTH(*ELIGIBLE) can be specified on the Change Recovery for Access Paths (CHGRCYAP) command. This will give SMAPP permission to ignore any access paths built over files journaled to journals in this state which in turn will prevent SMAPP from having to protect many other small access paths. However, this INCACCPTH option will ignore these access paths when estimating the IPL or independent Auxiliary Storage Pool (ASP) vary on exposure which means that the actual IPL or independent ASP vary on duration may be longer than the estimated value.

Auxiliary storage

SMAPP causes increased disk activity, which increases the load on disk input/output processors. Because the disk write operations for SMAPP do not happen at the same time, they do not directly affect the response time for a specific transaction. However, the increased disk activity might affect overall response time.

Also when you use SMAPP, the system creates an internal journal and journal receiver for each disk pool on your system. The journal receivers that SMAPP uses take additional auxiliary storage. If the target recovery time for access paths for a disk pool is set to *NONE, the journal receiver has no entries. The internal journal receivers are spread across all the arms in a disk pool, up to a maximum of 100 arms.

The system manages the journal receivers automatically to minimize the affect as much as possible. It regularly discards internal journal receivers that are no longer needed for recovery and recovers the disk space. The internal journal receivers that are used by SMAPP require less auxiliary storage than the journal receivers for explicit journaling of access paths. Internal journal receivers are more condensed because they are used only for SMAPP entries.

If you have already set up journaling for a physical file, the system uses the same journal to protect any access paths that are associated with that physical file. If the system chooses to protect additional access paths, your journal receivers will grow larger more quickly. You will need to change journal receivers more often.

Tips to reduce SMAPP's effect on auxiliary storage

• When you set up SMAPP, specify target recovery times for access paths either for the entire system or for individual disk pools, but not for both. If you specify both, the system does extra work by balancing the overall target with the individual targets.
• If you also journal physical files, to deal with the increased size of your journal receivers, consider specifying to remove internal entries when you set up journaling or swap journal receivers. If you specify this, the system periodically removes internal entries from user journal receivers when it no longer needs them to recover access paths. This prevents your journal receivers from growing excessively large because of SMAPP.
• If your system cannot support dedicating any resources to SMAPP, you can specify *OFF for the system target recovery time. Before choosing this option, consider setting the recovery time to *NONE for a normal business cycle, perhaps a week. During that time, periodically display the estimated recovery time for access paths. Evaluate whether those times are acceptable or whether you need to dedicate some system resources to protecting access paths.

  If you turn SMAPP off, any disk storage that has already been used will be recovered shortly thereafter. If you set the SMAPP values to *NONE, any disk storage that has already been used will be recovered after the next time you restart your system.

  Note: If you want to change the target system recovery time to a different value after you have set it to *OFF, the system must be in a restricted state.