- 新しい順
- 投票が多い順
- コメントが多い順
Thanks for the detailed follow-up and for testing those configurations. You're absolutely right that the RabbitMQ management UI and API are correctly showing your 300 connection limit, which confirms the vhost-level configuration is working as expected.
After checking with our service team, I can now clarify what's happening here. The connection limits you're seeing are actually documented in our sizing guidelines: https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/rabbitmq-sizing-guidelines.html
The key point is that there are two different types of limits at play:
- Vhost-level limits (what you configured to 300) - These allow you to restrict connections within each virtual host
- Node-level limits (what's capping you at 100) - These are the actual instance capacity limits that can't be overridden
For m7g.medium instances, the node-level connection limit is indeed 100 connections. The vhost limits you're setting don't override this underlying capacity - they're designed to let you partition that capacity across different vhosts if needed.
The reason you can successfully set lower limits (like 50) is because those are within the node's actual capacity, but setting it higher than the node limit won't increase your available connections.
Since you need more than 100 connections, you'll need to upgrade to a larger instance type. Looking at the sizing guidelines, m7g.large supports up to 5,000 connections, which should easily handle your requirements.
I know this isn't the answer you were hoping for, but the connection limits are enforced for stability and performance reasons. The m7g.medium instances are really intended for testing and development workloads.
I've also raised a documentation update request to make this distinction clearer between vhost-level and node-level limits, though I can't provide an ETA on when that will be published.
Let me know if you have any other questions.
For Amazon MQ for RabbitMQ brokers, there are indeed specific connection limits that differ from ActiveMQ brokers. The connection limits for RabbitMQ are based on instance type and deployment mode.
For RabbitMQ cluster deployments using m7g instance types, connection limits are applied per node. For an m7g.medium instance in a cluster deployment, the connection limit would be lower than larger instance types.
While the general Amazon MQ quotas document mentions that wire-level connection limits don't apply to RabbitMQ brokers (as those specific limits are for ActiveMQ), RabbitMQ has its own connection limit structure.
RabbitMQ brokers use a "max-connections" virtual host limit that can be configured. This limit prevents excessive broker memory usage, which could result in the broker raising a high memory alarm and pausing operations.
If you've set a connection limit of 300 in the RabbitMQ management UI but are experiencing a limit at 100 connections, you might need to:
- Check if the limit is applied correctly to the virtual host you're using
- Consider that cluster deployments have per-node limits
- Verify if there are any default policies overriding your settings
You can modify these limits using the RabbitMQ management API with curl commands or through the RabbitMQ web console. If you need higher connection limits, you might consider upgrading to a larger instance type.
Sources
Amazon MQ for RabbitMQ broker defaults - Amazon MQ
Applying policies to Amazon MQ for RabbitMQ - Amazon MQ
Amazon MQ for RabbitMQ sizing guidelines - Amazon MQ
Can you elaborate how to check the "per-node limits"? What are these?
I have made sure that the limit is applied to the virtual host and also, the max-connections limit is not defined by policies (its a vhost limit) thus option 1 and 3 did not help to clarify the situation.
Is there any connection limit applied to the cluster from the AmazonMQ side? The sizing guidelines specify 100 as the maximum limit for max-connections in an m7g.medium cluster but there is no word that this limit is enforced - especially since I am able to set a higher vhost limit via the RabbitMQ UI, I would expect that this value can be exceeded.
Your connection limit is being restricted to 100 connections despite setting 300 in the RabbitMQ management UI because of Amazon MQ's default vhost limits.
Understanding Amazon MQ Default Policies and Limits
According to the documentation (rabbitmq-defaults.html):
-
Default Policy Application:
- Amazon MQ applies default policies and vhost limits automatically
- These are applied only to the default (/) vhost
- Policies are named based on deployment mode:
- Single-instance:
AWS-DEFAULT-POLICY-SINGLE-INSTANCE - Cluster:
AWS-DEFAULT-POLICY-CLUSTER-MULTI-AZ
- Single-instance:
-
Policy Priorities:
- Single-instance brokers: priority value = 0
- Cluster deployments: priority value = 1
- Custom policies need higher priority values to override defaults
Solutions to Override Connection Limits
From rabbitmq-defaults-applying-policies.html, here are the detailed steps to override the limits:
Method 1: Using RabbitMQ Web Console
- Sign in to the Amazon MQ console
- Navigate to Brokers and select your broker
- Access the RabbitMQ web console URL
- Go to Admin → Limits
- Under "Set / update a virtual host limit":
Virtual host: / Limit: max-connections Value: 300 (your desired limit)
Method 2: Using RabbitMQ Management API
curl -i -u username:password -H "content-type:application/json" -XPUT \ -d '{"value":"300"}' \ broker-endpoint/api/vhost-limits/%2F/max-connections
Important Prerequisites
From the documentation:
"To perform these steps, you must have an Amazon MQ for RabbitMQ broker user with administrator permissions."
Required permissions:
Tags: administrator
Read regexp: .*
Configure regexp: .*
Write regexp: .*
Verification and Monitoring
- Verify Limits:
curl -i -u username:password broker-endpoint/api/vhost-limits
- Monitor Performance:
- Watch for memory usage
- Monitor broker performance
- Check for any high memory alarms
Alternative Solutions
-
Instance Upgrade: Consider upgrading to a larger instance type:
- m7g.large: 5,000 connections
- m7g.xlarge: 10,000 connections
-
Additional vhosts:
- Create new vhosts if needed
- Note that Amazon MQ will not automatically apply default policies to new vhosts
Sources:
Thanks @Makendran for such detailed instructions!
I tried all the approaches you gave to increase the connection limit. The UI shows the following if I set it to 300:
Virtual Host Limit Value / max-connections 300
And the curl command to verify the connection limit returns the following:
[{"value":{"max-connections":300,"max-queues":2500},"vhost":"/"}]
If I set the connection-limit to a value below 100 (e.g. 50), the limit is correctly applied and the connections are capped at that number.
This lets me believe that he rabbitMQ cluster should be correctly configured if I set it to 300 and the UI and API confirm this value. But still, there seems to be another mechanism at play that limits my connections to 100 which I suspect to be on the AmazonMQ side.
Could there be anything that I am missing or is there indeed a hard limit enforced by AmazonMQ?
It doesnt come unexpected and I think its the right call to update the documentation to be more explicit about this limit as it currently leaves room for interpretation. Thank you for the investigation and detailed explanation!