Effects of SMAPP on performance and storage

 

System-managed access-path protection (SMAPP) is designed to have minimal effect to your system. Though it is minimal, SMAPP does affect your system's processor performance and auxiliary 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.

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 Auxilary 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

 

Parent topic:

System-managed access-path protection

Related concepts
Receiver size options for journals Performance