179 lines
12 KiB
HTML
179 lines
12 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="task" />
|
||
|
|
<meta name="DC.Title" content="Factors that affect remote journal performance" />
|
||
|
|
<meta name="abstract" content="There are two main performance objectives for the remote journal function. To provide a timely delivery of journal entries to a target system and to minimize impacts to the journaling throughput on the source system." />
|
||
|
|
<meta name="description" content="There are two main performance objectives for the remote journal function. To provide a timely delivery of journal entries to a target system and to minimize impacts to the journaling throughput on the source system." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakiplanrjrn.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakijrnsysperform.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzahg/rzahgicnet2.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="http://www.redbooks.ibm.com/abstracts/sg245189.html?Open" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakireducesize.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakirattributes.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakirauxstore.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2004, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2004, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzakiperform" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Factors that affect remote journal performance</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzakiperform"><a name="rzakiperform"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Factors that affect remote journal performance</h1>
|
||
|
|
<div><p>There are two main performance objectives for the remote journal
|
||
|
|
function. To provide a timely delivery of journal entries to a target system
|
||
|
|
and to minimize impacts to the journaling throughput on the source system.</p>
|
||
|
|
<div class="section"><p>Even though both aspects are very important for both synchronous
|
||
|
|
and asynchronous delivery modes, each mode prioritizes the two in a different
|
||
|
|
order. The top priority for synchronous delivery is to guarantee that the
|
||
|
|
remote journal is always up to date with the source journal. For asynchronous
|
||
|
|
delivery mode, the top priority is to minimize impacts to journaling throughput.</p>
|
||
|
|
<p>All
|
||
|
|
performance considerations that are currently used for a local journal still
|
||
|
|
apply and must continue to be employed. The following are additional factors
|
||
|
|
that may affect the performance of the remote journal function. The factors
|
||
|
|
are listed in the order of importance.</p>
|
||
|
|
</div>
|
||
|
|
<ol><li class="stepexpand"><span><strong>Transport method</strong></span> <p>Your choice of transport
|
||
|
|
depends on the rate of the journal activity in your environment. Make special
|
||
|
|
consideration for using a fast transport method when you use synchronous delivery
|
||
|
|
mode. Weigh the response time impacts of the synchronous delivery mode in
|
||
|
|
your environment against the communications overhead of the transport method
|
||
|
|
you choose.</p>
|
||
|
|
<p>When replicating journal entries over a long distance, the
|
||
|
|
most important performance factors regarding a communications transport method
|
||
|
|
are the overall rated speed of the communications resource and any existing
|
||
|
|
traffic already using the communications resource.</p>
|
||
|
|
<p>For more information
|
||
|
|
about transport methods, see the Networking topic.</p>
|
||
|
|
</li>
|
||
|
|
<li class="stepexpand"><span><strong>Number of remote journals that are being maintained</strong></span> <p>With respect to the job performing the journal entry deposit, the
|
||
|
|
impact of the remote journal function for asynchronously maintained journals
|
||
|
|
is not noticeable. For synchronously maintained journals, the impact depends
|
||
|
|
on the slowest connection rather than number of remote journals.</p>
|
||
|
|
<p>The
|
||
|
|
impact to the job performing the journal entry deposit for an asynchronously
|
||
|
|
maintained journal is significantly less than that for a synchronously maintained
|
||
|
|
journal. Also, it is recommended that only one synchronous remote journal
|
||
|
|
be maintained for a given local journal.</p>
|
||
|
|
<p>With respect to the system
|
||
|
|
performance impacts, the processor use typically increases by less than an
|
||
|
|
equal factor for each additional remote journal.</p>
|
||
|
|
</li>
|
||
|
|
<li class="stepexpand"><span><strong>Arrival rate of journal entries that are being deposited on
|
||
|
|
the local system</strong></span> <p>The higher the arrival rate of journal
|
||
|
|
entries being deposited on the local system, the greater the chance journaling
|
||
|
|
throughput will increase for synchronous or asynchronous delivery. A high
|
||
|
|
arrival rate might cause asynchronous journaling to fall further behind.</p>
|
||
|
|
</li>
|
||
|
|
<li class="stepexpand"><span><strong>Batch versus interactive</strong></span> <p>In general, higher
|
||
|
|
local and remote journal throughput can be maintained when many interactive
|
||
|
|
jobs generate the journal throughput rather than a single-threaded batch job.
|
||
|
|
Journal caching can also increase this throughput for batch processing regardless
|
||
|
|
of the number of jobs.</p>
|
||
|
|
</li>
|
||
|
|
<li class="stepexpand"><span><strong>Processor utilization on the source system</strong></span> <p>The
|
||
|
|
higher the processor utilization of the source system, the greater the chance
|
||
|
|
of affecting journaling throughput for synchronous or asynchronous delivery.
|
||
|
|
This may cause asynchronous journaling to fall further behind.</p>
|
||
|
|
</li>
|
||
|
|
<li class="stepexpand"><span><strong>Processor utilization on the target system</strong></span> <p>The
|
||
|
|
higher the processor utilization of the target system, the greater the chance
|
||
|
|
of affecting journaling throughput for synchronous or asynchronous delivery.
|
||
|
|
This may cause asynchronous journaling to fall further behind.</p>
|
||
|
|
</li>
|
||
|
|
<li class="stepexpand"><span><strong>The value set for the sending task priority when using the asynchronous
|
||
|
|
delivery mode</strong></span> <p>The larger the value, the smaller effect the
|
||
|
|
remote journal function will have on the system, but the further the target
|
||
|
|
system may lag behind the source system.</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakiplanrjrn.htm" title="The following topics provide detailed information for planning to set up remote journals:">Plan for remote journals</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="rzakijrnsysperform.htm" title="Journal management prevents transactions from being lost if your system ends abnormally or has to be recovered. To do this, journal management writes changes to journaled objects immediately to the journal receiver in auxiliary storage. This increases the disk activity on your system and can have a noticeable affect on system performance. Journaling also increases the overhead associated with opening objects and closing objects.">Journal management and system performance</a></div>
|
||
|
|
<div><a href="rzakireducesize.htm" title="Reduce the size of journal entries by methods such as journaling after-images only, or specifying certain journaling options including the Fixed Length Data (FIXLENDTA) option on the Create Journal (CRTJRN) and Change Journal (CHGJRN) commands.">Methods to reduce the storage that journal receivers use</a></div>
|
||
|
|
<div><a href="rzakirattributes.htm" title="When a remote journal is created by the add remote journal processing, the remote journal's initial attributes are defined by the add request and the source journal.">Remote journal attributes</a></div>
|
||
|
|
<div><a href="rzakirauxstore.htm" title="Auxiliary storage will be required on both the source and target systems. The amount that is required will be about the same on both systems.">Remote journals and auxiliary storage</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
|
<div><a href="../rzahg/rzahgicnet2.htm">Networking</a></div>
|
||
|
|
<div><img src="./delta.gif" alt="Start of change" /><a href="http://www.redbooks.ibm.com/abstracts/sg245189.html?Open" target="_blank">AS/400 Remote Journal Function for High Availability and Data Replication</a><img src="./deltaend.gif" alt="End of change" /></div>
|
||
|
|
</div>
|
||
|
|
</div><div class="nested1" xml:lang="en-us" id="performanceconsid"><a name="performanceconsid"><!-- --></a><h2 class="topictitle2">Performance considerations regarding the catch-up phase</h2>
|
||
|
|
<div><div class="section"><p>Performance considerations regarding the catch-up phase when activating
|
||
|
|
the remote journal function include the following in order of importance:</p>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> The
|
||
|
|
catch-up processing that is performed by the remote journal function is the
|
||
|
|
most efficient method of replicating the journal entries with the remote journal
|
||
|
|
function.</div>
|
||
|
|
</div>
|
||
|
|
<ol><li class="stepexpand"><span><strong>Total number of bytes for all of the journal entries that need
|
||
|
|
to be caught up</strong> </span> <p>The larger the total size, the longer the
|
||
|
|
catch-up phase will run.</p>
|
||
|
|
</li>
|
||
|
|
<li class="stepexpand"><span><strong>Transport method</strong></span> <p>Select a transport method
|
||
|
|
that is appropriate for your remote journaling environment.</p>
|
||
|
|
</li>
|
||
|
|
<li class="stepexpand"><span><strong>Disk protection on the target system</strong></span> <p>At high
|
||
|
|
data transfer rates, disk units with device parity protection in the ASP on
|
||
|
|
the target system can limit the performance of the catch-up phase, unless
|
||
|
|
the target system has sufficient write cache configured in the I/O adaptors
|
||
|
|
servicing the disk units that house the journal receiver. One example of this
|
||
|
|
is when you use the OptiConnect for i5/OS<sup>®</sup> bus transport method. Having mirrored
|
||
|
|
or unprotected disk units in the ASP on the target system would eliminate
|
||
|
|
this effect.</p>
|
||
|
|
</li>
|
||
|
|
<li class="stepexpand"><span><strong>Processor utilization on the source system</strong></span> <p>The
|
||
|
|
higher the processor utilization of the source system, the greater the chance
|
||
|
|
of affecting the performance for the catch-up phase.</p>
|
||
|
|
</li>
|
||
|
|
<li class="stepexpand"><span><strong>Processor utilization on the target system</strong></span> <p>The
|
||
|
|
higher the processor utilization of the target system, the greater the chance
|
||
|
|
of affecting the performance for the catch-up phase.</p>
|
||
|
|
</li>
|
||
|
|
<li class="stepexpand"><span><strong>Delivery mode</strong></span> <p>The performance of the catch-up
|
||
|
|
phase does <strong>not</strong> depend on the delivery mode that was specified, synchronous
|
||
|
|
or asynchronous.</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="nested1" xml:lang="en-us" id="howjournalfunct"><a name="howjournalfunct"><!-- --></a><h2 class="topictitle2">How the journal attributes affect the remote journal performance</h2>
|
||
|
|
<div><div class="section"><p><img src="./delta.gif" alt="Start of change" />Reducing the size of the journal receivers on the source
|
||
|
|
system will reduce the communications overhead of the remote journal function.
|
||
|
|
Therefore, you may want to consider journaling *AFTER images and not journaling
|
||
|
|
open, close, or force entries.<img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p>Some of the most common attributes you
|
||
|
|
may want to use for auditing journal entries are the following:</p>
|
||
|
|
<ul><li>Maximum receiver size - RCVSIZOPT(*MAXOPT1, *MAXOPT2, or *MAXOPT3)</li>
|
||
|
|
<li>Remove internal entries - RCVSIZOPT(*RMVINTENT)</li>
|
||
|
|
<li>Minimized entry specific data - MINENTDTA(*FILE) or *FLDBDY</li>
|
||
|
|
</ul>
|
||
|
|
<p>Attributes such as the FIXLENDTA can also cause minimal performance
|
||
|
|
improvements.</p>
|
||
|
|
<p>Refer to the Remote journal attributes and Remote journals
|
||
|
|
and auxiliary storage links below for more details about remote journal performance.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|