diff options
| author | Michal Nasiadka <mnasiadka@gmail.com> | 2026-07-21 21:33:05 +0200 |
|---|---|---|
| committer | Michal Nasiadka <mnasiadka@gmail.com> | 2026-07-23 16:44:21 +0000 |
| commit | 4232989db9fce17aca3fe590d4ccd4a7e641521a (patch) | |
| tree | 52d29408fdcf75a830c9551676d6d868dd69517b /releasenotes/notes | |
| parent | 4d39a81d392f608a04b69cfae9afaa92d65ea388 (diff) | |
| download | kolla-ansible-4232989db9fce17aca3fe590d4ccd4a7e641521a.tar.gz kolla-ansible-4232989db9fce17aca3fe590d4ccd4a7e641521a.zip | |
rabbitmq: Bump default rabbit_qos_prefetch_count from 1 to 50
rabbit_qos_prefetch_count was previously set to 1, the lowest
value permitted by oslo.messaging when rabbit_stream_fanout is
enabled (oslo.messaging requires prefetch_count > 0 for stream
queues, since the stream protocol needs a positive credit window
to make progress).
However, non-zero is not the same as optimal. RabbitMQ's own
quorum queue documentation recommends the opposite of what a
prefetch of 1 provides:
"Quorum queues also benefit from consumers using higher
prefetch values to ensure consumers aren't starved whilst
acknowledgements are flowing through the system and allowing
messages to be delivered in a timely fashion."
-- https://www.rabbitmq.com/docs/quorum-queues
With rabbit_quorum_queue enabled by default alongside
rabbit_stream_fanout, prefetch=1 forces every quorum-queue
consumer (nova-conductor, neutron-server, cinder-volume, etc.)
into fully serialized delivery: RabbitMQ will not deliver the
next message to a channel until the previous one has been acked.
Combined with a small worker count, this can turn a burst of RPC
traffic into a queueing delay long enough to exceed
rpc_response_timeout, surfacing as a false-positive
MessagingTimeout with no actual broker outage.
Bump the default to 50. This keeps the value legal for stream
queues (still > 0), keeps a bound on how much a single consumer
can hold in flight, but gives quorum-queue consumers enough
headroom to avoid unnecessary serialization and consumer
starvation under load.
This is a shared value across all services using
oslo_messaging_rabbit, so it is intentionally conservative
rather than tuned per-service; operators with specific
throughput requirements can still override
om_rabbitmq_qos_prefetch_count.
See [1].
[1]: I541f704bfa2e98068096331afbdb591659cbc40b
Change-Id: Iea474a553cb8bd3920ef89c148f63b1c7b1b8dbc
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
(cherry picked from commit 1ccf97e6234dea12811f0a1270055015bd403079)
Diffstat (limited to 'releasenotes/notes')
| -rw-r--r-- | releasenotes/notes/qos_prefetch_count_bump-141e9eea0ca6a663.yaml | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/releasenotes/notes/qos_prefetch_count_bump-141e9eea0ca6a663.yaml b/releasenotes/notes/qos_prefetch_count_bump-141e9eea0ca6a663.yaml new file mode 100644 index 000000000..93b043808 --- /dev/null +++ b/releasenotes/notes/qos_prefetch_count_bump-141e9eea0ca6a663.yaml @@ -0,0 +1,4 @@ +--- +upgrade: + - | + ``om_rabbitmq_qos_prefetch_count`` has been changed to ``50``. |