Kbase 20464: SonicMQ: How Big Should My Recovery Log Files Be?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
6/5/2002 |
|
SUMMARY:
This solution applies to SonicMQ Versions 2000.x, 3.x, and 4.x, and
discusses how to determine the maximum size to which the recovery
log files might grow.
EXPLANATION:
The two recovery log files, recoverylog1.bin and recoverylog2.bin,
help ensure that when a SonicMQ broker is restarted, it is restored to
exactly the same state as it was when it was shut down. These files
reside in the directory indicated by the broker.ini property LOG_PATH.
The maximum size to which these files may grow is set with the
broker.ini property MAX_LOG_FILE_SIZE.
As the broker processes messages, handles connections, etc.,
information about these events is written to one of the recovery log
files. When one of the recovery log files is full, the broker
switches to the other log file. At this point, it performs a
"syncpoint." This means that the broker writes out all the
information about its current state (undelivered persistent messages,
transactions, subscriptions, users, etc.) to the log. This
information could potentially require disk space equivalent to the
sum of max queue sizes for all queues including system queues (for a
worst case scenario in which all queues have filled up and there are
no connected receivers), plus additional space to accomodate the rest
of the information necessary to restore the current state of the
broker.
If the information written to the log file and the syncpoint requires
more than half of MAX_LOG_FILE_SIZE, then the broker will output the following warning message:
Warning - The log file size is too small to maintain performance.
The warning threshhold has been exceeded 1 times since the last
warning.
A log size of at least [n] bytes is recommended.
The value of n in the above message is based on
(2 x [size of data written at last syncpoint]).
If the recovery log file has filled to the point where writing
further information overwrites the last syncpoint, the broker
shuts down with the following message:
Error logging a message that would overwrite recovery information.
Increase the log file size.
SOLUTION:
Sonic Software recommends using a value of at least
(2.5 x [sum of all max queue size values for all queues])
for MAX_LOG_FILE_SIZE.
If your queues are very large, you might want to consider reducing
their size in order to allow the recovery log files to be smaller.
This increases the potential for a queue to fill up, causing flow control to take effect, which temporarily holds up senders to that
queue (but senders would still be able to keep pace with the
receivers on that queue). A smaller log file size also causes the
syncpoints to occur more frequently, and the broker's performance
drops considerably while it is writing information to a recovery log
file for a syncpoint.
Once the syncpoint operation has been completed, all the information
that had been written to the log files previously is obsolete, and
the areas of the files where that obsolete information is recorded
can and will be overwritten the next time the broker switches from
one recovery log file to the other.
NOTE: While the value of MAX_LOG_FILE can always be increased, if
you wish to reduce this value after the broker has already written
past the new, lower value of this parameter, you must reinitialize
your database and recovery log files with the dbtool script.
References to Written Documentation:
SonicMQ 2000.x Installation and Administration Guide
SonicMQ 3.x Installation, Configuration & Administration Guide,
SonicMQ 4.x Configuration and Administration Guide
Sonic Knowledge Base Solution 19869, "SonicMQ Message Size"
Sonic Knowledge Base Solution 20548, "SonicMQ: Why Did My Broker
Take Longer To Start This Time?"