Resource Considerations
This document describes resource considerations and limitations to be taken into account when provisioning and operating a9s Messaging Service Instances.
The resource requirements of a Service Instance depend on the Template selected for its Service Plan. Each Template defines the topology (number of nodes) and the set of colocated processes. Templates that provide logging require a higher-memory VM type and more ephemeral disk than Templates without logging.
The Platform Operator must define matching vm_type and persistent_disk_type entries in the BOSH Cloud Config and
reference them from the Service Plan configuration. For guidance on Service Plans and Templates, see Service Plans
and Available Templates.
For guidance on Service Plans and Templates, see Service Plans and Available Templates.
Template Requirements
The resource requirements of a Service Instance depend on the Template selected for its Service Plan. The small,
medium, and large labels used for VM type and persistent disk type in the tables below refer to the example Cloud
Config entries defined in Update the Cloud Config.
Templates that provide logging require a higher-memory VM type than Templates without logging.
Templates that provide logging reserve at least 512 MB of RAM for the logging process, in addition to the memory required by the data service process itself. Provisioning 512 MB of additional headroom above this minimum is recommended, to comfortably absorb the logging overhead.
The following table lists resource requirements per VM, as well as totals across all nodes of a Service Instance.
- Per VM
- Totals
| Template name | Nodes | vCPUs | Logging | SSL | Min. RAM | Min. Persistent Disk | Min. Ephemeral Disk | Example VM Type | Example Persistent Disk Type |
|---|---|---|---|---|---|---|---|---|---|
messaging4-single-ssl | 1 | 4 | Yes | Yes | ≥ 4.5 GB † | 10 GB | 5 GB | large | medium |
messaging4-single-no-logging-ssl | 1 | 2 | No | Yes | ≥ 4 GB | 10 GB | 5 GB | small | medium |
messaging4-replica-ssl | 3 | 4 | Yes | Yes | ≥ 4.5 GB † | 10 GB | 5 GB | large | medium |
| † Includes the RAM reserved for the logging process. See the note above. | |||||||||
| Template name | Nodes | vCPUs | Logging | SSL | Min. RAM | Min. Persistent Disk | Min. Ephemeral Disk |
|---|---|---|---|---|---|---|---|
messaging4-single-ssl | 1 | 4 | Yes | Yes | ≥ 4.5 GB † | 10 GB | 5 GB |
messaging4-single-no-logging-ssl | 1 | 2 | No | Yes | ≥ 4 GB | 10 GB | 5 GB |
messaging4-replica-ssl | 3 | 12 | Yes | Yes | ≥ 13.5 GB † | 30 GB | 15 GB |
| † Includes the RAM reserved for the logging process. See the note above. | |||||||
RabbitMQ spills messages to disk when the memory high watermark is reached, and blocks all publishers once available
disk drops below disk_free_limit (default: 1.5× VM RAM). On a small VM with 4 GB RAM this threshold is 6 GB, the
strict computed minimum persistent disk required. The medium disk type (10 GB) is the recommended minimum for any a9s
Messaging deployment, since it clears this threshold with headroom to spare.
Disk and Memory Usage
RabbitMQ uses both disk and memory to store queues. a9s Messaging configures the process with
vm_memory_high_watermark.relative = 0.42 and vm_memory_high_watermark_paging_ratio = 0.5. When memory usage exceeds
half of 42% of total memory (21% of total memory), RabbitMQ begins moving messages from memory to disk.
For example, on a small VM with 4 GB of RAM and 6 GB of persistent disk (the strict computed minimum), the total
usable memory for RabbitMQ before the hard watermark is approximately 1.7 GB (42% of 4 GB). When this limit is reached,
publisher connections are blocked until memory is available again. The garbage collector and other internal RabbitMQ
processes can consume up to double the current memory usage. Memory for a9s Logstash, a9s Backup Agent, and a9s Consul
must also be reserved.
Once usage reaches approximately 840 MB (50% of the watermark), messages begin moving to disk, leaving roughly 840 MB of additional in-memory headroom plus the 6 GB of persistent disk, a combined 6.84 GB of available space for the RabbitMQ process before publisher connections are blocked. Independently of this memory-based blocking behavior, a9s Parachute stops all processes once storage utilization reaches 80% of capacity.
Disk space is also shared with durable and lazy queues.
RabbitMQ requires (disk_free_limit_mem_relative × total memory) GB as reserved disk space to ensure proper operation.
The default value of disk_free_limit_mem_relative is 1.5; the minimum recommended value is 1.0. For example, when
disk_free_limit_mem_relative is set to 1.0 on a VM with 10 GB of memory and 15 GB of disk, the actual usable disk
space is approximately 5 GB. When available disk drops below this threshold, the messaging broker blocks all clients.
Further information is available in the RabbitMQ runtime documentation.