aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMichal Nasiadka <mnasiadka@gmail.com>2026-07-21 21:33:05 +0200
committerMichal Nasiadka <mnasiadka@gmail.com>2026-07-23 16:44:21 +0000
commit4232989db9fce17aca3fe590d4ccd4a7e641521a (patch)
tree52d29408fdcf75a830c9551676d6d868dd69517b
parent4d39a81d392f608a04b69cfae9afaa92d65ea388 (diff)
downloadkolla-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)
-rw-r--r--ansible/group_vars/all/common.yml2
-rw-r--r--releasenotes/notes/qos_prefetch_count_bump-141e9eea0ca6a663.yaml4
2 files changed, 5 insertions, 1 deletions
diff --git a/ansible/group_vars/all/common.yml b/ansible/group_vars/all/common.yml
index 801fc9850..a987919d6 100644
--- a/ansible/group_vars/all/common.yml
+++ b/ansible/group_vars/all/common.yml
@@ -294,7 +294,7 @@ notify_transport_url: "{{ om_notify_transport }}://\
om_enable_rabbitmq_tls: "{{ rabbitmq_enable_tls | bool }}"
# CA certificate bundle in containers using oslo.messaging with RabbitMQ TLS.
om_rabbitmq_cacert: "{{ rabbitmq_cacert }}"
-om_rabbitmq_qos_prefetch_count: "1"
+om_rabbitmq_qos_prefetch_count: "50"
om_enable_rabbitmq_stream_fanout: true
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``.