Resource Considerations
This document describes resource considerations and limitations to be taken into account when provisioning and operating a9s MongoDB 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 |
|---|---|---|---|---|---|---|---|---|---|
mongodb80sspl-single-ssl | 1 | 4 | Yes | Yes | ≥ 4.5 GB † | 10 GB | 5 GB | large | medium |
mongodb80sspl-single-no-logging-ssl | 1 | 2 | No | Yes | ≥ 4 GB | 10 GB | 5 GB | small | medium |
mongodb80sspl-replica-ssl | 3 | 4 | Yes | Yes | ≥ 4.5 GB † | 10 GB | 5 GB | large | medium |
mongodb70sspl-single-ssl | 1 | 4 | Yes | Yes | ≥ 4.5 GB † | 10 GB | 5 GB | large | medium |
mongodb70sspl-single-no-logging-ssl | 1 | 2 | No | Yes | ≥ 4 GB | 10 GB | 5 GB | small | medium |
mongodb70sspl-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 |
|---|---|---|---|---|---|---|---|
mongodb80sspl-single-ssl | 1 | 4 | Yes | Yes | ≥ 4.5 GB † | 10 GB | 5 GB |
mongodb80sspl-single-no-logging-ssl | 1 | 2 | No | Yes | ≥ 4 GB | 10 GB | 5 GB |
mongodb80sspl-replica-ssl | 3 | 12 | Yes | Yes | ≥ 13.5 GB † | 30 GB | 15 GB |
mongodb70sspl-single-ssl | 1 | 4 | Yes | Yes | ≥ 4.5 GB † | 10 GB | 5 GB |
mongodb70sspl-single-no-logging-ssl | 1 | 2 | No | Yes | ≥ 4 GB | 10 GB | 5 GB |
mongodb70sspl-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. | |||||||
MongoDB sizes the oplog at approximately 5% of available persistent disk, subject to the minimum and maximum bounds
described in Replication Lag below. A small disk results in a small oplog, which reduces the replication lag window that
replica set members can tolerate before requiring a full resync. The medium disk type (10 GB) is the recommended
minimum to provide an adequate oplog.
Replication Lag
Secondary nodes replicate data from the primary. The primary node stores data that has not yet been replicated on the oplog on disk. Disk usage can therefore grow faster than expected until a lagging secondary catches up.
The maximum oplog size is 5% of free disk with a lower bound of 990 MB and an upper bound of 50 GB, calculated when the MongoDB process starts. Newer versions may grow the oplog beyond this limit to avoid deleting the majority commit point.
For example, with a 5 GB persistent disk, the oplog can consume up to 990 MB in the event of a secondary node failure. The oplog attempts to retain 24 hours of operations; after this window, the secondary node must be manually cleaned and rejoined to the cluster.
Max Connections
Every a9s MongoDB instance configures the MongoDB process with maxIncomingConnections: 65536. Each connection is
represented by a file descriptor. The maximum number of open files is therefore a direct constraint on
maxIncomingConnections. a9s MongoDB instances configure a maximum of 64000 open files (ulimit -n 64000) and
32000 processes (ulimit -u 32000).
Both values are set via ulimit and can affect MongoDB behavior under a large number of connections. The number of open
connections has a direct impact on memory consumption.
Memory Cache Limits
By default, MongoDB uses up to max[50% of (total_memory - 1 GB), 256 MB]. The storage engine WiredTiger
also uses the filesystem cache, which may consume all available free memory.