With RTR Versions 3 and 4, there are several considerations for
improving performance. These are described in the following sections.
7.1 Process Quotas
OpenVMS process quotas should be increased to accomodate the use of
mailboxes for processes. Check the RTR Installation Guide for
the specific formula to use.
7.2 Journal Sizing
With RTR, the larger the journal, the more time it takes
to read it. This can affect failover in some circumstances. Due to the
new journal format, journal files need to be created larger than in RTR
Version 2 to accomodate the larger transaction identification
implemented for RTR Version 3 and used with RTR Version 4. Monitor the
journal file periodically to make it the most effective size for your
7.3 RTR Startup Qualifiers
RTR startup qualifiers have changed. You no longer provide specific
configuration information but use OpenVMS quotas; RTR Versions 3 and 4
manage configuration requirements.
Monitoring is an important tool for evaluating performance on RTR facilities and between RTR nodes. It provides you with direct feedback on the performance and characteristics of your RTR system and its applications.
Additionally, because RTR Versions 3 and 4 monitoring use RTRACP heavily, doing constant monitoring can affect performance. If monitoring is affecting performance on your RTR system, use a longer monitoring interval than the default (2 seconds). Use the RTR MONITOR command with the /INTERVAL=seconds qualifier to increase the monitoring interval.
You generally use a different monitoring interval when debugging a new
environment, facility, or application than when you are in production.
This is not different between RTR Version 2 and RTR Versions 3 or 4.
RTR Versions 3 and 4 require more memory than RTR Version 2. Monitor
the RTR and application processes for increased page fault rates, and
increase process memory quotas if required.
7.6 Symmetric Multiprocessing
With RTR Version 2, threaded applications could use Symmetric Multiprocessing (SMP) effectively. In RTR Versions 3 and 4, SMP will not provide certain performance advantages of RTR Version 2. The single control process of RTRACP in RTR Versions 3 and 4 does not take advantage of an SMP configuration. Similarly, because with RTR Versions 3 and 4 there is only a single command server, you cannot gain advantages associated with the ability in RTR Version 2 to run command servers on different processors. However, applications can run multiple concurrent servers as in RTR Version 2.
RTR Versions 3 and 4 provide an error log and logical names to assist tracing errors including:
Always initiate an operator log in your RTR$STARTUP.COM procedure.
Place it in a disk partition separate from the RTR journal or database.
8.2 RTR_ERROR.LOG File
The RTR error log was new with RTR Version 3. The RTR_ERROR.LOG file
captures the call stack and counter information in a form readable by a
when a crash occurs, and can be read even when no dump is available.
With RTR Version 2, the only log captured was the operator log, named
by the operator. The operator log remains in RTR Versions 3 and 4, and
the new crash dump log provides additional information.
8.3 Dump File
The system logical name RTR$DUMP_DIRECTORY points to the crash-dump directory. The logical name specified by the user can be set in RTR$STARTUP.COM.
To produce a dump, the procedure is the same as in RTR Version 2 (in
unsupported mode, type DEBUG ACP to get a crash dump).
8.4 Producing and Directing a Trace
To start and stop a trace, use the SET TRACE command. To perform a trace, use the following procedure:
|1. set log/file= filename||Starts your log of the trace. This captures the trace of the specified subsystem in the specified file.|
|2. set mode/unsupported||Sets mode to unsupported.|
|3. set trace/subsystem= name||Starts the trace. Valid names are RTR subsystem names such as API and JNL.|
|or set trace/subsystem=(API, CIF, CRM)||Starts the trace on subsystems API, CIF and CRM.|
|4. set mode/nounsupported||Sets mode to supported.|
|5. set mode/unsupp||Sets mode to unsupported.|
|6. set trace||Stops the trace.|
|7. set mode/nounsupp||Sets mode back to supported.|
Running a trace can affect performance, so be sure to turn it off again
when done (see step 6).
8.5 Dealing with a Looping Process
If your system appears to be hung, this may be caused by an RTR process looping. To analyze the problem, do the following:
With RTR Version 2, the only way to examine the content of journal files was to stop the ACP. With RTR Versions 3 and 4, you can do this without stopping RTR using the DUMP JOURNAL command.