Use this topic as a reference for format of log manager data records.
The format of the log manager statistics record is described in assembler macro
thlqual.SCSQMACS(CSQDQJST).
In the statistics, these counts are important:
- The total number of log write requests:
Nlogwrite = QJSTWRNW + QJSTWRF
- The total number of log read requests:
Nlogread = QJSTRBUF + QJSTRACT + QJSTRARH
The problem symptoms that can be examined using log manager statistics are described in the
following table.
- Symptom 1
- QJSTWTB is nonzero.
- Reason
- Tasks are being suspended while the in-storage buffer is being written to the active log.
There might be problems writing to the active log.
The OUTBUFF parameter within CSQ6LOGP is too small.
- Action
- Investigate the problems writing to the active log.
Increase the value of the OUTBUFF
parameter within CSQ6LOGP.
|
- Symptom 2
- The ratio:
QJSTTVC/N logread
is greater than 1%.
- Reason
- Log reads were initiated that had to read from an archive log, but IBM® MQ could not allocate a data set because MAXRTU data sets
were already allocated.
- Action
- Increase MAXRTU.
|
- Symptom 3
- The ratio:
QJSTRARH/N logread
is larger than normal.
- Reason
- Most log read requests should come from the output buffer or the active log. To satisfy requests
for back out, unit-of-recovery records are read from the in-storage buffer, the active log, and the
archived logs.
A long-running unit of recovery, extending over a period of many minutes, might
have log records spread across many different logs. This degrades performance because extra work has
to be done to recover the log records.
- Action
- Change the application to reduce the length of a unit of recovery. Also, consider increasing the
size of the active log to reduce the possibility of a single unit of recovery being spread out over
more than one log.
- Other pointers
- The ratio
N logread /N logwrite
gives an indication of how much work has to be backed out.
|
- Symptom 4
- QJSTLLCP is more than 10 an hour.
- Reason
- On a busy system, you would expect to see typically 10 checkpoints an hour. If the QJSTLLCP
value is larger than this, it indicates a problem in the setup of the queue manager.
The most
likely reason for this is that the LOGLOAD parameter in CSQ6SYSP is too small. The other event that
causes a checkpoint is when an active log fills up and switches to the next active log data set. If
your logs are too small, this can cause frequent checkpoints.
QJSTLLCP
is a count of the total number of checkpoints.
- Action
- Increase the LOGLOAD parameter, or increase the size of your log data sets as required.
|
- Symptom 5
- QJSTCmpFail > 0 or QJSTCmpComp not much less than QJSTCmpUncmp
- Reason
-
The queue manager is unable to significantly compress log records.
QJSTCmpFail is the number of times the queue manager was unable to achieve any reduction in
record length. You should compare the number to QJSTCmpReq (number of compression requests) to see
if the number of failures is significant.
QJSTCmpComp is the total of compressed bytes written to the log and QJSTCmpUncmp is the total
bytes before compression. Neither total contains bytes written for log records that were not
eligible for compression. If the numbers are similar then compression has achieved little benefit.
- Action
- Turn off log compression. Issue the SET LOG COMPLOG(NONE) command. See the SET LOG command for details.
|
Note: In the first set of statistics produced after system startup, there might be significant log
activity due to the resolution of in-flight units of recovery.