In this article, we present a comprehensive tuning configurations guide for RabbitMQ when deploying Xray using Helm. We will focus on the essential settings that are typically sufficient for most systems, avoiding overly complex configurations.
It is important to note that RabbitMQ is deployed through our chart, utilizing the official Bitnami/RabbitMQ chart. As such, its maintenance falls outside the scope of JFrog. Therefore, if you have any specific PR requests regarding RabbitMQ, please consider directing them appropriately (unless the issue lies with Xray).
Without further delay, let us begin:
Configuring Kubernetes native resources:
We will start by tuning the Kubernetes native resource management, where we can configure how much CPU and RAM we want to give to RabbitMQ’s container:
An example:
rabbitmq: resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "1Gi" cpu: "1"
While this is a very basic resource configuration, RabbitMQ has extra flexibility in how we can tune the resource allocation behavior.
Memory Threshold:
RabbitMQ’s server detects the total amount of RAM installed in the container on startup and when the set_vm_memory_high_watermark fraction is executed.
By default, when the RabbitMQ server uses above 40% of the available RAM, it raises a memory alarm and blocks all connections that are publishing messages. Once the memory alarm has cleared, the services resume regularly.
The default memory threshold is set to 40% of installed RAM. Note that this does not prevent the RabbitMQ server from using more than 40%, it is merely the point at which publishers are throttled.
Configuring Memory Threshold:
The memory threshold at which the flow control is triggered can be adjusted by editing the memoryHighWatermark config:
rabbitmq: memoryHighWatermark: enabled: true type: "relative" value: 0.4
The example above sets the threshold to the default value of 0.4. The default value of 0.4 stands for 40% of available (detected) RAM.
Alternatively, the memory threshold can be adjusted by setting an absolute limit of RAM used by the container. The example below sets the threshold to 1024 MiB:
rabbitmq: memoryHighWatermark: enabled: true type: "absolute" value: 1024MiB
When using the absolute mode, it is possible to use one of the following memory units:
- M, MiB for mebibytes
- MB for megabytes
- G, GiB for gibibytes
- GB for gigabytes
Runtime Schedulers:
Schedulers in the runtime assign work to kernel threads that perform it. They execute code, perform I/O, execute timers and so on. By default the runtime will start one scheduler for one CPU core it detects. We can tune this by modifying the maxAvailableSchedulers and onlineSchedulers keys:
rabbitmq: maxAvailableSchedulers: "2" onlineSchedulers: "1"
The maxAvailableSchedulers specifies the max threads used at boot time and is fixed during the run time. But the number of onlineScheduler can be specified and changed in boot time as well as run time.
In the above example we configured 2 max available schedulers, but when the container starts only 1 will be in effect.
Since you are running RabbitMQ in a Kubernetes environment, and it’s not the main application (It’s tuned to work with Xray), you will rarely ever have to change the online schedulers mid work, thus it’s safe to set both of them at the same desired value.
For system sizing values, refer to the Xray Sizing Guide.