If publishing appears stuck during a memory alarm, identify the node and resource alarm first. A large queue and queues being the dominant memory consumer are different facts. Keep disk alarms and transient flow control separate in the incident record.
rabbitmq-diagnostics alarms
rabbitmq-diagnostics memory_breakdown
rabbitmqctl list_queues -p example-vhost name messages_ready messages_unacknowledged consumersReplace the vhost and compare at least two snapshots taken at a consistent interval. The alarm documentation explains publisher back pressure and its cluster scope. Consumer-only connections can continue, while mixing publishing and consumption on one connection complicates the effect.
Three observation patterns lead to different questions
If ready grows while consumers is 0, inspect consumer deployment and connectivity. If consumers exist but unacked keeps rising, compare processing time, missing acknowledgements and prefetch. If both queue counters are stable while connection count and connection memory grow, inspect connection creation, reuse and shutdown. These are diagnostic hypotheses, not measured broker results.
Read the categories in the memory analysis documentation alongside queue counters. Calling one RSS or queue-length reading a leak, or raising the watermark first, can conceal continuing growth. Also account for queue type and version-specific storage behavior.
After a correction, verify consumption rate, unacked trends and publisher confirms as well as alarm clearance. A recovered connection does not guarantee exactly-once processing, so review retries and deduplication separately. No real broker recovery is claimed here.