Intel 7xx Servers User Manual

There are 3 sets of tasks which do the SMAPP work.  These tasks work in the background at low priority
to minimize the impact of SMAPP on system performance.  The tasks are as follows:
y

JO_EVALUATE-TASK - Evaluates indexes, estimates rebuild time for an index, and may start or
stop implicit journaling of an index.

y

JO-TUNING-TASK -  Periodically wakes up to consider where the user recovery threshold is set and
manages which indexes should be implicitly journaled. 

y

JORECRA-DEF-XXX and JORECRA-USR-XXX tasks are the worker tasks which sweep aged
journal pages from main memory to minimize the amount of recovery needed during IPL. 

Here are guidelines for lowering the amount of work for each of these tasks:
y

If the JO-TUNING-TASK seems busy, you may want to increase SMAPP recovery target time.

y

If the JO-EVALUATE task seems busy, explicitly journaling the largest access paths may help or
looks for jobs that are opening/closing files repeatedly. 

y

If the JORECRA tasks seem busy, you may want to increase journal recovery ratio. 

y

Also, if the target recovery time is not being met there may be SMAPP ineligible access paths.  These
should be modified so as to become SMAPP eligible. 

To monitor the performance impacts of SMAPP there are Performance Explorer trace points and a
substantial set of Collection Services counters which provide information on the SMAPP work. 
 
SMAPP makes a decision of where to place the implicit access path journal entries.  If the underlying
physical file is not journaled, SMAPP will place the entries in a default (hidden) system journal.  If the
underlying physical file is journaled, SMAPP will place the implicit journal entries in the same place.
SMAPP automatically manages the system journal.  For the user journal receivers used by SMAPP,
RCVSIZOPT(*RMVINTENT), as specified on the CHGJRN command, is a recommended option. The
disk space used by SMAPP may be displayed with the EDTRCYAP and DSPRCYAP commands.  It
rarely exceeds 1% of the ASP size.  

For more information on SMAPP see the Systems management ->  Journal management ->  
System-managed access path protection section in the System i information center.

Commitment control is an extension to the journal function that allows users to ensure that all changes to
a transaction are either all complete or, if not complete, can be easily backed out.  The use of commitment
control adds two more journal entries, one at the beginning of the committed transaction and one at the
end, resulting in additional CPU and I/O overhead.  In addition, the time that record level locks are held
increases with the use of commitment control. Because of this additional overhead and possible additional
record lock contention, adding commitment control will in many cases result in a noticeable degradation
in performance for an application that is currently doing journaling.

DB2 Multisystem for i5/OS offers customers the ability to distribute large databases across multiple
System i servers in order to gain nearly unlimited scalability and improved performance for many large
query operations. Multiple System i servers are coupled together in a shared-nothing cluster where each
system uses its own main memory and disk storage. Once a database is properly partitioned among the

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

©

 Copyright IBM Corp. 2008