Capacity planning for IBM MQ is how you ensure next year's payment volume does not fill disks at 2 a.m., freeze channels for lack of CPU, or hit MQRC_Q_FULL because MAXDEPTH was copied from a twenty-year-old template. Middleware is often treated as unlimited until it isn't. Planning translates business growth into megabytes per second, queue depth, log gigabytes per day, and network megabits—then into hardware, cloud spend, and operational limits operators can defend. Beginners set one giant MAXDEPTH and hope; planners model peak rate, outage catch-up, message size, persistence, and DR copy. This tutorial walks forecasting inputs, disk and log sizing sketches, CPU and memory heuristics, network and channel counts, z/OS page set and CF considerations, governance, and how load testing and monitoring feed the plan.
Start with peak messages per second from monitoring or load tests. Multiply by average message size for payload byte rate. Add twenty to thirty percent for headers and protocol overhead. Apply growth factor for three to five years if hardware procurement lead times require it. Example: four thousand msg/s times three KB equals twelve MB/s payload; with growth factor 1.5 over three years, plan eighteen MB/s equivalent before overhead.
| Domain | What to plan | Utilization signal |
|---|---|---|
| Queue disk | Peak depth × msg size | Filesystem percent used |
| Log disk | Write rate × retention | Archive path full |
| CPU | TLS + persistent puts | MQ MSTR high CPU |
| Network | Byte rate × sites | WAN utilization |
| MAXDEPTH | Backlog × safety margin | Frequent Q_FULL |
If consumers stop for four hours during peak, how many messages accumulate? Multiply outage hours by three thousand six hundred by net put rate (puts minus gets). At four thousand net puts per second, four hours yields roughly fifty-seven million messages—if they fit in memory and disk. At two KB each, queue files need on the order of one hundred fourteen gigabytes plus overhead—before logs. That single scenario drives MAXDEPTH and filesystem size. Reduce risk with faster consumers, throttled producers, or shorter acceptable outage windows—not wishful thinking.
Persistent traffic generates log writes continuously. Estimate daily log megabytes from load test bytes written to log per message times peak duration times duty cycle. Retain archives per DR policy on primary and copy to DR site. Log full stops the queue manager—plan archive prune automation with legal approval.
TLS channels consume CPU per megabyte. Many small connections cost listener CPU. z/OS buffer pools need RAM for hit ratio. Cloud pods need limits that allow OS cache. Use load test CPU graphs at plateau; add headroom for failover when both nodes briefly run hot during switchover drills.
Count maximum channel instances, client connections, and cluster channels. Partners may cap sessions. Plan CONNAME and firewall rules when adding regions. Capacity includes operational complexity—not only megahertz.
DR site needs capacity to run production peak plus backlog drain simultaneously after failover. Log shipping storage on both sides. Do not size DR at idle average while primary runs peak.
Publish capacity baselines per queue manager tier. New applications complete a capacity questionnaire before go-live. Review quarterly utilization reports; trigger projects when any resource exceeds seventy percent for a month.
123456789Given: Net put rate during outage = 2,000 msg/s Outage duration = 3 hours Average message size = 1.5 KB (persistent) Messages = 2000 * 3 * 3600 = 21,600,000 Queue data ≈ 21.6M * 1.5 KB ≈ 32.4 GB Add 40% headroom → ~45 GB minimum queue filesystem Add log churn separately — run load test for log MB/hour
Capacity planning is building a parking lot big enough for Black Friday cars, not Tuesday afternoon—plus room for snow plows and fire lanes.
Capacity planning is making sure the marble jar is big enough when all your friends bring marbles at the same time, and Mom has enough notebooks to write down every marble so none get lost.
Calculate queue disk for two-hour outage at 1,500 net msg/s and 4 KB messages with thirty percent headroom.
List five questions for a new application team joining your MQ hub.
Map load test results to three capacity plan line items.
1. Capacity planning prevents:
2. Byte rate needs:
3. MAXDEPTH should reflect:
4. Load test results feed: