Log tuning is how you balance IBM MQ durability with the speed your business needs. Persistent messages commit to circular logs before applications receive success; that single design choice makes log disk quality, size, placement, and archive policy central to performance engineering. Beginners optimize queues and channels while logs saturate—a queue manager with perfect BATCHSZ still stumbles when NVMe is shared with a data warehouse extract. This tutorial covers distributed LOGFIL and LOGPATH, log file size, archive and media recovery interaction, synchronous versus relaxed logging policies where documented for your release, z/OS log data sets, monitoring, and mistakes that trade three percent faster puts for unacceptable DR gaps.
When an application MQPUT a persistent message with default sync behavior, the queue manager formats a log record describing the put, writes it to the current log extent, and ensures the record reaches durable media before returning MQCC_OK. The message body also lands in the queue file or page set. Non-persistent traffic may skip full logging—faster but not recoverable the same way. Tuning starts by knowing your persistence percentage on hot queues; tuning logs for traffic that is already non-persistent wastes effort.
| Attribute | Role | Tuning note |
|---|---|---|
| LOGPATH | Directory for primary and archive logs | |
| LOGFIL | Count of primary log files | |
| LOGFILE | Size of each primary log file | |
| Archive path | Where filled logs are archived | |
| Log retention / recovery | How long archives kept for restart |
Place logs on dedicated LUNs or local NVMe with low write latency. Avoid sharing with database redo, backup streams, or queue data files on the same spinning disk. In cloud, choose provisioned IOPS volumes for log volumes separately from general-purpose queue storage. RAID levels and fiber channel paths matter on traditional estates. Measure write milliseconds during synthetic persistent put tests, not only sequential read benchmarks marketed for video editing.
Larger total circular log space means less frequent switch to archive—fewer archive I/O spikes—but longer restart replay if the queue manager stops uncleanly. Smaller logs wrap faster, creating more archive files and operator noise. Increase LOGFIL when sustained persistent rate causes constant archiving that competes with active log writes. Decrease only with IBM guidance and maintenance window—never on a whim during production peaks. Document before and after message rates.
When primary logs fill, MQ archives them. If the archive directory is full, logging stops and the queue manager may fail. Automate monitoring on archive filesystem percent used. Prune archives only when recovery and DR policies allow—pruning too aggressively breaks point-in-time recovery and log shipping. Coordinate with backup queue manager teams on minimum retained sequence.
Some installations explore relaxed logging options or application NO_SYNCPOINT patterns to reduce fsync frequency. Each choice shifts RPO and failure behavior. Performance gains belong only in flows where business and compliance accept possible loss. Document sign-off. Never enable aggressive options on payment queues because a blog post suggested it.
z/OS uses log data sets and BSDS catalog entries. Systems programmers size logs with queue manager startup parameters and SMS storage classes. Buffer pools cache log pages as described in the buffer pools tutorial. Archive logs to tape or DASD per runbook. Coupling facility and QSG recovery have additional log coordination—follow IBM z/OS MQ operations manuals.
12345678910* Review current log config (read-only investigation) DISPLAY QMSTATUS * Paths often in qm.ini: LogPath, LogPrimaryFiles, LogFileSize * Example planned change (requires QM stop — follow IBM procedure): * Move logs to /mqlogs/QM1 on dedicated NVMe * Increase LogPrimaryFiles from 3 to 5 after capacity review * Verify archive path /mqlogs/QM1/archive has 500GB free * After change: persistent put load test, compare msg/s and p99 latency
The log is the notebook where MQ writes what happened before filing homework in the queue drawer. If the notebook is slow to write, you wait longer at the desk even when the drawer is empty.
Log tuning is picking a faster pencil and a bigger notebook so Mom can write down each marble she stores without getting tired. If the notebook fills, she stops until she copies old pages to the attic—so the attic needs space too.
List three risks of putting logs and queue files on one overloaded SAN LUN.
Explain tradeoff between larger LOGFILE and restart replay time.
Design archive disk alerts at eighty and ninety-five percent full.
1. Persistent puts require:
2. Logs on same slow disk as queues often cause:
3. LOGFIL controls:
4. Full archive directory can: